On Mon, Oct 15, 2018 at 09:51:00AM +0100, fdmanana@xxxxxxxxxx wrote: > From: Filipe Manana <fdmanana@xxxxxxxx> > > When using the NO_HOLES feature and logging a regular file, we were > expecting that if we find an inline extent, that either its size in ram > (uncompressed and unenconded) matches the size of the file or if it does > not, that it matches the sector size and it represents compressed data. > This assertion does not cover a case where the length of the inline extent > is smaller then the sector size and also smaller the file's size, such > case is possible through fallocate. Example: > > $ mkfs.btrfs -f -O no-holes /dev/sdb > $ mount /dev/sdb /mnt > > $ xfs_io -f -c "pwrite -S 0xb60 0 21" /mnt/foobar > $ xfs_io -c "falloc 40 40" /mnt/foobar > $ xfs_io -c "fsync" /mnt/foobar > > In the abobe example we trigger the assertion because the inline extent's > length is 21 bytes while the file size is 80 bytes. The fallocate() call > merely updated the file's size and did not touch the existing inline > extent, as expected. > > So fix this by adjusting the assertion so that an inline extent length > smaller then the file size is valid if the file size is smaller then the > filesystem's sector size. > > A test case for fstests follows soon. > > Reported-by: Anatoly Trosinenko <anatoly.trosinenko@xxxxxxxxx> > Link: https://lore.kernel.org/linux-btrfs/CAE5jQCfRSBC7n4pUTFJcmHh109=gwyT9mFkCOL+NKfzswmR=_Q@xxxxxxxxxxxxxx/ > Signed-off-by: Filipe Manana <fdmanana@xxxxxxxx> Added to misc-next, thanks.
