On Thu, 17 Sep 2009 18:40:49 -0400 Robert Milkowski <mi...@task.gda.pl> wrote:
> if you would create a dedicated dataset for your cache and set quota > on it then instead of tracking a disk space usage for each file you > could easily check how much disk space is being used in the dataset. > Would it suffice for you? No. We need to be able to tell how close to full we are, for determining when to start/stop removing things from the cache before we can add new items to the cache again. I'd also _like_ not to require a dedicated dataset for it, but it's not like it's difficult for users to create one. > Setting recordsize to 1k if you have lots of files (I assume) larger > than that doesn't really make sense. > The problem with metadata is that by default it is also compressed so > there is no easy way to tell how much disk space it occupies for a > specified file using standard API. We do not know in advance what file sizes we'll be seeing in general. We could of course tell people to tune the cache dataset according to their usage pattern, but I don't think users are generally going to know what their cache usage pattern looks like. I can say that at least right now, usually each file will be at most 1M long (1M is the max unless the user specifically changes it). But between the range 1k-1M, I don't know what the distribution looks like. I can't get an /estimate/ on the data+metadata disk usage? What about in the hypothetical case of the metadata compression ratio being effectively the same as without compression, what would it be then? -- Andrew Deason adea...@sinenomine.net _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
