On Tue, Nov 17, 2009 at 6:25 PM, jim owens <jow...@hp.com> wrote: > <snip> > So we know the "raw free blocks", but can not guarantee > "how many raw blocks per new user write-block" will be > consumed because we do not know what topology will be > in effect for a new write. > > We could cheat and use "worst-case topology" numbers > if all writes are the current default raid. Of course > this ignores DUP unless it is set on the whole filesystem. > > And we also have the problem of metadata - which is dynamic > and allocated in large chunks and has a DUP type, how do we > account for that in worst-case calculations. > > The worst-case is probably wrong but may be more useful to > people to know when they will run out of space. Or at least > it might make some of our ENOSPC complaints go away :) > > Only "raw" and "worst-case" can be explained to users and > which we report is up to Chris. Today we report "raw". > > After spending 10 years on a multi-volume filesystem that > had (unsolvable) confusing df output, I'm just of the > opinion that nothing we do will make everyone happy.
df is user-centric, and therefore is naturally expected to return used/available _logical_ capacity (how this translates to used physical space is up to file-system-specific tools to find out/report). Returning raw is counter-intuitive and causes surprise similar to that of Roland. With so flexible, down to per-file, topology configuration the only option I see for df to return logical capacity available is to compute the latter off the file-system object for which df is invoked. For instance, 'df /path/to/some/file' could return logical capacity for the mountpoint where some-file resides, computed from underlying physical capacity available _and_ topology for this file. 'df /mount-point' would under this implementation return available logical capacity assuming default topology for the referenced file-system. As to used logical space accounting, this is file-system-specific and I'm not yet familiar enough with btrfs code-base to argument for any approach. Regards, Andrey > > But feel free to run a patch proposal by Chris. > > jim > -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
