From: "hch@infradead.org" <hch@infradead.org>
To: Damien Le Moal <Damien.LeMoal@wdc.com>
Cc: "hch@infradead.org" <hch@infradead.org>,
Johannes Thumshirn <Johannes.Thumshirn@wdc.com>,
Jens Axboe <axboe@kernel.dk>,
linux-block <linux-block@vger.kernel.org>,
Keith Busch <kbusch@kernel.org>,
"linux-scsi @ vger . kernel . org" <linux-scsi@vger.kernel.org>,
"Martin K . Petersen" <martin.petersen@oracle.com>,
"linux-fsdevel @ vger . kernel . org"
<linux-fsdevel@vger.kernel.org>,
"Darrick J . Wong" <darrick.wong@oracle.com>
Subject: Re: [PATCH v2 10/11] iomap: Add support for zone append writes
Date: Tue, 24 Mar 2020 23:25:50 -0700 [thread overview]
Message-ID: <20200325062550.GA19666@infradead.org> (raw)
In-Reply-To: <CO2PR04MB2343309246F0D413F5C1691CE7CE0@CO2PR04MB2343.namprd04.prod.outlook.com>
On Wed, Mar 25, 2020 at 05:27:38AM +0000, Damien Le Moal wrote:
> > At least for a normal file system that is absolutely not true. If
> > zonefs is so special it might be better of just using a slightly tweaked
> > copy of blkdev_direct_IO rather than using iomap.
>
> It would be very nice to not have to add this direct BIO use case in zonefs
> since that would be only for writes to sequential zones while all other
> operations use iomap. So instead of this, what about using a flag as Dave
> suggested (see below comment too) ?
Given how special the use case is I'm not sure overloading iomap
is a good idea. Think of how a "normal" zone aware file system would
use iomap and not of this will apply. OTOH the "simple" single bio
code in __blkdev_direct_IO_simple is less than 100 lines of code. I
think having a specialized code base for a specialized use case
might be better than overloading generic code with tons of flags.
> > I don't think the iocb is the right interface for passing this
> > kind of information. We currently pass a bool wait to iomap_dio_rw
> > which really should be flags. I have a pending patch for that.
>
> Is that patch queued in iomap or xfs tree ? Could you point us to it please ?
It isn't queued up anywhere yet.
next prev parent reply other threads:[~2020-03-25 6:25 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-24 15:24 [PATCH v2 00/11] Introduce Zone Append for writing to zoned block devices Johannes Thumshirn
2020-03-24 15:24 ` [PATCH v2 01/11] block: factor out requeue handling from dispatch code Johannes Thumshirn
2020-03-25 8:40 ` Christoph Hellwig
2020-03-25 15:40 ` Jens Axboe
2020-03-24 15:24 ` [PATCH v2 02/11] block: provide fallbacks for blk_queue_zone_is_seq and blk_queue_zone_no Johannes Thumshirn
2020-03-24 15:24 ` [PATCH v2 03/11] block: Introduce REQ_OP_ZONE_APPEND Johannes Thumshirn
2020-03-24 16:07 ` Johannes Thumshirn
2020-03-25 16:24 ` Johannes Thumshirn
2020-03-24 15:24 ` [PATCH v2 04/11] block: introduce blk_req_zone_write_trylock Johannes Thumshirn
2020-03-24 15:24 ` [PATCH v2 05/11] block: Introduce zone write pointer offset caching Johannes Thumshirn
2020-03-24 15:24 ` [PATCH v2 06/11] scsi: sd_zbc: factor out sanity checks for zoned commands Johannes Thumshirn
2020-03-24 15:24 ` [PATCH v2 07/11] scsi: sd_zbc: emulate ZONE_APPEND commands Johannes Thumshirn
2020-03-24 15:24 ` [PATCH v2 08/11] null_blk: Cleanup zoned device initialization Johannes Thumshirn
2020-03-24 15:24 ` [PATCH v2 09/11] null_blk: Support REQ_OP_ZONE_APPEND Johannes Thumshirn
2020-03-24 15:24 ` [PATCH v2 10/11] iomap: Add support for zone append writes Johannes Thumshirn
2020-03-24 15:41 ` Christoph Hellwig
2020-03-25 5:27 ` Damien Le Moal
2020-03-25 6:25 ` hch [this message]
2020-03-25 9:45 ` Johannes Thumshirn
2020-03-25 9:48 ` hch
2020-03-25 9:54 ` Johannes Thumshirn
2020-03-25 9:59 ` Damien Le Moal
2020-03-25 10:01 ` hch
2020-03-25 10:15 ` Johannes Thumshirn
2020-03-24 22:45 ` Dave Chinner
2020-03-25 5:38 ` Damien Le Moal
2020-03-25 8:32 ` Johannes Thumshirn
2020-03-24 15:24 ` [PATCH v2 11/11] zonefs: use zone-append for sequential zones Johannes Thumshirn
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=20200325062550.GA19666@infradead.org \
--to=hch@infradead.org \
--cc=Damien.LeMoal@wdc.com \
--cc=Johannes.Thumshirn@wdc.com \
--cc=axboe@kernel.dk \
--cc=darrick.wong@oracle.com \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
/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.