On Tue, May 25, 2021 at 07:34:14PM +0200, Jakob Unterwurzacher wrote: > 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. Ah, that makes sense to me now. Would you please include the detailed explaination in commit log as well? Thanks, Eryu > > 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
