All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Chao Yu <chao@kernel.org>
Cc: Jaegeuk Kim <jaegeuk@kernel.org>,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org,
	Satya Tangirala <satyaprateek2357@gmail.com>,
	Changheun Lee <nanich.lee@samsung.com>,
	Matthew Bobrowski <mbobrowski@mbobrowski.org>
Subject: Re: [PATCH 3/9] f2fs: rework write preallocations
Date: Tue, 27 Jul 2021 00:38:25 -0700	[thread overview]
Message-ID: <YP+38QzXS6kpLGn0@sol.localdomain> (raw)
In-Reply-To: <70f16fec-02f6-cb19-c407-856101cacc23@kernel.org>

On Tue, Jul 27, 2021 at 11:23:03AM +0800, Chao Yu wrote:
> > > 
> > > Do you have a proper explanation for why preallocations shouldn't be done in
> 
> See commit f847c699cff3 ("f2fs: allow out-place-update for direct IO in LFS mode"),
> f2fs_map_blocks() logic was changed to force allocating a new block address no matter
> previous block address was existed if it is called from write path of DIO. So, in such
> condition, if we preallocate new block address in f2fs_file_write_iter(), we will
> suffer the problem which my trace indicates.
> 
> > > this case?  Note that preallocations are still done for buffered writes, which
> > > may be out-of-place as well; how are those different?
> Got your concern.
> 
> For buffered IO, we use F2FS_GET_BLOCK_PRE_AIO, in this mode, we just preserve
> filesystem block count and tag NEW_ADDR in dnode block, so, it's fine, double
> new block address allocation won't happen during data page writeback.
> 
> For direct IO, we use F2FS_GET_BLOCK_PRE_DIO, in this mode, we will allocate
> physical block address, after preallocation, if we fallback to buffered IO, we
> may suffer double new block address allocation issue... IIUC.
> 
> Well, can we relocate preallocation into f2fs_direct_IO() after all cases which
> may cause fallbacking DIO to buffered IO?
> 

That's somewhat helpful, but I've been doing some more investigation and now I'm
even more confused.  How can f2fs support non-overwrite DIO writes at all
(meaning DIO writes in LFS mode as well as DIO writes to holes in non-LFS mode),
given that it has no support for unwritten extents?  AFAICS, as-is users can
easily leak uninitialized disk contents on f2fs by issuing a DIO write that
won't complete fully (or might not complete fully), then reading back the blocks
that got allocated but not written to.

I think that f2fs will have to take the ext2 approach of not allowing
non-overwrite DIO writes at all...

- Eric

WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: Chao Yu <chao@kernel.org>
Cc: Satya Tangirala <satyaprateek2357@gmail.com>,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-xfs@vger.kernel.org,
	Matthew Bobrowski <mbobrowski@mbobrowski.org>,
	Changheun Lee <nanich.lee@samsung.com>,
	linux-fsdevel@vger.kernel.org, Jaegeuk Kim <jaegeuk@kernel.org>
Subject: Re: [f2fs-dev] [PATCH 3/9] f2fs: rework write preallocations
Date: Tue, 27 Jul 2021 00:38:25 -0700	[thread overview]
Message-ID: <YP+38QzXS6kpLGn0@sol.localdomain> (raw)
In-Reply-To: <70f16fec-02f6-cb19-c407-856101cacc23@kernel.org>

On Tue, Jul 27, 2021 at 11:23:03AM +0800, Chao Yu wrote:
> > > 
> > > Do you have a proper explanation for why preallocations shouldn't be done in
> 
> See commit f847c699cff3 ("f2fs: allow out-place-update for direct IO in LFS mode"),
> f2fs_map_blocks() logic was changed to force allocating a new block address no matter
> previous block address was existed if it is called from write path of DIO. So, in such
> condition, if we preallocate new block address in f2fs_file_write_iter(), we will
> suffer the problem which my trace indicates.
> 
> > > this case?  Note that preallocations are still done for buffered writes, which
> > > may be out-of-place as well; how are those different?
> Got your concern.
> 
> For buffered IO, we use F2FS_GET_BLOCK_PRE_AIO, in this mode, we just preserve
> filesystem block count and tag NEW_ADDR in dnode block, so, it's fine, double
> new block address allocation won't happen during data page writeback.
> 
> For direct IO, we use F2FS_GET_BLOCK_PRE_DIO, in this mode, we will allocate
> physical block address, after preallocation, if we fallback to buffered IO, we
> may suffer double new block address allocation issue... IIUC.
> 
> Well, can we relocate preallocation into f2fs_direct_IO() after all cases which
> may cause fallbacking DIO to buffered IO?
> 

That's somewhat helpful, but I've been doing some more investigation and now I'm
even more confused.  How can f2fs support non-overwrite DIO writes at all
(meaning DIO writes in LFS mode as well as DIO writes to holes in non-LFS mode),
given that it has no support for unwritten extents?  AFAICS, as-is users can
easily leak uninitialized disk contents on f2fs by issuing a DIO write that
won't complete fully (or might not complete fully), then reading back the blocks
that got allocated but not written to.

I think that f2fs will have to take the ext2 approach of not allowing
non-overwrite DIO writes at all...

