Re: [PATCH 0/6] block atomic writes for XFS

[Ritesh Harjani (IBM) <ritesh.list@gmail.com>]

John Garry <john.g.garry@oracle.com> writes:

> On 13/02/2024 07:45, Ritesh Harjani (IBM) wrote:
>> John Garry <john.g.garry@oracle.com> writes:
>> 
>>> This series expands atomic write support to filesystems, specifically
>>> XFS. Since XFS rtvol supports extent alignment already, support will
>>> initially be added there. When XFS forcealign feature is merged, then we
>>> can similarly support atomic writes for a non-rtvol filesystem.
>>>
>>> Flag FS_XFLAG_ATOMICWRITES is added as an enabling flag for atomic writes.
>>>
>>> For XFS rtvol, support can be enabled through xfs_io command:
>>> $xfs_io -c "chattr +W" filename
>>> $xfs_io -c "lsattr -v" filename
>>> [realtime, atomic-writes] filename
>> 
>> Hi John,
>> 
>> I first took your block atomic write patch series [1] and then applied this
>> series on top. I also compiled xfsprogs with chattr atomic write support from [2].
>> 
>> [1]: https://lore.kernel.org/linux-nvme/20240124113841.31824-1-john.g.garry@oracle.com/T/#m4ad28b480a8e12eb51467e17208d98ca50041ff2
>> [2]: https://github.com/johnpgarry/xfsprogs-dev/commits/atomicwrites/
>> 
>> 
>> But while setting +W attr, I see an Invalid argument error. Is there
>> anything I need to do first?
>> 
>> root@ubuntu:~# /root/xt/xfsprogs-dev/io/xfs_io -c "chattr +W" /mnt1/test/f1
>> xfs_io: cannot set flags on /mnt1/test/f1: Invalid argument
>> 
>> root@ubuntu:~# /root/xt/xfsprogs-dev/io/xfs_io -c "lsattr -v" /mnt1/test/f1
>> [realtime] /mnt1/test/f1
>
> Can you provide your full steps?
>
> I'm doing something like:
>
> # /mkfs.xfs -r rtdev=/dev/sdb,extsize=16k -d rtinherit=1 /dev/sda
> meta-data=/dev/sda               isize=512    agcount=4, agsize=22400 blks
>           =                       sectsz=512   attr=2, projid32bit=1
>           =                       crc=1        finobt=1, sparse=1, rmapbt=0
>           =                       reflink=0    bigtime=1 inobtcount=1 
> nrext64=0
> data     =                       bsize=4096   blocks=89600, imaxpct=25
>           =                       sunit=0      swidth=0 blks
> naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
> log      =internal log           bsize=4096   blocks=16384, version=2
>           =                       sectsz=512   sunit=0 blks, lazy-count=1
> realtime =/dev/sdb               extsz=16384  blocks=89600, rtextents=22400
> # mount /dev/sda mnt -o rtdev=/dev/sdb
> [    5.553482] XFS (sda): EXPERIMENTAL atomic writes feature in use. Use 
> at your own risk!

My bad, I missed to see your xfsprogs change involve setting this
feature flag as well during mkfs time itself. I wasn't using the right
mkfs utility.


> [    5.556752] XFS (sda): Mounting V5 Filesystem 
> 6e0820e6-4d44-4c3e-89f2-21b4d4480f88
> [    5.602315] XFS (sda): Ending clean mount
> #
> # touch mnt/file
> # /xfs_io -c "lsattr -v" mnt/file
> [realtime] mnt/file
> #
> #
> # /xfs_io -c "chattr +W" mnt/file
> # /xfs_io -c "lsattr -v" mnt/file
> [realtime, atomic-writes] mnt/file
>

Yup, this seems to work fine. Thanks!

> And then we can check limits:
>
> # /test-statx -a /root/mnt/file
> dump_statx results=9fff
>    Size: 0               Blocks: 0          IO Block: 16384   regular file
> Device: 08:00           Inode: 131         Links: 1
> Access: (0644/-rw-r--r--)  Uid:     0   Gid:     0
> Access: 2024-02-13 08:31:51.962900974+0000
> Modify: 2024-02-13 08:31:51.962900974+0000
> Change: 2024-02-13 08:31:51.969900974+0000
>   Birth: 2024-02-13 08:31:51.962900974+0000
> stx_attributes_mask=0x603070
>          STATX_ATTR_WRITE_ATOMIC set
>          unit min: 4096
>          unit max: 16384
>          segments max: 1
> Attributes: 0000000000400000 (........ ........ ........ ........ 
> ........ .?-..... ..--.... .---....)
> #
> #
>
> Does xfs_io have a statx function? If so, I can add support for atomic 
> writes for statx there. In the meantime, that test-statx code is also on 
> my branch, and can be run on the block device file (to sanity check that 
> the rtvol device supports atomic writes).
>
> Thanks,
> John