From: Robert White <rwhite@pobox.com>
To: Dongsheng Yang <yangds.fnst@cn.fujitsu.com>,
Grzegorz Kowal <custos.mentis@gmail.com>,
linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: Standards Problems [Was: [PATCH v2 1/3] Btrfs: get more accurate output in df command.]
Date: Fri, 26 Dec 2014 17:10:38 -0800 [thread overview]
Message-ID: <549E070E.8030509@pobox.com> (raw)
In-Reply-To: <549960B9.20300@cn.fujitsu.com>
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.
>> 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
>>
>
>
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. Grab some of those cases. Then tell me what your
patch will report and why it makes more sense than what is reported now.
For code to be correct it _must_ be correct for the "special" cases. You
don't get to just ignore the special cases.
So what are your specific answers to those cases?
next prev parent reply other threads:[~2014-12-27 1:10 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-11 8:31 [PATCH v2 1/3] Btrfs: get more accurate output in df command Dongsheng Yang
2014-12-11 8:31 ` [PATCH v2 2/3] Btrfs: raid56: simplify the parameter of nr_parity_stripes() Dongsheng Yang
2014-12-16 6:21 ` Satoru Takeuchi
2014-12-11 8:31 ` [PATCH v2 3/3] Btrfs: adapt df command to RAID5/6 Dongsheng Yang
2014-12-12 18:00 ` [PATCH v2 1/3] Btrfs: get more accurate output in df command Goffredo Baroncelli
2014-12-13 0:50 ` Duncan
2014-12-13 10:21 ` Dongsheng Yang
2014-12-13 9:57 ` Dongsheng Yang
2014-12-12 19:25 ` Goffredo Baroncelli
2014-12-14 11:29 ` Dongsheng Yang
[not found] ` <CABmMA7tw9BDsBXGHLO4vjcO4gaYmZPb_BQV8w22griqFvCJpPA@mail.gmail.com>
2014-12-14 14:32 ` Grzegorz Kowal
2014-12-15 1:21 ` Dongsheng Yang
2014-12-15 6:06 ` Robert White
2014-12-15 7:49 ` Robert White
2014-12-15 8:26 ` Dongsheng Yang
2014-12-15 9:36 ` Robert White
2014-12-16 3:30 ` Standards Problems [Was: [PATCH v2 1/3] Btrfs: get more accurate output in df command.] Robert White
2014-12-16 3:52 ` Robert White
2014-12-16 11:30 ` Dongsheng Yang
2014-12-16 13:24 ` Dongsheng Yang
2014-12-16 19:52 ` Robert White
2014-12-17 11:38 ` Dongsheng Yang
2014-12-18 4:07 ` Robert White
2014-12-18 8:02 ` Duncan
2014-12-23 12:31 ` Dongsheng Yang
2014-12-27 1:10 ` Robert White [this message]
2015-01-05 9:59 ` Dongsheng Yang
2014-12-31 0:15 ` Zygo Blaxell
2015-01-05 9:56 ` Dongsheng Yang
2015-01-05 10:07 ` [PATCH v2 1/3] Btrfs: get more accurate output in df command Dongsheng Yang
2015-01-05 10:07 ` [PATCH v2 2/3] Btrfs: raid56: simplify the parameter of nr_parity_stripes() Dongsheng Yang
2015-01-05 10:07 ` [PATCH v2 3/3] Btrfs: adapt df command to RAID5/6 Dongsheng Yang
2014-12-19 3:32 ` [PATCH v2 1/3] Btrfs: get more accurate output in df command Zygo Blaxell
[not found] ` <548F1EA7.9050505@inwind.it>
2014-12-16 13:47 ` Dongsheng Yang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=549E070E.8030509@pobox.com \
--to=rwhite@pobox.com \
--cc=custos.mentis@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=yangds.fnst@cn.fujitsu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).