- Eric


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

  reply	other threads:[~2021-07-27  7:38 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-16 14:39 [PATCH 0/9] f2fs: use iomap for direct I/O Eric Biggers
2021-07-16 14:39 ` [f2fs-dev] " Eric Biggers
2021-07-16 14:39 ` [PATCH 1/9] f2fs: make f2fs_write_failed() take struct inode Eric Biggers
2021-07-16 14:39   ` [f2fs-dev] " Eric Biggers
2021-07-25 10:00   ` Chao Yu
2021-07-25 10:00     ` [f2fs-dev] " Chao Yu
2021-07-16 14:39 ` [PATCH 2/9] f2fs: remove allow_outplace_dio() Eric Biggers
2021-07-16 14:39   ` [f2fs-dev] " Eric Biggers
2021-07-19  8:41   ` Christoph Hellwig
2021-07-19  8:41     ` [f2fs-dev] " Christoph Hellwig
2021-07-16 14:39 ` [PATCH 3/9] f2fs: rework write preallocations Eric Biggers
2021-07-16 14:39   ` [f2fs-dev] " Eric Biggers
2021-07-25 10:50   ` Chao Yu
2021-07-25 10:50     ` [f2fs-dev] " Chao Yu
2021-07-25 17:57     ` Eric Biggers
2021-07-25 17:57       ` [f2fs-dev] " Eric Biggers
2021-07-27  2:00       ` Jaegeuk Kim
2021-07-27  2:00         ` [f2fs-dev] " Jaegeuk Kim
2021-07-27  3:23         ` Chao Yu
2021-07-27  3:23           ` [f2fs-dev] " Chao Yu
2021-07-27  7:38           ` Eric Biggers [this message]
2021-07-27  7:38             ` Eric Biggers
2021-07-27  8:30             ` Chao Yu
2021-07-27  8:30               ` [f2fs-dev] " Chao Yu
2021-07-27 15:33               ` Darrick J. Wong
2021-07-27 15:33                 ` [f2fs-dev] " Darrick J. Wong
2021-07-29  0:26                 ` Chao Yu
2021-07-29  0:26                   ` [f2fs-dev] " Chao Yu
2021-07-28  2:29         ` Jaegeuk Kim
2021-07-28  2:29           ` [f2fs-dev] " Jaegeuk Kim
2021-07-25 15:35   ` Jaegeuk Kim
2021-07-25 15:35     ` [f2fs-dev] " Jaegeuk Kim
2021-07-25 15:47     ` Jaegeuk Kim
2021-07-25 15:47       ` [f2fs-dev] " Jaegeuk Kim
2021-07-25 18:01       ` Eric Biggers
2021-07-25 18:01         ` [f2fs-dev] " Eric Biggers
2021-07-26 19:04         ` Jaegeuk Kim
2021-07-26 19:04           ` [f2fs-dev] " Jaegeuk Kim
2021-07-16 14:39 ` [PATCH 4/9] f2fs: reduce indentation in f2fs_file_write_iter() Eric Biggers
2021-07-16 14:39   ` [f2fs-dev] " Eric Biggers
2021-07-16 14:39 ` [PATCH 5/9] f2fs: fix the f2fs_file_write_iter tracepoint Eric Biggers
2021-07-16 14:39   ` [f2fs-dev] " Eric Biggers
2021-07-16 14:39 ` [PATCH 6/9] f2fs: implement iomap operations Eric Biggers
2021-07-16 14:39   ` [f2fs-dev] " Eric Biggers
2021-07-19  8:59   ` Christoph Hellwig
2021-07-19  8:59     ` [f2fs-dev] " Christoph Hellwig
2021-07-22 20:47     ` Jaegeuk Kim
2021-07-22 20:47       ` [f2fs-dev] " Jaegeuk Kim
2021-07-22 20:49       ` Jaegeuk Kim
2021-07-22 20:49         ` [f2fs-dev] " Jaegeuk Kim
2021-07-22 20:54       ` Eric Biggers
2021-07-22 20:54         ` [f2fs-dev] " Eric Biggers
2021-07-22 21:57         ` Jaegeuk Kim
2021-07-22 21:57           ` [f2fs-dev] " Jaegeuk Kim
2021-07-23  1:52     ` Eric Biggers
2021-07-23  1:52       ` [f2fs-dev] " Eric Biggers
2021-07-23  5:00       ` Christoph Hellwig
2021-07-23  5:00         ` [f2fs-dev] " Christoph Hellwig
2021-07-23  8:05         ` Eric Biggers
2021-07-23  8:05           ` [f2fs-dev] " Eric Biggers
2021-07-16 14:39 ` [PATCH 7/9] f2fs: use iomap for direct I/O reads Eric Biggers
2021-07-16 14:39   ` [f2fs-dev] " Eric Biggers
2021-07-16 14:39 ` [PATCH 8/9] f2fs: use iomap for direct I/O writes Eric Biggers
2021-07-16 14:39   ` [f2fs-dev] " Eric Biggers
2021-07-16 14:39 ` [PATCH 9/9] f2fs: remove f2fs_direct_IO() Eric Biggers
2021-07-16 14:39   ` [f2fs-dev] " Eric Biggers

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=YP+38QzXS6kpLGn0@sol.localdomain \
    --to=ebiggers@kernel.org \
    --cc=chao@kernel.org \
    --cc=jaegeuk@kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=mbobrowski@mbobrowski.org \
    --cc=nanich.lee@samsung.com \
    --cc=satyaprateek2357@gmail.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.