[zfs-discuss] "du -ksh ." taking hours to complete

Durval Menezes durval.menezes at gmail.com
Wed Nov 14 08:40:54 EST 2018


Hello Ed,

On Wed, Nov 14, 2018 at 10:30 AM Edward Ned Harvey (zfsonlinux) <
zfsonlinux at nedharvey.com> wrote:

> > From: zfs-discuss <zfs-discuss-bounces at list.zfsonlinux.org> On Behalf Of
> > Durval Menezes via zfs-discuss
> >
> > Thanks for the explanation. Yes, I remember that the L2ARC cache is
> cleared
> > on boot, but this is hardly a problem here since I hardly ever reboot...
> my
> > main server has been up for over 6 months now.
> >
> > BTW, wasn't there some work being done on making the L2ARC cache
> > persistent across reboots? I faintly remember reading about that a few
> > months ago.
>
> Besides just the issue of cache being cleared on reboot - data is not
> guaranteed to be in cache, and cache must be read at least once, and writes
> still have to hit the disk regardless of cache... So the difference between
> L2ARC (with or without "secondary cache=metadata", with or without
> persistence) versus special vdev's, is a fundamental difference in
> architecture, reliability, and performance characteristics. I know in many
> filesystems, the files themselves tend to be fairly large, but the metadata
> is always small (per file), so being able to "walk" a large filesystem very
> quickly with all metadata stored on SSD would be a wonderful addition IMHO,
> and I know in the past I've never been able to recommend using dedup,
> because the DDT is too large. Incredible demands on RAM. So hopefully being
> able to offload DDT to some nice fast NVMe devices might make it usable...
>
> Who knows, in your personal situation where you have a particular usage
> pattern and never reboot, having a SSD cache and "secondary cache=metadata"
> might be just as good for you personally as the special vdev would.
> *shrugs*.   YMMV.
>

Good point RE: writes. This would tip the scale towards the special vdevs
for some loads here.

Looking forward to 0.8.0!

BTW (and if it's not too OOT), does anyone know whether this is on track
(or at least on the horizon) to be included in other OpenZFS
implementations, more specifically FreeBSD's?

Cheers,
-- 
   Durval.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.zfsonlinux.org/pipermail/zfs-discuss/attachments/20181114/c690a3e5/attachment.html>


More information about the zfs-discuss mailing list