From: Jan Kara <jack@suse.cz>
To: Christoph Hellwig <hch@lst.de>
Cc: Andreas Gruenbacher <agruenba@redhat.com>,
Jan Kara <jack@suse.cz>,
linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org,
linux-ext4@vger.kernel.org
Subject: Re: [PATCH 5/5] ext4: Switch to iomap for SEEK_HOLE / SEEK_DATA
Date: Tue, 25 Jul 2017 14:45:11 +0200 [thread overview]
Message-ID: <20170725124511.GG19943@quack2.suse.cz> (raw)
In-Reply-To: <20170629135420.21357-6-hch@lst.de>
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...
> + 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.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2017-07-25 12:45 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 ` Jan Kara [this message]
2017-08-29 13:46 ` [PATCH 5/5] ext4: Switch to iomap for SEEK_HOLE / SEEK_DATA Andreas Gruenbacher
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=20170725124511.GG19943@quack2.suse.cz \
--to=jack@suse.cz \
--cc=agruenba@redhat.com \
--cc=hch@lst.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).