Re: ext4 unkillable lseek.

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 [off-list ref]
    Signed-off-by: Theodore Ts'o [off-list ref]

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