From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resqmta-ch2-11v.sys.comcast.net ([69.252.207.43]:43739 "EHLO resqmta-ch2-11v.sys.comcast.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750779AbaL0BKl (ORCPT ); Fri, 26 Dec 2014 20:10:41 -0500 Message-ID: <549E070E.8030509@pobox.com> Date: Fri, 26 Dec 2014 17:10:38 -0800 From: Robert White MIME-Version: 1.0 To: Dongsheng Yang , Grzegorz Kowal , linux-btrfs Subject: Re: Standards Problems [Was: [PATCH v2 1/3] Btrfs: get more accurate output in df command.] References: <36be817396956bffe981a69ea0b8796c44153fa5.1418203063.git.yangds.fnst@cn.fujitsu.com> <548B4117.1040007@inwind.it> <548E377D.6030804@cn.fujitsu.com> <548E7A7A.90505@pobox.com> <548E929B.2090203@pobox.com> <548E9B38.9080202@cn.fujitsu.com> <548EABBB.4060204@pobox.com> <548FA762.2070504@pobox.com> <549017E8.7060107@cn.fujitsu.com> <54908D8A.8040101@pobox.com> <54916B39.5080409@cn.fujitsu.com> <549252FF.10400@pobox.com> <549960B9.20300@cn.fujitsu.com> In-Reply-To: <549960B9.20300@cn.fujitsu.com> Content-Type: text/plain; charset=utf-8; format=flowed Sender: linux-btrfs-owner@vger.kernel.org List-ID: 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?