On Wed, 30 Jul 2025, LongPing Wei wrote: > Hi, Mikulas > > For example: > > F2FS/EXT4 > ---- > dm-thin > ---- > dm-thin-pool > ---- > pool data > > 1. There is a block of testfile in F2FS/EXT4. > 2. The offset of this block is n. > 3. The position in the dm-thin device is m. > 4. The position in the pool data is x. > > The IV is only be affectted by offset in file and the ino of this file. > > Even if we change m by defrag or change x by COW, IV won't changed. > > The upper layer will only read the decrypted blocks with the same key and > continous IV in one bio. > > If the upper layer read the full chunk with mixed blocks for GC purpose, key > and IV won't be passed in. Then the upper layer just get the encrypted blocks. > > LongPing Wei Yes - so if the IV is calculated from inode and offset, it seems safe to support it on dm-thin. So, I accepted the patch (and increased the target version). BTW. what happens if someone uses FALLOC_FL_COLLAPSE_RANGE or FALLOC_FL_INSERT_RANGE on a file with inline encryption? That changes file offsets of existing data, so it should be disallowed when using inline encryption - but I don't see a test for this in the functions ext4_collapse_range and ext4_insert_range. Mikulas
