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.
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 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
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
12 matches
Mail list logo
