On Mon, Dec 04, 2023 at 03:19:15PM +0000, John Garry wrote: > On 04/12/2023 13:45, Christoph Hellwig wrote: >> On Tue, Nov 28, 2023 at 05:42:10PM +0000, John Garry wrote: >>> ok, fine, it would not be required for XFS with CoW. Some concerns still: >>> a. device atomic write boundary, if any >>> b. other FSes which do not have CoW support. ext4 is already being used for >>> "atomic writes" in the field - see dubious amazon torn-write prevention. >> >> What is the 'dubious amazon torn-write prevention'? > > https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/storage-twp.html > > AFAICS, this is without any kernel changes, so no guarantee of unwanted > splitting or merging of bios. > > Anyway, there will still be !CoW FSes which people want to support. Ugg, so they badly reimplement NVMe atomic write support and use it without software stack enablement. Calling it dubious is way to gentle.. >> Relying just on the hardware seems very limited, especially as there is >> plenty of hardware that won't guarantee anything larger than 4k, and >> plenty of NVMe hardware without has some other small limit like 32k >> because it doesn't support multiple atomicy mode. > > So what would you propose as the next step? Would it to be first achieve > atomic write support for XFS with HW support + CoW to ensure contiguous > extents (and without XFS forcealign)? I think the very first priority is just block device support without any fs enablement. We just need to make sure the API isn't too limited for additional use cases. > Ignoring FSes, then how is this supposed to work for block devices? We just > always need HW support, right? Yes.
