All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Gruenbacher <agruenba@redhat.com>
To: Jan Kara <jack@suse.cz>
Cc: Christoph Hellwig <hch@lst.de>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	linux-xfs@vger.kernel.org,
	linux-ext4 <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH 5/5] ext4: Switch to iomap for SEEK_HOLE / SEEK_DATA
Date: Tue, 29 Aug 2017 15:46:07 +0200	[thread overview]
Message-ID: <CAHc6FU5e7SaEtZGVRPWdnLBHZ72dqd-3JTOHjJsPMQ=mOe9ZbA@mail.gmail.com> (raw)
In-Reply-To: <20170725124511.GG19943@quack2.suse.cz>

Jan,

On Tue, Jul 25, 2017 at 2:45 PM, Jan Kara <jack@suse.cz> wrote:
> On Thu 29-06-17 06:54:20, Christoph Hellwig wrote:
>> @@ -3359,6 +3358,7 @@ static int ext4_iomap_begin(struct inode *inode, loff_t offset, loff_t length,
>>       unsigned long first_block = offset >> blkbits;
>>       unsigned long last_block = (offset + length - 1) >> blkbits;
>>       struct ext4_map_blocks map;
>> +     bool delalloc = false;
>>       int ret;
>>
>>       if (WARN_ON_ONCE(ext4_has_inline_data(inode)))
>> @@ -3369,6 +3369,27 @@ static int ext4_iomap_begin(struct inode *inode, loff_t offset, loff_t length,
>>
>>       if (!(flags & IOMAP_WRITE)) {
>>               ret = ext4_map_blocks(NULL, inode, &map, 0);
>> +             if (!ret) {
>> +                     struct extent_status es = {};
>> +
>> +                     ext4_es_find_delayed_extent_range(inode, map.m_lblk,
>> +                                     map.m_lblk + map.m_len - 1, &es);
>> +                     /* Is delalloc data before next block in extent tree? */
>> +                     if (es.es_len && es.es_lblk < map.m_lblk + map.m_len) {
>> +                             ext4_lblk_t offset = 0;
>> +
>> +                             if (es.es_lblk < map.m_lblk)
>> +                                     offset = map.m_lblk - es.es_lblk;
>> +                             map.m_lblk = es.es_lblk + offset;
>> +                             map.m_pblk = ext4_es_pblock(&es) + offset;
>
> This is wrong for delalloc extent - adding offset to some magic block
> value...

Right.

>> +                             map.m_len = es.es_len - offset;
>> +                             if (ext4_es_status(&es) & EXTENT_STATUS_UNWRITTEN)
>> +                                     map.m_flags |= EXT4_MAP_UNWRITTEN;
>> +                             if (ext4_es_status(&es) & EXTENT_STATUS_DELAYED)
>> +                                     delalloc = true;
>> +                             ret = 1;
>> +                     }
>> +             }
>
> Also the delalloc handling seems to be wrong that if we have file as:
>
> HD
>
> where H is hole, D is delalloc block, and iomap is called at offset 0, we
> should be getting back "hole at 0" back but instead you will return
> "delalloc at 1".
>
> We deal with a similar situation in ext4_da_map_blocks() so it would be
> good if we could reuse that one rather than reimplementing it here. But
> factoring the necessary functionality out isn't that easy.

I've tried to figure out where the issue might be, and I really don't see any.

It may be confusing that ext4_iomap_begin doesn't split up
IOMAP_UNWRITTEN maps into holes and data as ext4_find_unwritten_pgoff
did. This splitting is instead done generically in
iomap_seek_{hole,data} for IOMAP_UNWRITTEN maps using
page_cache_seek_hole_data.

I'll post an improved version of this patch queue shortly.

Thanks,
Andreas

  reply	other threads:[~2017-08-29 13:46 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-29 13:54 lseek SEEK_HOLE / SEEK_DATA fixes and switch to iomap V3.2-hch Christoph Hellwig
2017-06-29 13:54 ` [PATCH 1/5] xfs: remove a whitespace-only line from xfs_fs_get_nextdqblk Christoph Hellwig
2017-07-01  2:45   ` Darrick J. Wong
2017-06-29 13:54 ` [PATCH 2/5] vfs: Add page_cache_seek_hole_data helper Christoph Hellwig
2017-06-29 13:54 ` [PATCH 3/5] vfs: Add iomap_seek_hole and iomap_seek_data helpers Christoph Hellwig
2017-06-29 13:54 ` [PATCH 4/5] xfs: Switch to iomap for SEEK_HOLE / SEEK_DATA Christoph Hellwig
2017-06-29 13:54 ` [PATCH 5/5] ext4: " Christoph Hellwig
2017-06-30 11:51   ` Andreas Gruenbacher
2017-06-30 12:11     ` Andreas Gruenbacher
2017-06-30 17:37     ` Christoph Hellwig
2017-07-01  7:03       ` Darrick J. Wong
2017-07-02 15:24         ` Christoph Hellwig
2017-07-03 15:03       ` Andreas Gruenbacher
2017-07-03 16:21         ` Darrick J. Wong
2017-07-03 22:58           ` Dave Chinner
2017-07-07 21:27     ` Andreas Gruenbacher
2017-07-07 21:27     ` [PATCH v4 1/3] ext4: Add missing locking around iomap_seek_{hole,data} Andreas Gruenbacher
2017-07-12  9:17       ` Christoph Hellwig
2017-07-07 21:28     ` [PATCH v4 2/3] iomap: Switch from blkno to physical offset Andreas Gruenbacher
2017-07-12  9:20       ` Christoph Hellwig
2017-07-07 21:28     ` [PATCH v4 3/3] ext4: Add IOMAP_REPORT support for inline data Andreas Gruenbacher
2017-07-25 12:16       ` Jan Kara
2017-07-25 12:19         ` Andreas Gruenbacher
2017-07-25 12:45   ` [PATCH 5/5] ext4: Switch to iomap for SEEK_HOLE / SEEK_DATA Jan Kara
2017-08-29 13:46     ` Andreas Gruenbacher [this message]
2017-06-29 18:47 ` lseek SEEK_HOLE / SEEK_DATA fixes and switch to iomap V3.2-hch Darrick J. Wong
2017-06-29 18:53   ` Christoph Hellwig
2017-07-03 15:11     ` Andreas Gruenbacher

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='CAHc6FU5e7SaEtZGVRPWdnLBHZ72dqd-3JTOHjJsPMQ=mOe9ZbA@mail.gmail.com' \
    --to=agruenba@redhat.com \
    --cc=hch@lst.de \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    /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.