From: Zheng Liu <gnehzuil.liu@gmail.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: "Dilger, Andreas" <andreas.dilger@intel.com>,
"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>
Subject: Re: "make check" broken on maint branch?
Date: Mon, 4 Nov 2013 14:20:40 +0800 [thread overview]
Message-ID: <20131104062039.GA3265@gmail.com> (raw)
In-Reply-To: <20131101164834.GA28988@thunk.org>
On Fri, Nov 01, 2013 at 12:48:34PM -0400, Theodore Ts'o wrote:
> On Fri, Nov 01, 2013 at 09:12:37PM +0800, Zheng Liu wrote:
> > > Hmm.... it works for me. Run while r_64bit_big_expand is running:
> > >
> > > % ls -l tmp
> > > ...
> > > 24896 -rw-r--r--. 1 tytso tytso 2199023255552 Oct 31 23:17 e2fsprogs-tmp.pkOcCc
> > > ...
> >
> > $ ls -l /tmp
> > -rw-rw-r-- 1 wenqing wenqing 536870912 Nov 1 21:03 e2fsprogs-tmp.x8yzKP
>
> Well, I got this by running "./test_script r_64bit_big_expand" and
> then typing ^Z to stop the test mid-stream, and then looking in /tmp.
Thanks for letting me know.
>
> But a simpler thing to do is to simply run the following commands:
>
> truncate -s 2T /tmp/foo.img
> mke2fs -t ext4 -F /tmp/foo.img
>
> ... and see if it works correctly. I'm wondering if the problem is
> that a file limit was set, although that would result in a core dump:
>
> % bash
> % ulimit -f 131072
> % truncate -s 2T /tmp/foo.img
> File size limit exceeded (core dumped)
> % exit
>
> .... so that doesn't seem to be it. Anyway, the problem seems to be
> that trying to create a sparse 2T file during the test is what's
> causing the problem that you and Andreas are seeing. If this theory
> is question, the next question is what's causing the failure to write
> files whose i_size is greater than 2T.
It seems that I know the reason why tests failed. That is because my
/tmp directory is a ext3 file system, and I couldn't create a big sparse
file like this 'truncate -s 2T /tmp/foo.img'. So I did the following
test in my sand box.
% sudo mke2fs -t ext4 ${DEV} # I create a new ext4 file system
% sudo mount -t ext4 ${DEV} /tmp # mount this file system on /tmp
% sudo chmod 777 -R /tmp
% cd $E2FSPROGS
% make check
Then r_64bit_big_expand, r_bigalloc_big_expand and r_ext4_big_expand can
survive. So I guess that the root cause is this.
Andreas, could you please confirm my guess?
BTW, after that, I still get a failure. That is f_extent_oobounds. So
we still need to take a closer look at this problem.
- Zheng
next prev parent reply other threads:[~2013-11-04 6:18 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-31 21:35 "make check" broken on maint branch? Dilger, Andreas
2013-11-01 2:35 ` Zheng Liu
2013-11-01 3:21 ` Theodore Ts'o
2013-11-01 13:12 ` Zheng Liu
2013-11-01 16:48 ` Theodore Ts'o
2013-11-04 6:20 ` Zheng Liu [this message]
2013-11-01 18:24 ` Dilger, Andreas
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=20131104062039.GA3265@gmail.com \
--to=gnehzuil.liu@gmail.com \
--cc=andreas.dilger@intel.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.