On Thu, Jan 11, 2024 at 09:55:36AM +0000, John Garry wrote:
> On 11/01/2024 05:02, Christoph Hellwig wrote:
>> On Wed, Jan 10, 2024 at 05:40:56PM -0800, Darrick J. Wong wrote:
>>> struct statx statx;
>>> struct fsxattr fsxattr;
>>> int fd = open('/foofile', O_RDWR | O_DIRECT);
>
> I'm assuming O_CREAT also.
Yes.
>> I think this still needs a check if the fs needs alignment for
>> atomic writes at all. i.e.
>>
>> struct statx statx;
>> struct fsxattr fsxattr;
>> int fd = open('/foofile', O_RDWR | O_DIRECT);
>>
>> ioctl(fd, FS_IOC_GETXATTR, &fsxattr);
>> statx(fd, "", AT_EMPTY_PATH, STATX_ALL | STATX_WRITE_ATOMIC, &statx);
>> if (statx.stx_atomic_write_unit_max < 16384) {
>> bailout();
>> }
>
> How could this value be >= 16384 initially? Would it be from pre-configured
> FS alignment, like XFS RT extsize? Or is this from some special CoW-based
> atomic write support? Or FS block size of 16384?
Sorry, this check should not be here at all, we should only check it
later.
> Incidentally, for consistency only setting FS_XFLAG_WRITE_ATOMIC will lead
> to FMODE_CAN_ATOMIC_WRITE being set. So until FS_XFLAG_WRITE_ATOMIC is set
> would it make sense to have statx return 0 for STATX_WRITE_ATOMIC.
True. We might need to report the limits even without that, though.
