On Thu, 17 Sep 2009 22:55:38 +0100 Robert Milkowski <mi...@task.gda.pl> wrote:
> IMHO you won't be able to lower a file blocksize other than by > creating a new file. For example: Okay, thank you. > If you are not worried with this extra overhead and you are mostly > concerned with proper accounting of used disk space than instead of > relaying on a file size alone you should take intro account its > blocksize and round file size up-to blocksize (actual file size on > disk (not counting metadata) is N*blocksize). Metadata can be nontrivial for small blocksizes, though, can't it? I tried similar tests with varying recordsizes and with recordsize=1k, a file with 1M bytes written to it took up significantly more than 1024 1k blocks. Is there a reliable way to account for this? Through experimenting with various recordsizes and file sizes I can see enough of a pattern to try and come up with an equation for the total disk usage, but that doesn't mean such a relation would be correct... if someone could give me something a bit more authoritative, it would be nice. > However IIRC there is an open bug/rfe asking for a special treatment > of a file's tail block so it can be smaller than the file blocksize. > Once it's integrated your math could be wrong again. > > Please also note that relaying on a logical file size could be even > more misleading if compression is enabled in zfs (or dedup in the > future). Relaying on blocksize will give you more accurate estimates. I was a bit unclear. We're not so concerned about the math being wrong in general; we just need to make sure we are not significantly underestimating the usage. If we overestimate within reason, that's fine, but getting the tightest bound is obviously more desirable. So I'm not worried about compression, dedup, or the tail block being treated in such a way. > You can get a file blocksize by using stat() and getting value of > buf.st_blksize > or you can get a good estimate of used disk space by doing > buf.st_blocks*512 Hmm, I thought I had tried this, but st_blocks didn't seem to be updated accurately until after some time after a write. I'd also like to avoid having to stat the file each time after a write or truncate in order to get the file size. The current way the code is structured intends for the space calculations to be made /before/ the write is done. It may be possible to change that, but I'd rather not, if possible (and I'd have to make sure there's not a significant speed hit in doing so). -- Andrew Deason adea...@sinenomine.net _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
