Re: ext4 unkillable lseek.

[Theodore Ts'o <tytso@mit.edu>]

On Tue, Jan 12, 2016 at 02:17:43PM -0700, Andreas Dilger wrote:
> 
> It looks like ext4_es_find_delayed_extent_range() is being called once
> for every block in the file looking for any delalloc data, which is
> pretty awful.  Checking the git history for this code, it seems it was
> fixed once upon a time in commit 14516bb7bb:
> 
>     ext4: fix suboptimal seek_{data,hole} extents traversial
> 
>     It is ridiculous practice to scan inode block by block, this technique
>     applicable only for old indirect files. This takes significant amount
>     of time for really large files. Let's reuse ext4_fiemap which already
>     traverse inode-tree in most optimal meaner.
> 
>     TESTCASE:
>     ftruncate64(fd, 0);
>     ftruncate64(fd, 1ULL << 40);
>     /* lseek will spin very long time */
>     lseek64(fd, 0, SEEK_DATA);
>     lseek64(fd, 0, SEEK_HOLE);
> 
>     Original report: https://lkml.org/lkml/2014/10/16/620
> 
>     Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
>     Signed-off-by: Theodore Ts'o <tytso@mit.edu>
> 
> but it was later reverted in ad7fefb10 because of a problem with ext3 and
> never restored.

The relevant thread dates back to January 3, 2015 when it went
dead/dormant.  The last message from Dimitri was:

>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

We never did do that last bit, which is probably what we should do as
a short-term fix until we can debug the "fix suboptimal seek_{data,hole}
extents traversal" patch.

							- Ted