[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b902bee1-fcfd-4542-8a4e-c6b9861828c9@oracle.com>
Date: Wed, 14 Feb 2024 12:36:40 +0000
From: John Garry <john.g.garry@...cle.com>
To: "Darrick J. Wong" <djwong@...nel.org>
Cc: hch@....de, viro@...iv.linux.org.uk, brauner@...nel.org,
dchinner@...hat.com, jack@...e.cz, chandan.babu@...cle.com,
martin.petersen@...cle.com, linux-kernel@...r.kernel.org,
linux-xfs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
tytso@....edu, jbongio@...gle.com, ojaswin@...ux.ibm.com
Subject: Re: [PATCH 6/6] fs: xfs: Set FMODE_CAN_ATOMIC_WRITE for
FS_XFLAG_ATOMICWRITES set
On 13/02/2024 17:59, Darrick J. Wong wrote:
>>> Shouldn't we check that the device supports AWU at all before turning on
>>> the FMODE flag?
>> Can we easily get this sort of bdev info here?
>>
>> Currently if we do try to issue an atomic write and AWU for the bdev is
>> zero, then XFS iomap code will reject it.
> Hmm. Well, if we move towards pushing all the hardware checks out of
> xfs/iomap and into whatever goes on underneath submit_bio then I guess
> we don't need to check device support here at all.
Yeah, I have been thinking about this. But I was still planning on
putting a "bdev on atomic write" check here, as you mentioned.
But is this a proper method to access the bdev for an xfs inode:
STATIC bool
xfs_file_can_atomic_write(
struct xfs_inode *inode)
{
struct xfs_buftarg *target = xfs_inode_buftarg(inode);
struct block_device *bdev = target->bt_bdev;
if (!xfs_inode_atomicwrites(inode))
return false;
return bdev_can_atomic_write(bdev);
}
I do notice the dax check in xfs_bmbt_to_iomap() when assigning
iomap->bdev, which is creating some doubt?
Thanks,
John
Powered by blists - more mailing lists