linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Damien Le Moal <Damien.LeMoal@wdc.com>
To: Dave Chinner <david@fromorbit.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 02:29:37 +0000	[thread overview]
Message-ID: <BYAPR04MB58165F4D55724B03EDED8E0DE71C0@BYAPR04MB5816.namprd04.prod.outlook.com> (raw)
In-Reply-To: 20200207002948.GC21953@dread.disaster.area

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.

> 
> Everything else looks OK to me.

Thanks !

> 
> Cheers,
> 
> Dave.
> 


-- 
Damien Le Moal
Western Digital Research

  reply	other threads:[~2020-02-07  2:29 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 [this message]
2020-02-07  3:49       ` Dave Chinner
2020-02-06  5:26 ` [PATCH v12 2/2] zonefs: Add documentation Damien Le Moal
2020-02-06 23:41   ` Dave Chinner
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=BYAPR04MB58165F4D55724B03EDED8E0DE71C0@BYAPR04MB5816.namprd04.prod.outlook.com \
    --to=damien.lemoal@wdc.com \
    --cc=Naohiro.Aota@wdc.com \
    --cc=darrick.wong@oracle.com \
    --cc=david@fromorbit.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 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).