From: Dave Chinner <david@fromorbit.com>
To: Damien Le Moal <Damien.LeMoal@wdc.com>
Cc: "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Johannes Thumshirn <jth@kernel.org>,
Naohiro Aota <Naohiro.Aota@wdc.com>,
"Darrick J . Wong" <darrick.wong@oracle.com>,
Hannes Reinecke <hare@suse.de>
Subject: Re: [PATCH v12 1/2] fs: New zonefs file system
Date: Fri, 7 Feb 2020 14:49:35 +1100 [thread overview]
Message-ID: <20200207034935.GD21953@dread.disaster.area> (raw)
In-Reply-To: <BYAPR04MB58165F4D55724B03EDED8E0DE71C0@BYAPR04MB5816.namprd04.prod.outlook.com>
On Fri, Feb 07, 2020 at 02:29:37AM +0000, Damien Le Moal wrote:
> On 2020/02/07 9:29, Dave Chinner wrote:
> > On Thu, Feb 06, 2020 at 02:26:30PM +0900, Damien Le Moal wrote:
> >> zonefs is a very simple file system exposing each zone of a zoned block
> >> device as a file. Unlike a regular file system with zoned block device
> >> support (e.g. f2fs), zonefs does not hide the sequential write
> >> constraint of zoned block devices to the user. Files representing
> >> sequential write zones of the device must be written sequentially
> >> starting from the end of the file (append only writes).
> >
> > ....
> >> + if (flags & IOMAP_WRITE)
> >> + length = zi->i_max_size - offset;
> >> + else
> >> + length = min(length, isize - offset);
> >> + mutex_unlock(&zi->i_truncate_mutex);
> >> +
> >> + iomap->offset = offset & (~sbi->s_blocksize_mask);
> >> + iomap->length = ((offset + length + sbi->s_blocksize_mask) &
> >> + (~sbi->s_blocksize_mask)) - iomap->offset;
> >
> > iomap->length = __ALIGN_MASK(offset + length, sbi->s_blocksize_mask) -
> > iomap->offset;
> >
> > or it could just use ALIGN(..., sb->s_blocksize) and not need
> > pre-calculation of the mask value...
>
> Yes, that is cleaner. Fixed.
>
> >> +static ssize_t zonefs_file_dio_write(struct kiocb *iocb, struct iov_iter *from)
> >> +{
> >> + struct inode *inode = file_inode(iocb->ki_filp);
> >> + struct zonefs_sb_info *sbi = ZONEFS_SB(inode->i_sb);
> >> + struct zonefs_inode_info *zi = ZONEFS_I(inode);
> >> + size_t count;
> >> + ssize_t ret;
> >> +
> >> + /*
> >> + * For async direct IOs to sequential zone files, ignore IOCB_NOWAIT
> >> + * as this can cause write reordering (e.g. the first aio gets EAGAIN
> >> + * on the inode lock but the second goes through but is now unaligned).
> >> + */
> >> + if (zi->i_ztype == ZONEFS_ZTYPE_SEQ && !is_sync_kiocb(iocb)
> >> + && (iocb->ki_flags & IOCB_NOWAIT))
> >> + iocb->ki_flags &= ~IOCB_NOWAIT;
> >
> > Hmmm. I'm wondering if it would be better to return -EOPNOTSUPP here
> > so that the application knows it can't do non-blocking write AIO to
> > this file.
>
> I wondered the same too. In the end, I decided to go with silently ignoring
> the flag (for now) since raw block device accesses do the same (the NOWAIT
> support is not complete and IOs may wait on free tags). I have an idea for
> fixing simply the out-of-order issuing that may result from using nowait. I
> will send a patch for that later and can then remove this.
> But if zonefs does not make it to 5.6 (looking really tight), I will send
> add that patch to a new zonefs series rebased for 5.7.
THat seems reasonable to me.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2020-02-07 3:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-06 5:26 [PATCH v12 0/2] New zonefs file system Damien Le Moal
2020-02-06 5:26 ` [PATCH v12 1/2] fs: " Damien Le Moal
2020-02-07 0:29 ` Dave Chinner
2020-02-07 2:29 ` Damien Le Moal
2020-02-07 3:49 ` Dave Chinner [this message]
2020-02-06 5:26 ` [PATCH v12 2/2] zonefs: Add documentation Damien Le Moal
2020-02-06 23:41 ` Dave Chinner
-- strict thread matches above, loose matches on Subject: below --
2020-02-06 19:56 [PATCH v12 1/2] fs: New zonefs file system Markus Elfring
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=20200207034935.GD21953@dread.disaster.area \
--to=david@fromorbit.com \
--cc=Damien.LeMoal@wdc.com \
--cc=Naohiro.Aota@wdc.com \
--cc=darrick.wong@oracle.com \
--cc=hare@suse.de \
--cc=jth@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=torvalds@linux-foundation.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.