However - as we have seen with a trial user - it can create a problem if weSo currently, if we don't fallocate beforehand in xfs and the user
don't do that and we write 4K and then overwrite with a 16K atomic write to
a file, as 2x extents may be allocated for the complete 16K and it cannot be
issued as a single BIO.
tries to do the 16k overwrite to an offset having a 4k extent, how are
we handling it?
Here ext4 will return an error indicating atomic write can't happen at
this particular offset. The way I see it is if the user passes atomic
flag to pwritev2 and we are unable to ensure atomicity for any reason we
return error, which seems like a fair approach for a generic interface.
Yes, but its an mkfs time feature and it also applies to each an everyWe didn't want to overly restrict the users of atomic writes byDoesn't bigalloc already give you what you require here?
forcing
the extents to be of a certain alignment/size irrespective of the
size
of write. The design in this patchset provides this flexibility at
the
cost of some added precautions that the user should take (eg not
doing
an atomic write on a pre existing unaligned extent etc).
file which might not be desirable for all use cases.