On Sun, May 23, 2021 at 11:05 AM Eryu Guan <guan@xxxxxxx> wrote: > The total read length should be > > "The length of this extent is (hole_off - data_off)" > > according to the comments above do_extent_copy(). Total read length > being not a multiple of 4k means 'data_off' or 'hole_off' is not 4k > aligned. That is correct. > But generic/286 creates source files with length of all data extents and > hole extents being multiple of 4k. So I still don't understand why this > is valid for gocryptfs. Shouldn't that be a bug in seek_data/seek_hole > in gocryptfs? Could you please elaborate? Yes sure, the situation is a bit complicated. gocryptfs works similar to eCryptFS and EncFS (also overlay filesystems). The files are stored in encrypted form in regular files on ext4 or xfs or whatever "real disk" filesystem. Disk space allocation & file holes are handled by the real filesystem. A gocryptfs mount shows a decrypted view of these files. Now, gocryptfs uses AES-GCM for encryption. This adds 32 bytes of overhead to every 4096-byte block, which gives a storage size of 4128 bytes. The encryption overhead is why the files & holes created by generic/286 are not 4k-aligned on disk when viewed through the gocryptfs mount. Thanks, Jakob
