On 12/15/2014 03:49 PM, Robert White wrote:
On 12/14/2014 10:06 PM, Robert White wrote:
On 12/14/2014 05:21 PM, Dongsheng Yang wrote:
Anyone have some suggestion about it?
(... strong advocacy for raw numbers...)
Hi Robert, thanx for your so detailed reply.
You are proposing to report the raw numbers in df command, right?
Let's compare the space information in FS level and Device level.
Example:
/dev/sda == 1TiB
/dev/sdb == 2TiB
mkfs.btrfs /dev/sda /dev/sdb -d raid1
(1). If we report the raw numbers in df command, we will get the result of
@size=3T, @used=0 @available=3T. It's not a bad idea until now, as you said
user can consider the raid when they are using the fs. Then if we fill
1T data
into it. we will get @size=3, @used=2T, @avalable=1T. And at this moment, we
will get ENOSPC when writing any more data. It's unacceptable. Why you
tell me there is 1T space available, but I can't write one byte into it?
(2). Actually, there was an elder btrfs_statfs(), it reported the raw
numbers to user.
To solve the problem mentioned in (1), we need report the space
information in the FS level.
Current btrfs_statfs() is designed like this, but not working in any cases.
My new btrfs_statfs() here is following this design and implementing it
to show a *better* output to user.
Thanx
Yang
Concise Example to attempt to be clearer:
/dev/sda == 1TiB
/dev/sdb == 2TiB
/dev/sdc == 3TiB
/dev/sdd == 3TiB
mkfs.btrfs /dev/sd{a..d} -d raid0
mount /dev/sda /mnt
Now compare ::
#!/bin/bash
dd if=/dev/urandom of=/mnt/example bs=1G
vs
#!/bin/bash
typeset -i counter
for ((counter=0;;counter++)); do
dd if=/dev/urandom of=/mnt/example$conter bs=44 count=1
done
vs
#!/bin/bash
typeset -i counter
for ((counter=0;;counter++)); do
dd if=/dev/urandom of=/mnt/example$conter bs=44 count=1
done &
dd if=/dev/urandom of=/mnt/example bs=1G
Now repeat the above 3 models for
mkfs.btrfs /dev/sd{a..d} -d raid5
......
As you watch these six examples evolve you can ponder the ultimate
futility of doing adaptive prediction within statfs().
Then go back and change the metadata from the default of RAID1 to
RAID5 or RAID6 or RAID10.
Then go back and try
mkfs.btrfs /dev/sd{a..d} -d raid10
then balance when the big file runs out of space, then resume the big
file with oflag=append
......
Unlike _all_ our predecessors, we are active at both the semantic file
storage level _and_ the physical media management level.
None of the prior filesystems match this new ground exactly.
The only real option is to expose the raw numbers and then tell people
the corner cases.
Absolutely unavailable blocks, such as the massive waste of 5TiB in
the above sized media if raid10 were selected for both data and
metadata would be subtracted from size if and only if it's
_impossible_ for it to be accessed by this sort of restriction. But
even in this case, the correct answer for size is 4TiB because that
exactly answers "how big is this filesystem".
It might be worth having a "dev_item.bytes_excluded" or unusable or
whatever to account for the difference between total_bytes and
bytes_used and the implicit bytes available. This would account for
the 0,1,2,2 TiB that a raid10 of the example sizes could never reach
in the current geometry. I'm betting that this sort of number also
shows up as some number of sectors in any filesystem that has an odd
tidbit of size up at the top where no structure is ever gong to fit.
That's just a feature of the way disks use GB instead of GiB and msdos
style partitions love the number 63.
So resize sets the size. Geometry limitations may reduce the effective
size by some, or a _lot_, but then the used-vs-available should _not_
try to correct for whatever geometry is in use. Even when it might be
simple because if it does it well in the simple cases like
raid10/raid10, it would have to botch it up on the hard cases.
.
--
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
