3 ms·

> Does it do anything to ensure data integrity, like journaling does? What kind of journaling though? By default ext4 only uses journaling for metadata updates

> Does it do anything to ensure data integrity, like journaling does? What kind of journaling though? By default ext4 only uses journaling for metadata updates, not data updates (see "ordered" mode in ext4(5)). So if you have a (e.g.) 1000MB file, and you update 200MB in the middle of it, you can have a situation where the first 100MB is written out and the system dies with the other 100MB vanishing. With a CoW, if the second 100MB is not written out and the file sync'd, then on system recovery you're back to the original file being completely intact. With ext4 in the default configuration you have a file that has both new-100MB and stale-100MB in the middle of it. The updating of the file data and the metadata are two separate steps (by default) in ext4: * https://www.baeldung.com/linux/ext-journal-modes https://www.baeldung.com/linux/ext-journal-modes * https://michael.kjorling.se/blog/2024/ext4-defaulting-to-data-ordered/ https://michael.kjorling.se/blog/2024/ext4-defaulting-to-dat... * https://fy.blackhats.net.au/blog/2024-08-13-linux-filesystems/ https://fy.blackhats.net.au/blog/2024-08-13-linux-filesystem... Whereas with a proper CoW (like ZFS), updates are ACID.

ryao 1y ago
Large file writes are an exception in ZFS. They are broken into multiple transactions, which can go into multiple transaction groups, such that the updates are not ACID. You can see this in the code here: https://github.com/openzfs/zfs/blob/6af8db61b1ea489ade2d5344f4ae5f09c3d9faad/module/zfs/zfs_vnops.c#L789 https://github.com/openzfs/zfs/blob/6af8db61b1ea489ade2d5344... Small writes on ZFS are ACID. If ZFS made large writes ACID, large writes could block the transaction group commit for arbitrarily long periods, which is why it does not. Just imagine writing a 1PB file. It would likely take a long time (days?) and it is just not reasonable to block the transaction group commit until it finishes. That said, for your example, you will often have all of the writes go into the same transaction group commit, such that it becomes ACID, but this is not a strict guarantee. The maximum atomic write size on ZFS is 32MB, assuming alignment. If the write is not aligned to the record size, it will be smaller, as per: https://github.com/openzfs/zfs/blob/6af8db61b1ea489ade2d5344f4ae5f09c3d9faad/module/zfs/zfs_vnops.c#L845 https://github.com/openzfs/zfs/blob/6af8db61b1ea489ade2d5344...

ryao 1y ago

Large file writes are an exception in ZFS. They are broken into multiple transactions, which can go into multiple transaction groups, such that the updates are not ACID. You can see this in the code here: https://github.com/openzfs/zfs/blob/6af8db61b1ea489ade2d5344f4ae5f09c3d9faad/module/zfs/zfs_vnops.c#L789 https://github.com/openzfs/zfs/blob/6af8db61b1ea489ade2d5344... Small writes on ZFS are ACID. If ZFS made large writes ACID, large writes could block the transaction group commit for arbitrarily long periods, which is why it does not. Just imagine writing a 1PB file. It would likely take a long time (days?) and it is just not reasonable to block the transaction group commit until it finishes. That said, for your example, you will often have all of the writes go into the same transaction group commit, such that it becomes ACID, but this is not a strict guarantee. The maximum atomic write size on ZFS is 32MB, assuming alignment. If the write is not aligned to the record size, it will be smaller, as per: https://github.com/openzfs/zfs/blob/6af8db61b1ea489ade2d5344f4ae5f09c3d9faad/module/zfs/zfs_vnops.c#L845 https://github.com/openzfs/zfs/blob/6af8db61b1ea489ade2d5344...