On Wed, Jan 10, 2024 at 10:19:29AM +0100, Christoph Hellwig wrote:
> On Wed, Jan 10, 2024 at 10:04:00AM +1100, Dave Chinner wrote:
> > Hence history teaches us that we should be designing the API around
> > the generic filesystem function required (hard alignment of physical
> > extent allocation), not the specific use case that requires that
> > functionality.
>
> I disagree. The alignment requirement is an artefact of how you
> implement atomic writes. As the fs user I care that I can do atomic
> writes on a file and need to query how big the writes can be and
> what alignment is required.
>
> The forcealign feature is a sensible fs side implementation of that
> if using hardware based atomic writes with alignment requirements,
> but it is a really lousy userspace API.
>
> So with John's API proposal for XFS with hardware alignment based atomic
> writes we could still use force align.
>
> Requesting atomic writes for an inode will set the forcealign flag
> and the extent size hint, and after that it'll report atomic write
> capabilities. Roughly the same implementation, but not an API
> tied to an implementation detail.
Sounds good to me! So to summarize, this is approximately what
userspace programs would have to do something like this:
struct statx statx;
struct fsxattr fsxattr;
int fd = open('/foofile', O_RDWR | O_DIRECT);
ioctl(fd, FS_IOC_GETXATTR, &fsxattr);
fsxattr.fsx_xflags |= FS_XFLAG_FORCEALIGN | FS_XFLAG_WRITE_ATOMIC;
fsxattr.fsx_extsize = 16384; /* only for hardware no-tears writes */
ioctl(fd, FS_IOC_SETXATTR, &fsxattr);
statx(fd, "", AT_EMPTY_PATH, STATX_ALL | STATX_WRITE_ATOMIC, &statx);
if (statx.stx_atomic_write_unit_max >= 16384) {
pwrite(fd, &iov, 1, 0, RWF_SYNC | RWF_ATOMIC);
printf("HAPPY DANCE\n");
}
(Assume we bail out on errors.)
--D
