I was catching up on old e-mail on this list, and came across a blog posting from Henrik Johansson:
http://sparcv9.blogspot.com/2009/10/curious-case-of-strange-arc.html it tells of his woes with a fragmented /var/pkg/downloads combined with atime updates. I see the same problem on my servers, e.g. $ time du -s /var/pkg/download 1614308 /var/pkg/download real 11m50.682s $ time du -s /var/pkg/download 1614308 /var/pkg/download real 12m03.395s on this server, increasing arc_meta_limit wouldn't help, but I think a newer kernel would be more aggressive (this is 2008.11). arc_meta_used = 262 MB arc_meta_limit = 2812 MB arc_meta_max = 335 MB turning off atime helps: real 8m06.563s in this test case, running du(1), turning off atime altogether isn't really needed, it would suffice to turn off atime updates on directories. in Linux, this can be achieved with the mount option "nodiratime". if ZFS had it, I guess it would be a new value for the atime property, "nodir" or somesuch. I quite often find it useful to have access to atime information to see if files have been read, for forensic purposes, for debugging, etc. so I am loath to turn it off. however, atime on directories can hardly ever be used for anything -- you have to take really good care not to trigger an update just checking the atime, and even if you do get a proper reading, there are so many tree traversing utilities that the information value is low. it is quite unlikely that any applications break in a nodiratime mode, and few people should have any qualms enabling it. Santa, are you listening? :-) -- Kjetil T. Homme Redpill Linpro AS - Changing the game _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
