On 12/16/2014 03:30 AM, Dongsheng Yang wrote:
Hi Robert, thanx for your proposal about this.
IMHO, output of df command shoud be more friendly to user.
Well, I think we have a disagreement on this point, let's take a look at
what the zfs is doing.
/dev/sda7- 10G
/dev/sda8- 10G
# zpool create myzpool mirror /dev/sda7 /dev/sda8 -f
# df -h /myzpool/
Filesystem Size Used Avail Use% Mounted on
myzpool 9.8G 21K 9.8G 1% /myzpool
That said that df command should tell user the space info they can see.
It means the output is the information from the FS level rather than
device level or _storage_manager level.
That's great for ZFS, but ZFS isn't BTRFS. ZFS can't get caught halfway
between existing modailties and sit there forever. ZFS doesn't
restructure itself. So the simple answer you want isn't _possible_
outside very simple cases.
So again, you've displayed a _simple_ case as if it covers or addresses
all the complex cases.
(I don't have the storage to actually do the exercise) But what do you
propose the correct answer is for the following case:
/dev/sda - 7.5G
/dev/sdb - 7.5G
mkfs.btrfs /dev/sd{a,b} -d raid0
mount /dev/sda /mnt
dd if=/dev/urandom of=/mnt/consumed bs=1G count=7
btrfsck balance start -dconvert=raid1 -dlimit=1 /mnt
(wait)
/bin/df
The filesystem is now in a superposition where all future blocks are
going to be written as raid1, one 2G stripe has been converted into two
two-gig stripes that have been mirrored, and six gig is still RAID0.
In your proposal we now have
@size=7G
@used=??? (clearly 7G, at the least, is consumed)
@filesize[consumed]=7G
@available is really messed up since there is now _probably_ 1G of one
of the original raid0 extents with free space and so available, almost
all of the single RAID1 metadata block, Room for three more metadata
stripes, and room for one more RAID1 extent.
so @available=2-ish gigs.
But since statfs() pivots on @size and @available /bin/df is going to
report @used as 3-ish gigs even though we've got an uncompressed and
uncompressable @7G file.
NOW waht if we went the _other_ way?
/dev/sda - 7.5G
/dev/sdb - 7.5G
mkfs.btrfs /dev/sd{a,b} -d raid1
mount /dev/sda /mnt
dd if=/dev/urandom of=/mnt/consumed bs=1G count=7
btrfsck balance start -dconvert=raid0 -dlimit=1 /mnt
(wait)
/bin/df
filesystem is _full_ when the convert starts.
@size=14Gig
@used=7G
@actual_available=0
@reported_available=??? (at least 2x1G extents are up for grabs so
minimum 2G)
@reported_used=???
@calculated_used=???
We are either back to reporting available space when non-trivial
allocation will report ENOSPC (if I did the math right etc).
Now do partial conversions to other formats and repeat the exercise.
Now add or remove storage here-or-there.
The "working set" and the "current model" are not _required_ to be in
harmony at any given time, so trying to analyze the working set based on
the current model is NP-complete.
In every modality we find that at some point we _can_ either report 0
available and still have room, or we report non-zero available and the
user's going to get an ENOSPC.
So fine, _IF_ btrfs disallowed conversion and fixed its overhead -- that
is if it stopped bing btrfs -- we could safely report cooked numbers.
But at that point, why BTRFS at all?
As for being easier on the user, that just depends on which lie each
user wants. People are smart enough to use a fair approximation, and the
only fair approximation we have available are at the storage management
level -- which is halfway between the raw blocks and the cooked
file-system numbers.
A BTRFS filesystem just _isn't_ fully cooked until the last data extent
is allocated, and because of COW that's over-cooked as well.
--
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
