linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: Nikola Ciprich <nikola.ciprich@linuxbox.cz>, linux-ext4@vger.kernel.org
Subject: Re: e2fsprogs - possible regression between 1.42.7 and 1.42.8
Date: Mon, 29 Jul 2013 12:14:43 -0500	[thread overview]
Message-ID: <51F6A303.4090008@redhat.com> (raw)
In-Reply-To: <20130729163838.GI11816@thunk.org>

On 7/29/13 11:38 AM, Theodore Ts'o wrote:
> On Mon, Jul 29, 2013 at 11:13:42AM -0500, Eric Sandeen wrote:
>>
>> Ted, these are the same ones I saw, plus one I think (working on getting
>> all the info).
>>
>> I don't think it's a regression, because:
>>
>> commit e79a9395b382e831c125d000d2bf16ba4b6253d4
>> Author: Theodore Ts'o <tytso@mit.edu>
>> Date:   Sun Mar 31 20:34:24 2013 -0400
>>
>>     tests: add more tests for off-line resizing
>>
>> and:
>>
>> $ git describe --contains e79a9395b382e831c125d000d2bf16ba4b6253d4
>> v1.42.8~31
>>
>> the tests were only added in the last release.  Running the same tests
>> on older releases most likely breaks as well.
> 
> Well, they would almost certainly break on older releases because of
> bugs due to bugs that were fixed in 1.42.8.  :-)

...or not ;)

> Let me be more precise; these tests aren't failing for me when I run
> build and run "make check" on pristine 1.42.8 version of e2fsprogs on
> Debian Stable.  So it's likely that the test is doing something that
> is specific to Red Hat systems.  It may stil be turning up a bug that
> for some reason we're not seeing on Debian systems.  
> 
> We are using the e2fsck binary built in the tree as the source of test
> bits for the resize test.  I'm guessing that it is substantially
> smaller or bigger when built on Red Hat systems?!?

Something along those lines.

> Could you modify tests/script/resize to capture a copy of the
> constructed file system before we start running resize2fs on it so I
> can try reproducing it on my end?

Yes, getting to it ...

> 					- Ted
> 
> P.S.  Hmm, for some reason the size of the e2fsck binary must be
> *substantially* smaller on Red Hat systems.  What configure options
> are you using?

oh we just symlink it to /bin/true ;)  (KIDDING)

Hm, it's currently this in the specfile:

%configure --enable-elf-shlibs --enable-nls --disable-uuidd --disable-fsck \
           --disable-e2initrd-helper --disable-libblkid --disable-libuuid \
           --with-root-prefix=/usr

and %configure pulls in other stuff as well - let's see, here's the full cmdline:

+ ./configure --build=s390x-redhat-linux-gnu --host=s390x-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-elf-shlibs --enable-nls --disable-uuidd --disable-fsck --disable-e2initrd-helper --disable-libblkid --disable-libuuid --with-root-prefix=/usr

(!)

-Eric

> Looking at my log, it shrinks the file system to:
> 
> r_1024_small_bg.log:The filesystem on /tmp/e2fsprogs-tmp.RE74xl is now 1341 blocks long.
> 
> and then
> 
> r_1024_small_bg.log:The filesystem on /tmp/e2fsprogs-tmp.RE74xl is now 1215 blocks long.
> 
> On your log, it shrinks the filesystem to 1191 blocks and then 1111 blocks.
> 
> On my system with default configure options, the size of the e2fsck
> binary is 1124k.  It sounds like the size of your compiled e2fsck
> binary is approximately 100k smaller?
> 


  reply	other threads:[~2013-07-29 17:14 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-29  8:39 e2fsprogs - possible regression between 1.42.7 and 1.42.8 Nikola Ciprich
2013-07-29 14:40 ` Theodore Ts'o
2013-07-29 16:00   ` Nikola Ciprich
2013-07-29 16:13 ` Eric Sandeen
2013-07-29 16:38   ` Theodore Ts'o
2013-07-29 17:14     ` Eric Sandeen [this message]
     [not found]   ` <51F87075.2020508@redhat.com>
2013-07-31  2:10     ` Eric Sandeen
2013-09-04  8:04       ` Nikola Ciprich
2013-09-04 14:02         ` Eric Sandeen

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=51F6A303.4090008@redhat.com \
    --to=sandeen@redhat.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=nikola.ciprich@linuxbox.cz \
    --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 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).