On Tue, May 09, 2006 at 04:01:53PM -0500, Al Hopper wrote: > Does this mean, that if I have a zfs filesystem that is > creating/writing/reading/deleting millions of short-lived files in a day, > that the directory area would keep growing? Or am I missing something?
The space used by a directory is not completely reclaimed until the directory is removed with rmdir(2). However, its space usage is bounded by its maximum number of entries. For example, if I have a single directory with a million files in it, and I repeatedly remove all the files, then fill it up with another million files, then the space used by the directory will fluctuate between 77MB and 41MB (which should be about 8MB, see CR 6423695). The space used by files (and directories) is completely reclaimed when they are deleted. > Surely the ideal case, when a file is deleted, is that the corresponding > directory space/time would be zero. Agreed. As I mentioned, we haven't found this to be a problem in practice. Almost all directories are trivially small, and the big ones tend to stay big. However, if you find it to be a problem, let us know the details of your situation, and we'll adjust the priority of this accordingly. > In the case of busy production systems, it would be great to have some > sort of zfs directory 'purge' function, that, *if necessary*, could be > run when the system is known to be idle (in the wee hours of the > A.M.)? If this turns out to be an issue, we will solve the problem transparently (eg. ZAP leaf block "joining" or automatic ZAP rewriting), rather than introduce a knob for administrators to worry about. --matt _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
