From: Christoph Hellwig <hch@infradead.org>
To: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Cc: Christoph Hellwig <hch@infradead.org>,
linux-fsdevel@vger.kernel.org,
Johannes Thumshirn <johannes.thumshirn@wdc.com>
Subject: Re: [PATCH 3/3] zonefs: fix zonefs_iomap_begin() for reads
Date: Tue, 7 Jun 2022 03:09:43 -0700 [thread overview]
Message-ID: <Yp8j53irZalw6mlH@infradead.org> (raw)
In-Reply-To: <48ea1d34-6992-f85d-c763-d817cd32cca4@opensource.wdc.com>
On Tue, Jun 07, 2022 at 03:53:35PM +0900, Damien Le Moal wrote:
> >> + else if (offset < isize)
> >> length = min(length, isize - offset);
> >
> > So you still report an IOMAP_UNWRITTEN extent for the whole size of
> > the requst past EOF? Looking at XFS we do return the whole requested
> > length, but do return it as HOLE. Maybe we need to clarify the behavior
> > here and document it.
>
> Yes, I checked xfs and saw that. But in zonefs case, since the file blocks are
> always preallocated, blocks after the write pointer are indeed UNWRITTEN. I did
> check that iomap read processing treats UNWRITTEN and HOLE similarly, that is,
> ignore the value of length and stop issuing IOs when either type is seen. But I
> may have missed something.
>
> Note that initially I wrote the patch below to fix the problem. But it is very
> large and should probably be a cleanup for the next cycle. It separates the
> begin op for read and write, which makes things easier to understand.
I much prefer this more extensive fix.
next prev parent reply other threads:[~2022-06-07 10:10 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-03 11:49 [PATCH 0/3] zonefs fixes Damien Le Moal
2022-06-03 11:49 ` [PATCH 1/3] zonefs: fix handling of explicit_open option on mount Damien Le Moal
2022-06-07 6:01 ` Christoph Hellwig
2022-06-07 8:46 ` Johannes Thumshirn
2022-06-03 11:49 ` [PATCH 2/3] zonefs: Do not ignore explicit_open with active zone limit Damien Le Moal
2022-06-07 6:02 ` Christoph Hellwig
2022-06-03 11:49 ` [PATCH 3/3] zonefs: fix zonefs_iomap_begin() for reads Damien Le Moal
2022-06-07 6:09 ` Christoph Hellwig
2022-06-07 6:53 ` Damien Le Moal
2022-06-07 10:09 ` Christoph Hellwig [this message]
2022-06-07 10:25 ` Damien Le Moal
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=Yp8j53irZalw6mlH@infradead.org \
--to=hch@infradead.org \
--cc=damien.lemoal@opensource.wdc.com \
--cc=johannes.thumshirn@wdc.com \
--cc=linux-fsdevel@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.