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 failure cases and the entire
question is full of fail.
...
See you keep giving me these examples where the history of the
filesystem is uniform. It was made a certain way and stayed that way.
But in real life this sort of thing is going to happen and your patch
simply report's a _different_ _wrong_ number. A _friendlier_ wrong
number, I'll grant you that, but still wrong.
Hi Robert, sorry for the late. (It's busy to deal with some other work.)
Yes, you are providing some examples here to show that in some cases the
numbers from df is not helpful to understand the real space state in
disk. But
I'm afraid we can not blame df reporting a wrong number. You could say
"Hey df, you are stupid, we can store the small file in metadata to exceed
your @size.". But he just reports the information from what he is seeing
from FS level honestly.
He is reporting what he can see, and do not care about the other things
out of
his business.
The all special cases you provided in this thread, actually lead to one
result that
"Btrfs is special, df command will report an improper in some case.". It
means
we need some other methods to tell user about the space info. And yes,
we had. It's
btrfs fi df.
You are trying to make df showing information as more as possible, even
change
the behaviour of df in btrfs to show the numbers of different meaning
with what it
is in other filesystems. And my answer is keeping df command doing what
he want,
and solve the problems in our private "df" , btrfs fi df.
Thanx
Yang
. xaE
--
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
