On Mon, Feb 10, 2014 at 7:13 PM, cwillu <cwi...@cwillu.com> wrote: > On Mon, Feb 10, 2014 at 7:02 PM, Roger Binns <rog...@rogerbinns.com> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 10/02/14 10:24, cwillu wrote: >>> The regular df data used number should be the amount of space required >>> to hold a backup of that content (assuming that the backup maintains >>> reflinks and compression and so forth). >>> >>> There's no good answer for available space; >> >> I think the flipside of the above works well. How large a group of files >> can you expect to create before you will get ENOSPC? >> >> That for example is the check code does that looks at df - "I need to put >> in XGB of files - will it fit?" It is also what users do. > > But the answer changes dramatically depending on whether it's large > numbers of small files or a small number of large files, and the > conservative worst-case choice means we report a number that is half > what is probably expected.
I don't think that is a problem, as long as the "avail guesstimate" is conservative. Scenario: A user has 10G of files and df reports that there are 11G available. I think the expectation is that copying these 10G into the filesystem will not ENOSPC. After the copy completes, whether the new avail number is ==1G or >>1G is less important IMHO. I.e. I like to see df output as a "you can write AT LEAST this much more data until the filesystem is full". That was my 5 cent. -- 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
