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@xxxxxxxxxx>
> Signed-off-by: Theodore Ts'o <tytso@xxxxxxx>
>
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
