From: Dmitry Monakhov <dmonakhov@openvz.org>
To: Theodore Ts'o <tytso@mit.edu>
Cc: linux-ext4@vger.kernel.org
Subject: Re: [PATCH 4/4] ext4: fix suboptimal seek_{data,hole} extents traversial
Date: Sat, 03 Jan 2015 23:16:14 +0400 [thread overview]
Message-ID: <87zj9zzncx.fsf@openvz.org> (raw)
In-Reply-To: <20150102200301.GC10927@thunk.org>
Theodore Ts'o <tytso@mit.edu> writes:
> On Sun, Dec 28, 2014 at 11:13:10PM -0500, Theodore Ts'o wrote:
>> On Sun, Dec 28, 2014 at 10:55:46PM +0400, Dmitry Monakhov wrote:
>> > Yes. I've already sent you updated patches
>> > https://patchwork.ozlabs.org/patch/422594/
>> > https://patchwork.ozlabs.org/patch/422595/
>>
>> Thanks, this somehow got lost from my inbox. I'm not sure how it
>> happened, but I do see it in patchwork.
>
> I tried applying both of these patches, but I'm still seeing a failure:
>
> % git log --oneline -2
> e195ba5 ext4: fix seek_data for indirect layout
> dd634e3 ext4: fix seek_data cleanup
>
> # uname -a
> Linux kvm-xfstests 3.18.0-rc3-00003-ge195ba5 #2548 SMP Fri Jan 2 14:35:32 EST 2015 i686 GNU/Linux
> # mke2fs -t ext4 -O ^extent,^flex_bg,^uninit_bg -Fq /dev/vdd
> /dev/vdd contains a ext4 file system
> last mounted on /vdd on Fri Jan 2 14:49:58 2015
> # mount -t ext4 -o nodelalloc /dev/vdd /vdd
> # xfstests/src/seek_sanity_test /vdd/seek_sanity_testfile
> File system magic#: 0xef53
> Allocation size: 4096
>
> ...
> 10. Test a huge file for offset overflow
> 10.01 SEEK_HOLE expected 65536 or 0, got 0. FAIL
> 10.02 SEEK_HOLE expected 65536 or 0, got 1. FAIL
> 10.03 SEEK_DATA expected 0 or 0, got -1. FAIL
> 10.04 SEEK_DATA expected 1 or 1, got -1. FAIL
> 10.05 SEEK_HOLE expected 0 or 0, got -65536. FAIL
> 10.06 SEEK_DATA expected -65536 or -65536, got -1. FAIL
> 10.07 SEEK_DATA expected -65535 or -65535, got -1. FAIL
> 10.08 SEEK_DATA expected -65536 or -65536, got -1. FAIL
>
> I'm getting the exact same failure with a kernel compiled with
>
> # CONFIG_EXT3_FS is not set
> CONFIG_EXT4_USE_FOR_EXT23=y
>
> and then using "mke2fs -t ext3 -Fq /dev/vdd" and "mount -t ext3
> /dev/vdd /vdd" and I'm seeing the same failure. Which really worries
> me, since that's something that many more users will be using.
>
> At this point I'm beginning to think that we would be better off
> reverting 14516bb7bb6 until we can figure out what is going on. I'm
> really wondering why you're not seeing this failure, but I am.
Crap. I do not understand why I cant not reproduce this.
I'm out of my normal dev environment for couple of days,
so patch reverting looks reasonable. But please add code which
break the loop on signal because otherwise this result in DOS for huge file
#touch file
#truncate -s 1T file
#./seek_hole file
>
> - Ted
next prev parent reply other threads:[~2015-01-03 19:16 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-02 11:00 [PATCH 1/4] ext4: fix potential use after free during resize V2 Dmitry Monakhov
2014-12-02 11:00 ` [PATCH 2/4] ext4: prevent fsreentrance deadlock for inline_data Dmitry Monakhov
2014-12-02 23:07 ` Theodore Ts'o
2014-12-02 11:00 ` [PATCH 3/4] ext4: ext4_inline_data_fiemap should respect callers argument Dmitry Monakhov
2014-12-02 23:07 ` Theodore Ts'o
2014-12-02 11:00 ` [PATCH 4/4] ext4: fix suboptimal seek_{data,hole} extents traversial Dmitry Monakhov
2014-12-02 23:07 ` Theodore Ts'o
2014-12-11 20:05 ` Theodore Ts'o
2014-12-12 8:52 ` Dmitry Monakhov
2014-12-17 3:57 ` Theodore Ts'o
2014-12-17 15:06 ` Dmitry Monakhov
2014-12-18 2:39 ` Theodore Ts'o
2014-12-27 15:39 ` Theodore Ts'o
2014-12-28 18:55 ` Dmitry Monakhov
2014-12-29 4:13 ` Theodore Ts'o
2015-01-02 20:03 ` Theodore Ts'o
2015-01-03 19:16 ` Dmitry Monakhov [this message]
2014-12-02 11:12 ` [PATCH 1/4] ext4: fix potential use after free during resize V2 Dmitry Monakhov
2014-12-02 23:06 ` Theodore Ts'o
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=87zj9zzncx.fsf@openvz.org \
--to=dmonakhov@openvz.org \
--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.