All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Keith Busch <kbusch@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>, Keith Busch <kbusch@meta.com>,
	linux-nvme@lists.infradead.org, m@bjorling.me,
	matias.bjorling@wdc.com, kch@nvidia.com, kanie@linux.alibaba.com
Subject: Re: [PATCHv4 13/13] nvmet: report ns's vwc not present
Date: Mon, 11 Nov 2024 06:41:59 +0100	[thread overview]
Message-ID: <20241111054159.GA22853@lst.de> (raw)
In-Reply-To: <Zy45M1HRz8cKLPxf@kbusch-mbp>

On Fri, Nov 08, 2024 at 09:15:47AM -0700, Keith Busch wrote:
> > > +	if ((req->ns->file && !req->ns->buffered_io) ||
> > 
> > I don't think this check is correct.  Direct I/O still requires cache
> > flushes for durability.
> 
> Oh, right. Would it be sufficient to check the file's block device for
> write caching?
> 
> 	if ((req->ns->file && !req->ns->buffered_io &&
> 		bdev_write_cache(file_inode(req->ns->file)->i_sb->s_bdev))

No, that's wrong for two reasons:

 1) sb->s_bdev is only really relevant for mounting and st_dev reported
    in stat.  It might not relate to where the file data is placed at
    all
 2) the presence of cache in the underlying block device only has a
    minimal relation to the need to fdatasync a file you wrote to.
    Except for the corner case of overwritting a fully allocated (and
    not just preallocated) extent on an in-place write file system there
    always is metadata for a write that needs to be synchronized.
    You could work around that with an O_DYNC write that does that
    sync per I/O, but performance would be awful (and nvmet donsn't
    support that anyway)


  parent reply	other threads:[~2024-11-11  5:42 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-07 19:38 [PATCHv4 00/13] nvme target 2.1 and independent identify ns Keith Busch
2024-11-07 19:38 ` [PATCHv4 01/13] nvmet: implement id ns for nvm command set Keith Busch
2024-11-08 12:01   ` Matias Bjørling
2024-11-08 14:21   ` Christoph Hellwig
2024-11-07 19:38 ` [PATCHv4 02/13] nvmet: implement active command set ns list Keith Busch
2024-11-08 12:10   ` Matias Bjørling
2024-11-07 19:38 ` [PATCHv4 03/13] nvmet: implement supported log pages Keith Busch
2024-11-08 12:16   ` Matias Bjørling
2024-11-08 14:22   ` Christoph Hellwig
2024-11-11  1:57   ` Chaitanya Kulkarni
2024-11-07 19:38 ` [PATCHv4 04/13] nvmet: implement supported features log Keith Busch
2024-11-08 12:24   ` Matias Bjørling
2024-11-08 14:24   ` Christoph Hellwig
2024-11-07 19:38 ` [PATCHv4 05/13] nvmet: implement crto property Keith Busch
2024-11-08 12:34   ` Matias Bjørling
2024-11-07 19:38 ` [PATCHv4 06/13] nvmet: declare 2.1 version compliance Keith Busch
2024-11-08 12:37   ` Matias Bjørling
2024-11-07 19:38 ` [PATCHv4 07/13] nvmet: implement endurance groups Keith Busch
2024-11-08 14:26   ` Christoph Hellwig
2024-11-07 19:38 ` [PATCHv4 08/13] nvmet: implement rotational media information log Keith Busch
2024-11-07 19:38 ` [PATCHv4 09/13] nvmet: implement csi identify ns Keith Busch
2024-11-08  1:42   ` Guixin Liu
2024-11-08 14:26   ` Christoph Hellwig
2024-11-07 19:38 ` [PATCHv4 10/13] nvme: use command set independent id ns if available Keith Busch
2024-11-08 14:26   ` Christoph Hellwig
2024-11-07 19:38 ` [PATCHv4 11/13] nvme: add rotational support Keith Busch
2024-11-09 15:01   ` Guixin Liu
2024-11-07 19:38 ` [PATCHv4 12/13] nvme: check ns's volatile write cache not present Keith Busch
2024-11-07 19:38 ` [PATCHv4 13/13] nvmet: report ns's vwc " Keith Busch
2024-11-08 14:27   ` Christoph Hellwig
2024-11-08 16:15     ` Keith Busch
2024-11-09 14:59       ` Guixin Liu
2024-11-09 15:00         ` Guixin Liu
2024-11-12 22:49           ` Keith Busch
2024-11-13  1:51             ` Guixin Liu
2024-11-11  5:42         ` Christoph Hellwig
2024-11-11  5:41       ` Christoph Hellwig [this message]
2024-11-08 16:50 ` [PATCHv4 00/13] nvme target 2.1 and independent identify ns Keith Busch

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=20241111054159.GA22853@lst.de \
    --to=hch@lst.de \
    --cc=kanie@linux.alibaba.com \
    --cc=kbusch@kernel.org \
    --cc=kbusch@meta.com \
    --cc=kch@nvidia.com \
    --cc=linux-nvme@lists.infradead.org \
    --cc=m@bjorling.me \
    --cc=matias.bjorling@wdc.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.