On 12/31/2014 08:15 AM, Zygo Blaxell wrote:
On Wed, Dec 17, 2014 at 08:07:27PM -0800, Robert White wrote:
[...]
There are a number of pathological examples in here, but I think there
are justifiable correct answers for each of them that emerge from a
single interpretation of the meanings of
On 12/27/2014 09:10 AM, Robert White wrote:
On 12/23/2014 04:31 AM, Dongsheng Yang wrote:
On 12/18/2014 12:07 PM, Robert White wrote:
...
Thanx
Yang
. xaE
Fine. but you still haven't told me/us what you thing df (really
fsstat() ) should report in those cases.
Go back to that email.
When function btrfs_statfs() calculate the tatol size of fs, it is calculating
the total size of disks and then dividing it by a factor. But in some usecase,
the result is not good to user.
Example:
# mkfs.btrfs -f /dev/vdf1 /dev/vdf2 -d raid1
# mount /dev/vdf1 /mnt
# dd
On Wed, Dec 17, 2014 at 08:07:27PM -0800, Robert White wrote:
[...]
There are a number of pathological examples in here, but I think there
are justifiable correct answers for each of them that emerge from a
single interpretation of the meanings of f_bavail, f_blocks, and f_bfree.
One gotcha is
On 12/23/2014 04:31 AM, Dongsheng Yang wrote:
On 12/18/2014 12:07 PM, Robert White wrote:
I don't disagree with the _ideal_ of your patch. I just think that
it's impossible to implement it without lying to the user or making
things just as bad in a different way. I would _like_ you to be right.
On 12/18/2014 12:07 PM, Robert White wrote:
I don't disagree with the _ideal_ of your patch. I just think that
it's impossible to implement it without lying to the user or making
things just as bad in a different way. I would _like_ you to be right.
But my thing is finding and quantifying
Robert White posted on Wed, 17 Dec 2014 20:07:27 -0800 as excerpted:
We have room for 1 more metadata extent on each
drive, but if we allocate two more metadat extents on each drive we will
burn up 1.25 GiB by reducing it to 0.75GiB.
FWIW, at least the last chunk assignment can be smaller
On Sun, Dec 14, 2014 at 10:06:50PM -0800, Robert White wrote:
ABSTRACT:: Stop being clever, just give the raw values. That's what
you should be doing anyway. There are no other correct values to
give that doesn't blow someone's paradigm somewhere.
The trouble is a lot of existing software
On 12/17/2014 03:52 AM, Robert White wrote:
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.
I don't disagree with the _ideal_ of your patch. I just think that it's
impossible to implement it without lying to the user or making things
just as bad in a different way. I would _like_ you to be right. But my
thing is finding and quantifying failure cases and the entire question
is full of
On 12/16/2014 11:30 AM, Robert White wrote:
On 12/15/2014 01:36 AM, Robert White wrote:
So we don't just hand-wave over statfs(). We include the
dev_item.bytes_excluded in the superblock and we decide once-and-for-all
(with any geometry creation, or completed conversion) how many bytes
just
On Tue, Dec 16, 2014 at 7:30 PM, Dongsheng Yang
yangds.f...@cn.fujitsu.com wrote:
On 12/16/2014 11:30 AM, Robert White wrote:
On 12/15/2014 01:36 AM, Robert White wrote:
So we don't just hand-wave over statfs(). We include the
dev_item.bytes_excluded in the superblock and we decide
Hi Goffredo,
On Tue, Dec 16, 2014 at 1:47 AM, Goffredo Baroncelli kreij...@inwind.it wrote:
I Yang,
On 12/14/2014 12:29 PM, Dongsheng Yang wrote:
On Sat, Dec 13, 2014 at 3:25 AM, Goffredo Baroncelli kreij...@inwind.it
wrote:
On 12/11/2014 09:31 AM, Dongsheng Yang wrote:
When function
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
On 12/15/2014 12:26 AM, Dongsheng Yang wrote:
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
On 12/15/2014 01:36 AM, Robert White wrote:
So we don't just hand-wave over statfs(). We include the
dev_item.bytes_excluded in the superblock and we decide once-and-for-all
(with any geometry creation, or completed conversion) how many bytes
just _can't_ be reached but only once we _know_ they
On 12/15/2014 07:30 PM, Robert White wrote:
The above would be ideal. But POSIX says no. f_blocks is defined (only
Correction the linux kernel says total data blocks, POSIX says total
blocks -- it was a mental typo... 8-)
in the comments) as total data blocks in the filesystem and /bin/df
On Sat, Dec 13, 2014 at 3:25 AM, Goffredo Baroncelli kreij...@inwind.it wrote:
On 12/11/2014 09:31 AM, Dongsheng Yang wrote:
When function btrfs_statfs() calculate the tatol size of fs, it is
calculating
the total size of disks and then dividing it by a factor. But in some
usecase,
the
Hi,
I see another problem on 1 device fs after applying this patch. I set
up 30GB system partition:
in gdisk key 'i'
Partition size: 62914560 sectors (30.0 GiB) - 62914560 * 512 =
32212254720 = 30.0GiB
before applying the patch df -B1 shows
Filesystem1B-blocks UsedAvailable
On 12/14/2014 10:32 PM, Grzegorz Kowal wrote:
Hi,
I see another problem on 1 device fs after applying this patch. I set
up 30GB system partition:
in gdisk key 'i'
Partition size: 62914560 sectors (30.0 GiB) - 62914560 * 512 =
32212254720 = 30.0GiB
before applying the patch df -B1 shows
On 12/14/2014 05:21 PM, Dongsheng Yang wrote:
Does it make sense to you?
I understood what you were saying but it didn't make sense to me...
As there are 2 complaints for the same change of @size in df, I have to
say it maybe not so easy to understand.
Anyone have some suggestion about
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...)
Concise Example to attempt to be clearer:
/dev/sda == 1TiB
/dev/sdb == 2TiB
/dev/sdc == 3TiB
/dev/sdd == 3TiB
mkfs.btrfs
On 12/13/2014 02:00 AM, Goffredo Baroncelli wrote:
On 12/11/2014 09:31 AM, Dongsheng Yang wrote:
When function btrfs_statfs() calculate the tatol size of fs, it is calculating
the total size of disks and then dividing it by a factor. But in some usecase,
the result is not good to user.
I am
On 12/13/2014 08:50 AM, Duncan wrote:
Goffredo Baroncelli posted on Fri, 12 Dec 2014 19:00:20 +0100 as
excerpted:
$ sudo ./btrfs fi df /mnt/btrfs1/
Data, RAID1: total=1.00GiB, used=512.00KiB
Data, single: total=8.00MiB, used=0.00B
System, RAID1: total=8.00MiB, used=16.00KiB
System, single:
On 12/11/2014 09:31 AM, Dongsheng Yang wrote:
When function btrfs_statfs() calculate the tatol size of fs, it is calculating
the total size of disks and then dividing it by a factor. But in some usecase,
the result is not good to user.
I am checking it; to me it seems a good improvement.
On 12/11/2014 09:31 AM, Dongsheng Yang wrote:
When function btrfs_statfs() calculate the tatol size of fs, it is calculating
the total size of disks and then dividing it by a factor. But in some usecase,
the result is not good to user.
I Yang; during my test I discovered an error:
$ sudo
Goffredo Baroncelli posted on Fri, 12 Dec 2014 19:00:20 +0100 as
excerpted:
$ sudo ./btrfs fi df /mnt/btrfs1/
Data, RAID1: total=1.00GiB, used=512.00KiB
Data, single: total=8.00MiB, used=0.00B
System, RAID1: total=8.00MiB, used=16.00KiB
System, single: total=4.00MiB, used=0.00B
Metadata,
When function btrfs_statfs() calculate the tatol size of fs, it is calculating
the total size of disks and then dividing it by a factor. But in some usecase,
the result is not good to user.
Example:
# mkfs.btrfs -f /dev/vdf1 /dev/vdf2 -d raid1
# mount /dev/vdf1 /mnt
# dd
28 matches
Mail list logo
