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

Edward Ned Harvey (zfsonlinux) zfsonlinux at nedharvey.com
Wed Nov 14 08:30:31 EST 2018


> 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.


More information about the zfs-discuss mailing list