From: Eric Whitney <enwlinux@gmail.com>
To: namjae.jeon@samsung.com
Cc: a.sangwan@samsung.com, linux-ext4@vger.kernel.org
Subject: generic/064 test failures on ext4 (4.2-rc*)
Date: Mon, 27 Jul 2015 15:10:03 -0400 [thread overview]
Message-ID: <20150727190957.GA1606@localhost.localdomain> (raw)
Hi Namjae:
I'm seeing generic/064 fail consistently when testing ext4 on 4.2-rc kernels
with Ted's kvm-xfstests test appliance.
The two kvm-xfstests test cases that fail are ext3conv and data_journal. Both
of them force disablement of delayed allocation. The nodelalloc mount option
is used explicitly in the ext3conv case, and it's set implicitly in the kernel
when the data_journal mount option is used. The size of the scratch device
used also matters. The failure occurs when the device is 5 GB in size, but
does not when 20 GB in size.
What's happening is that when nodelalloc is set, ext4 produces a testfile.dest
containing 101 extents when generic/064 inserts 100 block ranges, and this does
not match the test's expected output of 100 extents.
Ted Ts'o says that ext4 does not guarantee a specific extent layout when
delayed allocation is disabled in these circumstances.
The header comment for generic/064 states that insert range is to be called
until 100 extents are created. Would the intent of your test be preserved if
it was modified to verify that 100 holes were inserted rather than 100
extents created? This would seem to be a more direct way to verify that
insert range was functioning correctly without assuming anything about other
test filesystem behavior. ext4 does create 100 holes for generic/064 with
nodelalloc set.
Thanks,
Eric
next reply other threads:[~2015-07-27 19:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-27 19:10 Eric Whitney [this message]
2015-07-27 21:51 ` generic/064 test failures on ext4 (4.2-rc*) Dave Chinner
2015-07-28 3:09 ` Theodore Ts'o
2015-08-03 2:01 ` Namjae Jeon
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=20150727190957.GA1606@localhost.localdomain \
--to=enwlinux@gmail.com \
--cc=a.sangwan@samsung.com \
--cc=linux-ext4@vger.kernel.org \
--cc=namjae.jeon@samsung.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).