From: Goldwyn Rodrigues <rgoldwyn@suse.de>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: linux-fsdevel@vger.kernel.org, linux-btrfs@vger.kernel.org,
hch@infradead.org, nborisov@suse.com
Subject: Re: [PATCH 2/2] btrfs: Make btrfs_direct_write atomic with respect to inode_lock
Date: Wed, 16 Dec 2020 15:07:18 -0600 [thread overview]
Message-ID: <20201216210718.u2rklayhl5hir5sg@fiona> (raw)
In-Reply-To: <20201215221359.GA6911@magnolia>
On 14:13 15/12, Darrick J. Wong wrote:
> On Tue, Dec 15, 2020 at 12:06:36PM -0600, Goldwyn Rodrigues wrote:
> > From: Goldwyn Rodrigues <rgoldwyn@suse.com>
> >
> > btrfs_direct_write() fallsback to buffered write in case btrfs is not
> > able to perform or complete a direct I/O. During the fallback
> > inode lock is unlocked and relocked. This does not guarantee the
> > atomicity of the entire write since the lock can be acquired by another
> > write between unlock and relock.
> >
> > __btrfs_buffered_write() is used to perform the direct fallback write,
> > which performs the write without acquiring the lock or checks.
>
> Er... can you grab the inode lock before deciding which of the IO
> path(s) you're going to take? Then you'd always have an atomic write
> even if fallback happens.
No, since this is a fallback option which also works if the I/O is
incomplete.
>
> (Also vaguely wondering why this needs even more slicing and dicing of
> the iomap directio functions...)
I would most likely go with Dave's method of storing the flag in the
function and calling iomap dio functions without IOCB_DSYNC flag. This
way we don't have to change iomap.
--
Goldwyn
next prev parent reply other threads:[~2020-12-16 21:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-15 18:06 [PATCH v2 0/2] Fix locking for btrfs direct writes Goldwyn Rodrigues
2020-12-15 18:06 ` [PATCH 1/2] iomap: Separate out generic_write_sync() from iomap_dio_complete() Goldwyn Rodrigues
2020-12-15 21:24 ` kernel test robot
2020-12-15 21:24 ` kernel test robot
2020-12-15 22:16 ` Dave Chinner
2020-12-15 18:06 ` [PATCH 2/2] btrfs: Make btrfs_direct_write atomic with respect to inode_lock Goldwyn Rodrigues
2020-12-15 22:13 ` Darrick J. Wong
2020-12-16 21:07 ` Goldwyn Rodrigues [this message]
-- strict thread matches above, loose matches on Subject: below --
2020-12-16 1:06 kernel test robot
2020-12-08 18:42 [PATCH 0/2] Fix direct write with respect to inode locking Goldwyn Rodrigues
2020-12-08 18:42 ` [PATCH 2/2] btrfs: Make btrfs_direct_write atomic with respect to inode_lock Goldwyn Rodrigues
2020-12-10 8:52 ` Nikolay Borisov
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=20201216210718.u2rklayhl5hir5sg@fiona \
--to=rgoldwyn@suse.de \
--cc=darrick.wong@oracle.com \
--cc=hch@infradead.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=nborisov@suse.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.