On Wed, May 26, 2021 at 11:20:37AM +0800, Eryu Guan wrote: > 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? ...and maybe a sample output of a seek_data/seek_hole scan between a gocryptfs file and the ext4fs underneath it? I'm still trying to wrap my head around what the problem here is. It might also help to describe where the 32 bytes of overhead goes -- are you interleaving the overhead inline with 4k of encrypted content? --D > > 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
