From: Zachary Mark <zmark@cleversafe.com>
To: Ted Ts'o <tytso@mit.edu>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH 0/2] Re: Discrepancy in 'df' output between kernel 3.0 and 3.2 for ext4?
Date: Tue, 19 Jun 2012 16:01:06 -0500 [thread overview]
Message-ID: <4FE0E892.4090603@cleversafe.com> (raw)
In-Reply-To: <20120619201325.GE22805@thunk.org>
On 06/19/2012 03:13 PM, Ted Ts'o wrote:
> On Tue, Jun 19, 2012 at 02:54:44PM -0500, Zachary Mark wrote:
>>
>> Ted, thanks for the patches! I've tested your patches against
>> 3.5~rc3. I had to return the machine on which I first spotted the
>> problem, but here are results from a box with identical hardware:
>>
>> df from 3.0:
>> Filesystem 1K-blocks Used Available Use% Mounted on
>> /dev/sdh1 2907178636 205816 2906972820 1%
>> /dev/sdi1 2907178636 1056768 2906121868 1%
>>
>> df from 3.2.20 (identical to 3.5~rc3 without your patches):
>> Filesystem 1K-blocks Used Available Use% Mounted on
>> /dev/sdh1 2928733612 21760792 2906972820 1%
>> /dev/sdi1 2928733612 22611744 2906121868 1%
>>
>>
>> df from 3.5~rc3 with your patches applied (as they didn't apply to 3.2):
>> /dev/sdh1 2907178636 205816 2906972820 1%
>> /dev/sdi1 2907178636 1060936 2906117700 1%
>>
>> sdh1 is mostly empty. sdi1 has about 6700 128k files written to it plus
>> everything on sdh1. There seems to be slightly more overhead accounted
>> for after your patches. Not sure if this is to be expected or not.
>
> Hmm... it looks like df output /dev/sdh1 is identical between 3.0 and
> 3.5~rc3 with my patches. I'm not sure why there is a difference for
> /dev/sdi1. However, I note that the "Available" figure is the same
> between 3.0, 3.2.20 and 3.5~rc3 for /dev/sdh1, but there is a
> difference in the Available column between 3.2.20 and 3.5~rc3 for
> /dev/sdi3. Could it be that some files got written to /dev/sdi
> between your test run?
>
> It would be good if we could get this sorted out. I was pretty
> careful to account for all of the fs overhead blocks between when I
> did my patch with an empty file system.
>
> If this can't be accounted by more files being written to /dev/sdi1,
> could you send me the (compressed, since they will be large) output of
> dumpe2fs for /dev/sdh1 and /dev/sdi1 with the "df" output from your
> three test kernel so I can investigate further?
>
> Thanks,
>
> - Ted
Actually, you're right, I must have screwed up my original test somehow.
I just repeated the test. The 3.0 and 3.5~rc3-patched numbers are
identical to each other, and the 3.2.20/3.5~rc3-unpatched are also
identical to each other.
-- Zach
prev parent reply other threads:[~2012-06-19 21:01 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-13 18:08 Discrepancy in 'df' output between kernel 3.0 and 3.2 for ext4? Zachary Mark
2012-06-13 18:27 ` Eric Sandeen
2012-06-13 22:21 ` Zachary Mark
2012-06-14 19:00 ` Eric Sandeen
2012-06-18 21:45 ` [PATCH 0/2] " Theodore Ts'o
2012-06-18 21:45 ` [PATCH 1/2] ext4: pass a char * to ext4_count_free() instead of a buffer_head ptr Theodore Ts'o
2012-06-18 21:45 ` [PATCH 2/2] ext4: fix overhead calculation used by ext4_statfs() Theodore Ts'o
2012-06-19 19:54 ` [PATCH 0/2] Re: Discrepancy in 'df' output between kernel 3.0 and 3.2 for ext4? Zachary Mark
2012-06-19 20:13 ` Ted Ts'o
2012-06-19 21:01 ` Zachary Mark [this message]
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=4FE0E892.4090603@cleversafe.com \
--to=zmark@cleversafe.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.