[PATCH] Btrfs: fix race between balance and unused block group deletion

From: Filipe Manana fdman...@suse.com We have a race between deleting an unused block group and balancing the same block group that leads to an assertion failure/BUG(), producing the following assertion failure/BUG_ON(): [181631.208236] BTRFS: assertion failed: 0, file: fs/btrfs/volumes.c, line:

[PATCH] Btrfs: fix a comment in inode.c:evict_inode_truncate_pages()

From: Filipe Manana fdman...@suse.com The comment was not correct about the part where it says the endio callback of the bio might have not yet been called - update it to mention that by that time the endio callback execution might still be in progress only. Signed-off-by: Filipe Manana

[PATCH v2] Btrfs: fix fsync xattr loss in the fast fsync path

From: Filipe Manana fdman...@suse.com After commit 4f764e515361 (Btrfs: remove deleted xattrs on fsync log replay), we can end up in a situation where during log replay we end up deleting xattrs that were never deleted when their file was last fsynced. This happens in the fast fsync path (flag

[PATCH v2] fstests: shared test for fsync after adding xattrs to a file

From: Filipe Manana fdman...@suse.com This test is motivated by an issue found in btrfs. It test that after syncing the filesystem, adding many xattrs to a file, syncing the filesystem again, writing to the file and then doing a fsync against that file, all the xattrs still exists after a power

[PATCH v3] Btrfs: fix fsync xattr loss in the fast fsync path

From: Filipe Manana fdman...@suse.com After commit 4f764e515361 (Btrfs: remove deleted xattrs on fsync log replay), we can end up in a situation where during log replay we end up deleting xattrs that were never deleted when their file was last fsynced. This happens in the fast fsync path (flag

[PATCH] Btrfs: fix shrinking truncate when the no_holes feature is enabled

From: Filipe Manana fdman...@suse.com If the no_holes feature is enabled, we attempt to shrink a file to a size that ends up in the middle of a hole and we don't have any file extent items in the fs/subvol tree that go beyond the new file size (or any ordered extents that will insert such file

[PATCH] Btrfs: fix fsync after truncate when no_holes feature is enabled

From: Filipe Manana fdman...@suse.com When we have the no_holes feature enabled, if a we truncate a file to a smaller size, truncate it again but to a size greater than or equals to its original size and fsync it, the log tree will not have any information about the hole covering the range

[PATCH] fstests: generic test for truncating a file into the middle of a hole

From: Filipe Manana fdman...@suse.com Test that after truncating a file into the middle of a hole causes the new size of the file to be persisted after a clean unmount of the filesystem (or after the inode is evicted). This is for the case where all the data following the hole is not yet durably

[PATCH] fstests: generic test for fsync after file truncations

From: Filipe Manana fdman...@suse.com Test that if we truncate a file to a smaller size, then truncate it to its original size or a larger size, then fsyncing it and a power failure happens, the file will have the range [first_truncate_size, last_size[ with all bytes having a value of 0x00 if we

[PATCH v2] fstests: generic test for fsync after file truncations

From: Filipe Manana fdman...@suse.com Test that if we truncate a file to a smaller size, then truncate it to its original size or a larger size, then fsyncing it and a power failure happens, the file will have the range [first_truncate_size, last_size[ with all bytes having a value of 0x00 if we

[PATCH v2] Btrfs: fix race between balance and unused block group deletion

From: Filipe Manana fdman...@suse.com We have a race between deleting an unused block group and balancing the same block group that leads to an assertion failure/BUG(), producing the following trace: [181631.208236] BTRFS: assertion failed: 0, file: fs/btrfs/volumes.c, line: 2622 [181631.220591]

[PATCH 2/2] Btrfs: fix race between caching kthread and returning inode to inode cache

From: Filipe Manana fdman...@suse.com While the inode cache caching kthread is calling btrfs_unpin_free_ino(), we could have a concurrent call to btrfs_return_ino() that adds a new entry to the root's free space cache of pinned inodes. This concurrent call does not acquire the

[PATCH 1/2] Btrfs: use kmem_cache_free when freeing entry in inode cache

From: Filipe Manana fdman...@suse.com The free space entries are allocated using kmem_cache_zalloc(), through __btrfs_add_free_space(), therefore we should use kmem_cache_free() and not kfree() to avoid any confusion and any potential problem. Looking at the kfree() definition at mm/slab.c it has

[PATCH] Btrfs: fix crash on close_ctree() if cleaner starts new transaction

From: Filipe Manana fdman...@suse.com Often when running fstests btrfs/079 I was running into the following trace during umount on one of my qemu/kvm test vms: [ 8245.682441] WARNING: CPU: 8 PID: 25064 at fs/btrfs/extent-tree.c:138 btrfs_put_block_group+0x51/0x69 [btrfs]() [ 8245.685039]

[PATCH] Btrfs-progs: add feature to get mininum size for resizing a fs/device

From: Filipe Manana fdman...@suse.com Currently there is not way for a user to know what is the minimum size a device of a btrfs filesystem can be resized to. Sometimes the value of total allocated space (sum of all allocated chunks/device extents), which can be parsed from 'btrfs filesystem

[PATCH] fstests: generic test for fsync after adding xattr to a file

From: Filipe Manana fdman...@suse.com This test is motivated by an issue found in btrfs. It tests that after syncing the filesystem, adding a xattr to a file, syncing the filesystem again, writing to the file and then doing a fsync against that file, the xattr still exists after a power failure.

[PATCH] Btrfs: fix fsync xattr loss in the fast fsync path

From: Filipe Manana fdman...@suse.com After commit 4f764e515361 (Btrfs: remove deleted xattrs on fsync log replay), we can end up in a situation where during log replay we end up deleting xattrs that were never deleted when their file was last fsynced. This happens in the fast fsync path (flag

[PATCH] Btrfs: fix fsync data loss after append write

From: Filipe Manana fdman...@suse.com If we do an append write to a file (which increases its inode's i_size) that does not have the flag BTRFS_INODE_NEEDS_FULL_SYNC set in its inode, and the previous transaction added a new hard link to the file, which sets the flag BTRFS_INODE_COPY_EVERYTHING

[PATCH] fstests: generic test for fsync after adding hard link to a file

From: Filipe Manana fdman...@suse.com This test is motivated by an issue found in btrfs. It tests that after syncing the filesystem, adding a hard link to a file, syncing the filesystem again, doing a write to the file that increases its size and then doing a fsync against that file, durably

[PATCH] Btrfs: check pending chunks when shrinking fs to avoid corruption

From: Filipe Manana fdman...@suse.com When we shrink the usable size of a device (its total_bytes), we go over all the device extent items in the device tree and attempt to relocate the chunk of any device extent that goes beyond the new usable size for the device. We do that after setting the

[PATCH v3] Btrfs: fix memory corruption on failure to submit bio for direct IO

From: Filipe Manana fdman...@suse.com If we fail to submit a bio for a direct IO request, we were grabbing the corresponding ordered extent and decrementing its reference count twice, once for our lookup reference and once for the ordered tree reference. This was a problem because it caused the

[PATCH] Btrfs: fix memory corruption on failure to submit bio for direct IO

From: Filipe Manana fdman...@suse.com If we fail to submit a bio for a direct IO request, we were grabbing the corresponding ordered extent and decrementing its reference count twice, once for our lookup reference and once for the ordered tree reference. This was a problem because it caused the

[PATCH] Btrfs: fix list transaction-pending_ordered corruption

From: Filipe Manana fdman...@suse.com When we call btrfs_commit_transaction(), we splice the list ordered of our transaction handle into the transaction's pending_ordered list, but we don't reinitialize the ordered list of our transaction handle, this means it still points to the same elements it

[PATCH v2] Btrfs-progs: add feature to get mininum size for resizing a fs/device

From: Filipe Manana fdman...@suse.com Currently there is not way for a user to know what is the minimum size a device of a btrfs filesystem can be resized to. Sometimes the value of total allocated space (sum of all allocated chunks/device extents), which can be parsed from 'btrfs filesystem

[PATCH] Btrfs: fix memory leak in the extent_same ioctl

From: Filipe Manana fdman...@suse.com We were allocating memory with memdup_user() but we were never releasing that memory. This affected pretty much every call to the ioctl, whether it deduplicated extents or not. This issue was reported on IRC by Julian Taylor and on the mailing list by Marcel

[PATCH v2] Btrfs: fix memory leak in the extent_same ioctl

From: Filipe Manana fdman...@suse.com We were allocating memory with memdup_user() but we were never releasing that memory. This affected pretty much every call to the ioctl, whether it deduplicated extents or not. This issue was reported on IRC by Julian Taylor and on the mailing list by Marcel

[PATCH v2] Btrfs: fix list transaction-pending_ordered corruption

From: Filipe Manana fdman...@suse.com When we call btrfs_commit_transaction(), we splice the list ordered of our transaction handle into the transaction's pending_ordered list, but we don't re-initialize the ordered list of our transaction handle, this means it still points to the same elements

[PATCH] Btrfs: fix hang during inode eviction due to concurrent readahead

From: Filipe Manana fdman...@suse.com Zygo Blaxell and other users have reported occasional hangs while an inode is being evicted, leading to traces like the following: [ 5281.972322] INFO: task rm:20488 blocked for more than 120 seconds. [ 5281.973836] Not tainted 4.0.0-rc5-btrfs-next-9+

[PATCH] Btrfs: check if previous transaction aborted to avoid fs corruption

From: Filipe Manana fdman...@suse.com While we are committing a transaction, it's possible the previous one is still finishing its commit and therefore we wait for it to finish first. However we were not checking if that previous transaction ended up getting aborted after we waited for it to

[PATCH v2] Btrfs: check if previous transaction aborted to avoid fs corruption

From: Filipe Manana fdman...@suse.com While we are committing a transaction, it's possible the previous one is still finishing its commit and therefore we wait for it to finish first. However we were not checking if that previous transaction ended up getting aborted after we waited for it to

[GIT PULL] Btrfs fixes for integration-4.3

46cd28555ffaa40162290dba203daad0ff6f7abd: Merge branch 'jeffm-discard-4.3' into for-linus-4.3 (2015-08-09 07:35:33 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/fdmanana/linux.git integration-4.3 for you to fetch changes up

[PATCH] Btrfs: fix file read corruption after extent cloning and fsync

From: Filipe Manana fdman...@suse.com If we partially clone one extent of a file into a lower offset of the file, fsync the file, power fail and then mount the fs to trigger log replay, we can get multiple checksum items in the csum tree that overlap each other and result in checksum lookup

[PATCH] fstests: btrfs regression test for fsync after extent cloning

From: Filipe Manana fdman...@suse.com Test that if we fsync a file that got one extent partially cloned into a lower file offset, after a power failure our file has the same content it had before the power failure and after the extent cloning operation. This test is motivated by an issue found

[PATCH v2] Btrfs: fix memory corruption on failure to submit bio for direct IO

From: Filipe Manana fdman...@suse.com If we fail to submit a bio for a direct IO request, we were grabbing the corresponding ordered extent and decrementing its reference count twice, once for our lookup reference and once for the ordered tree reference. This was a problem because it caused the

[GIT PULL] Btrfs bug fixes

://git.kernel.org/pub/scm/linux/kernel/git/fdmanana/linux.git integration-4.2 for you to fetch changes up to 9ac2b7cb4755cb3311bb7d1ccf0eb51d0e006fba: Btrfs: fix wrong check for btrfs_force_chunk_alloc() (2015-06-30 05:00:49 +0100

[PATCH] fstests: test for btrfs incremental send after file extent cloning

From: Filipe Manana fdman...@suse.com Test that an incremental send works after a file gets one of its extents cloned/deduplicated into lower file offsets. This is a regression test for the problem fixed by the linux kernel patch titled: Btrfs: teach backref walking about backrefs with

[PATCH] Btrfs: teach backref walking about backrefs with underflowed offset values

/foo ... $ cat /home/fdmanana/git/hub/xfstests/results//btrfs/097.full (...) ERROR: send ioctl failed with -5: Input/output error Signed-off-by: Filipe Manana fdman...@suse.com --- fs/btrfs/backref.c | 27 +-- 1 file changed, 25 insertions(+), 2 deletions(-) diff

[PATCH] Btrfs: fix stale dir entries after removing a link and fsync

/* rmdir $SCRATCH_MNT/testdir _unmount_flakey status=0 exit The test fails with: $ ./check generic/107 FSTYP -- btrfs PLATFORM -- Linux/x86_64 debian3 4.1.0-rc6-btrfs-next-11+ MKFS_OPTIONS -- /dev/sdc MOUNT_OPTIONS -- /dev/sdc /home/fdmanana/btrfs-tests/scratch_1

[PATCH] fstests: generic test for fsync of file with multiple links

.out.bad) --- tests/generic/107.out 2015-08-04 09:47:46.922131256 +0100 +++ /home/fdmanana/git/hub/xfstests/results//generic/107.out.bad @@ -1,3 +1,5 @@ QA output created by 107 Entries in testdir: foo2 +foo3 +rmdir: failed to remove '/home/fdmanana/btrfs-tests

[PATCH] fstests: test for file fsync after unlink and inode eviction

by an issue found on btrfs, and on an unpatched btrfs it fails with: FSTYP -- btrfs PLATFORM -- Linux/x86_64 debian3 4.1.0-rc6-btrfs-next-11+ MKFS_OPTIONS -- /dev/sdc MOUNT_OPTIONS -- /dev/sdc /home/fdmanana/btrfs-tests/scratch_1 generic/098 4s ... - output mismatch (see

[PATCH] Btrfs: fix stale dir entries after unlink, inode eviction and fsync

$SCRATCH_MNT/testdir _unmount_flakey # The fstests framework will call fsck against our filesystem which will verify # that all metadata is in a consistent state. status=0 exit The test failed on btrfs with: generic/098 4s ... - output mismatch (see /home/fdmanana/git/hub

[PATCH v2] fstests: btrfs test to exercise shared extent reference accounting

From: Filipe Manana fdman...@suse.com Regression test for adding and dropping an equal number of references for file extents. Verify that if we drop N references for a file extent and we add too N new references for that same file extent in the same transaction, running the delayed references

[PATCH v2] Btrfs: fix stale directory entries after fsync log replay

fsck against our filesystem which will verify # that all metadata is in a consistent state. status=0 exit The test fails with: -Link count for file foo: 2 +Link count for file foo: 1 Link count for file bar: 2 +rm: cannot remove '/home/fdmanana/btrfs-tests/scratch_1/testdir/foo_link

[GIT PULL] More btrfs bug fixes

-0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/fdmanana/linux.git integration-4.2 for you to fetch changes up to cffc3374e567ef42954f3c7070b3fa83f20f9684: Btrfs: fix order by which delayed references are run (2015-07-11 22:36:44 +0100

[PATCH] fstests: regression test for the btrfs clone ioctl

From: Filipe Manana fdman...@suse.com This tests that we can not clone an inline extent into a non-zero file offset. Inline extents at non-zero offsets is something btrfs is not prepared for and results in all sorts of corruption and crashes on future IO operations, such as the following BUG_ON()

[PATCH] Btrfs: fix file corruption after cloning inline extents

From: Filipe Manana fdman...@suse.com Using the clone ioctl (or extent_same ioctl, which calls the same extent cloning function as well) we end up allowing copy an inline extent from the source file into a non-zero offset of the destination file. This is something not expected and that the btrfs

[PATCH] Btrfs: fix stale directory entries after fsync log replay

fsck against our filesystem which will verify # that all metadata is in a consistent state. status=0 exit The test fails with: -Link count for file foo: 2 +Link count for file foo: 1 Link count for file bar: 2 +rm: cannot remove '/home/fdmanana/btrfs-tests/scratch_1/testdir/foo_link

[PATCH] fstests: generic test for fsync after adding hard links

From: Filipe Manana fdman...@suse.com Test that if we add hard links (in the same directory) to two files and then fsync only one of the files, after the fsync log/journal is replayed all the links exist and the filesystem metadata (directory and file inodes) is in a consistent state. This test

[PATCH v3] Btrfs-progs: add feature to get mininum size for resizing a fs/device

From: Filipe Manana fdman...@suse.com Currently there is not way for a user to know what is the minimum size a device of a btrfs filesystem can be resized to. Sometimes the value of total allocated space (sum of all allocated chunks/device extents), which can be parsed from 'btrfs filesystem

[PATCH] Btrfs: fix quick exhaustion of the system array in the superblock

From: Filipe Manana fdman...@suse.com Omar reported that after commit 4fbcdf669454 (Btrfs: fix -ENOSPC when finishing block group creation), introduced in 4.2-rc1, the following test was failing due to exhaustion of the system array in the superblock: #!/bin/bash truncate -s 100T big.img

[PATCH 1/2 v2] Btrfs: fix regression when running delayed references

From: Filipe Manana In the kernel 4.2 merge window we had a refactoring/rework of the delayed references implementation in order to fix certain problems with qgroups. However that rework introduced one more regression that leads to the following trace when running delayed

[PATCH 2/2 v2] Btrfs: fix regression running delayed references when using qgroups

From: Filipe Manana In the kernel 4.2 merge window we had a big changes to the implementation of delayed references and qgroups which made the no_quota field of delayed references not used anymore. More specifically the no_quota field is not used anymore as of: commit

[PATCH] Btrfs: fix regression when running delayed references

From: Filipe Manana In the kernel 4.2 merge window we had a refactoring/rework of the delayed references implementation in order to fix certain problems with qgroups. However that rework introduced one more regression that leads to the following trace when running delayed

[GIT PULL] Btrfs fixes for delayed refs regression and a deadlock

since commit a9e6d153563d2ed69c6cd7fb4fa5ce4ca7c712eb: Merge branch 'allocator-fixes' into for-linus-4.4 (2015-10-21 19:00:38 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/fdmanana/linux.git delayed-refs-balance-fix-4.4 for you to fetch chan

[PATCH 1/2 v3] Btrfs: fix regression when running delayed references

From: Filipe Manana In the kernel 4.2 merge window we had a refactoring/rework of the delayed references implementation in order to fix certain problems with qgroups. However that rework introduced one more regression that leads to the following trace when running delayed

[PATCH 2/2 v3] Btrfs: fix regression running delayed references when using qgroups

From: Filipe Manana In the kernel 4.2 merge window we had a big changes to the implementation of delayed references and qgroups which made the no_quota field of delayed references not used anymore. More specifically the no_quota field is not used anymore as of: commit

[PATCH] Btrfs: fix race leading to incorrect item deletion when dropping extents

From: Filipe Manana While running a stress test I got the following warning triggered: [191627.672810] [ cut here ] [191627.673949] WARNING: CPU: 8 PID: 8447 at fs/btrfs/file.c:779 __btrfs_drop_extents+0x391/0xa50 [btrfs]() (...)

[PATCH] Btrfs: fix race leading to BUG_ON when running delalloc for nodatacow

From: Filipe Manana If we are using the NO_HOLES feature, we have a tiny time window when running delalloc for a nodatacow inode where we can race with a concurrent link or xattr add operation leading to a BUG_ON. This happens because at run_delalloc_nocow() we end up casting

[PATCH] Btrfs: fix race when listing an inode's xattrs

From: Filipe Manana When listing a inode's xattrs we have a time window where we race against a concurrent operation for adding a new hard link for our inode that makes us not return any xattr to user space. In order for this to happen, the first xattr of our inode needs to be

[PATCH 1/2] Btrfs: use global reserve when deleting unused block group after ENOSPC

From: Filipe Manana It's possible to reach a state where the cleaner kthread isn't able to start a transaction to delete an unused block group due to lack of enough free metadata space and due to lack of unallocated device space to allocate a new metadata block group as well.

[PATCH 0/2] Btrfs: fixes for an ENOSPC issue that left a fs unusable

e also available at: http://git.kernel.org/cgit/linux/kernel/git/fdmanana/linux.git/log/?h=integration-4.4 Thanks. Filipe Manana (2): Btrfs: use global reserve when deleting unused block group after ENOSPC Btrfs: fix the number of transaction units needed to remove a block group

[PATCH v2 2/2] Btrfs: fix the number of transaction units needed to remove a block group

From: Filipe Manana We were using only 1 transaction unit when attempting to delete an unused block group but in reality we need 3 + N units, where N corresponds to the number of stripes. We were accounting only for the addition of the orphan item (for the block group's free

[PATCH v2 0/2] Btrfs: fixes for an ENOSPC issue that left a fs unusable

e also available at: http://git.kernel.org/cgit/linux/kernel/git/fdmanana/linux.git/log/?h=integration-4.4 Thanks. Changes in v2: Updated the second patch to account for the space required to remove the device extents from the device tree (was previously ignored). Filipe Manana (2): Btrfs: us

[PATCH v2 1/2] Btrfs: use global reserve when deleting unused block group after ENOSPC

From: Filipe Manana It's possible to reach a state where the cleaner kthread isn't able to start a transaction to delete an unused block group due to lack of enough free metadata space and due to lack of unallocated device space to allocate a new metadata block group as well.

[PATCH RESEND] fstests: test for btrfs direct IO write against compressed extent

From: Filipe Manana Test that doing a direct IO write against a file range that contains one prealloc extent and one compressed extent works correctly. >From the linux kernel 4.0 onwards, this either triggered an assertion failure (leading to a BUG_ON) when

[PATCH] Btrfs: fix race waiting for qgroup rescan worker

From: Filipe Manana We were initializing the completion (fs_info->qgroup_rescan_completion) object after releasing the qgroup rescan lock, which gives a small time window for a rescan waiter to not actually wait for the rescan worker to finish. Example: CPU 1

[GIT PULL] Btrfs fixes

write regression. Thanks. The following changes since commit 2959a32a858a2c44bbbce83d19c158d54cc5998a: Btrfs: fix hole punching when using the no-holes feature (2015-11-03 07:44:20 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/fdmanana/linux.git integ

[PATCH] Btrfs: fix sleeping inside atomic context in qgroup rescan worker

From: Filipe Manana We are holding a btree path with spinning locks and then we attempt to clone an extent buffer, which calls kmem_cache_alloc() and this function can sleep, causing the following trace to be reported on a debug kernel: [107118.218536] BUG: sleeping function

[PATCH] fstests: generic test for fsync after hole punching

From: Filipe Manana Test that a file fsync works after punching a hole for the same file range multiple times, and that after log/journal replay the file's content and layout are correct. This test is motivated by a bug found in btrfs, which is fixed by the following linux

[PATCH] Btrfs: fix hole punching when using the no-holes feature

From: Filipe Manana When we are using the no-holes feature, if we punch a hole into a file range that already contains a hole which overlaps the range we are passing to fallocate(), we end up removing the extent map that represents the existing hole without adding a new one.

[PATCH] Btrfs: fix extent accounting for partial direct IO writes

From: Filipe Manana When doing a write using direct IO we can end up not doing the whole write operation using the direct IO path, in that case we fallback to a buffered write to do the remaining IO. This happens for example if the range we are writing to contains a compressed

[PATCH] fstests: test for btrfs direct IO write against compressed extent

From: Filipe Manana Test that doing a direct IO write against a file range that contains one prealloc extent and one compressed extent works correctly. >From the linux kernel 4.0 onwards, this either triggered an assertion failure (leading to a BUG_ON) when

[PATCH v2] fstests: generic test for fsync after hole punching

From: Filipe Manana Test that a file fsync works after punching a hole for the same file range multiple times, and that after log/journal replay the file's content and layout are correct. This test is motivated by a bug found in btrfs, which is fixed by the following linux

[PATCH v2] Btrfs: fix truncation of compressed and inlined extents

From: Filipe Manana When truncating a file to a smaller size which consists of an inline extent that is compressed, we did not discard (or made unusable) the data between the new file size and the old file size, wasting metadata space and allowing for the truncated data to be

[GIT PULL] Btrfs fixes for 4.4 integration branch

el.org/pub/scm/linux/kernel/git/kdave/linux into for-linus-4.4 (2015-10-12 16:24:40 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/fdmanana/linux.git integration-4.4 for you to fetch changes up to 5e6ecb362bd5950a3d8ce19c32829e4f8c7917d9: Btrf

[PATCH v3] Btrfs: send, fix file corruption due to incorrect cloning operations

From: Filipe Manana If we have a file that shares an extent with other files, when processing the extent item relative to a shared extent, we blindly issue a clone operation that will target a length matching the length in the extent item and uses as a source some other file

[PATCH] fstests: test btrfs send with shared and compressed extents

From: Filipe Manana Test that a send operation works correctly for files that have shared extents which are compressed and partially overwritten after they are cloned. This used to fail on btrfs, resulting in different file digests after receiving the send stream, and got

[PATCH] Btrfs: fix truncation of compressed and inlined extents

From: Filipe Manana When truncating a file to a smaller size which consists of an inline extent that is compressed, we did not discard (or made unusable) the data between the new file size and the old file size, wasting metadata space and allowing for the truncated data to be

[PATCH] fstests: test btrfs cloning of compressed inline extent after truncation

From: Filipe Manana Test that truncating a file that consists of a compressed and inlined extent to a smaller size and then cloning it into another file is not possible and does not result in leaking stale data (data past the truncation offset) nor losing data in the clone

[PATCH v4] Btrfs: send, fix file corruption due to incorrect cloning operations

From: Filipe Manana If we have a file that shares an extent with other files, when processing the extent item relative to a shared extent, we blindly issue a clone operation that will target a length matching the length in the extent item and uses as a source some other file

[PATCH v2] fstests: test btrfs send with shared and compressed extents

From: Filipe Manana Test that a send operation works correctly with reflinked files (cloned extents which multiple files point to) that have compressed extents. This used to fail on btrfs, resulting in different file digests after receiving the send stream, and got fixed by

[PATCH v2] Btrfs: send, fix file corruption due to incorrect cloning operations

From: Filipe Manana If we have a file that shares an extent with other files, when processing the extent item relative to a shared extent, we blindly issue a clone operation that will target a length matching the length in the extent item and uses as a source some other file

[PATCH] Btrfs: fix file corruption and data loss after cloning inline extents

From: Filipe Manana Currently the clone ioctl allows to clone an inline extent from one file to another that already has other (non-inlined) extents. This is a problem because btrfs is not designed to deal with files having inline and regular extents, if a file has an inline

[PATCH 1/2] fstests: btrfs test for cloning of inline extents

From: Filipe Manana Test several cases of cloning inline extents that used to lead to file corruption or data loss. These file corruption and data loss cases are fixed by the linux kernel patch titled: "Btrfs: fix file corruption and data loss after cloning inline extents"

[PATCH 2/2] fstests: update btrfs/035 to check for data loss

From: Filipe Manana The test currently verifies that cloning one file with an inline extent with a size of 10 bytes into a file with an inline extent that has a size of 20 bytes succeeds. But this results in data loss, because the btrfs clone operation drops the 20 bytes

[PATCH] Btrfs: fix double range unlock of hole region when reading page

From: Filipe Manana If when reading a page we find a hole and our caller had already locked the range (bio flags has the bit EXTENT_BIO_PARENT_LOCKED set), we end up unlocking the hole's range and then later our caller unlocks it again, which might have already been locked by

[PATCH] Btrfs: fix order by which delayed references are run

From: Filipe Manana fdman...@suse.com When we have an extent that got N references removed and N new references added in the same transaction, we must run the insertion of the references first because otherwise the last removed reference will remove the extent item from the extent tree, resulting

[PATCH] fstests: btrfs test to exercise shared extent reference accounting

From: Filipe Manana fdman...@suse.com Regression test for adding and dropping an equal number of references for file extents. Verify that if we drop N references for a file extent and we add too N new references for that same file extent in the same transaction, running the delayed references

[PATCH] fstests: fix btrfs/091 failure due to not found _require_cp_reflink

btrfs/091 FSTYP -- btrfs PLATFORM -- Linux/x86_64 debian3 4.3.0-rc5-btrfs-next-17+ MKFS_OPTIONS -- /dev/sdc MOUNT_OPTIONS -- /dev/sdc /home/fdmanana/btrfs-tests/scratch_1 btrfs/091 1s ... - output mismatch (see .../results//btrfs/091.out.bad) --- tests/btrfs/091.out

[PATCH] fstests: add regression test for a btrfs enospc issue

From: Filipe Manana Regression test for an ENOSPC issue when attempting to write to a file in a filesystem without any data block groups allocated. The btrfs issue is fixed by the linux kernel patch titled "Btrfs: don't initialize a space info as full to prevent ENOSPC" and

[PATCH] Btrfs: don't initialize a space info as full to prevent ENOSPC

From: Filipe Manana Commit 2e6e518335f8 ("Btrfs: fix block group ->space_info null pointer dereference") accidently marked a space info as full when initializing it with a value of 0 total bytes. This introduces an ENOSPC problem when writing file data if we mount a filesystem

[PATCH] Btrfs: remove unnecessary locking of cleaner_mutex to avoid deadlock

From: Filipe Manana After commmit e44163e17796 ("btrfs: explictly delete unused block groups in close_ctree and ro-remount"), added in the 4.3 merge window, we have calls to btrfs_delete_unused_bgs() while holding the cleaner_mutex. This can cause a deadlock with a concurrent

[GIT PULL] Btrfs bug fixes

ges since commit 527afb4493c2892ce89fb74648e72a30b68ba120: Btrfs: cleanup: remove unnecessary check before btrfs_free_path is called (2015-08-31 11:46:41 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/fdmanana/linux.git integration-4.3 for you to

[PATCH] Btrfs: fix read corruption of compressed and shared extents

From: Filipe Manana If a file has a range pointing to a compressed extent, followed by another range that points to the same compressed extent and a read operation attempts to read both ranges (either completely or part of them), the pages that correspond to the second range

[PATCH] fstests: regression test for btrfs read corruption of compressed extents

From: Filipe Manana Regression test for file read corruption when using compressed extents that are shared by multiple consecutive ranges of the same file. The btrfs issue is fixed by the linux kernel patch titled: "Btrfs: fix read corruption of compressed and shared extents"

[PATCH v2] Btrfs: fix deadlock when finalizing block group creation

From: Filipe Manana Josef ran into a deadlock while a transaction handle was finalizing the creation of its block groups, which produced the following trace: [260445.593112] fio D 88022a9df468 0 8924 4518 0x0084 [260445.593119]

[PATCH] Btrfs: send, fix file corruption due to incorrect cloning operations

From: Filipe Manana If we have a file that shares an extent with other files, when processing the extent item relative to a shared extent, we blindly issue a clone operation that will target a length matching the length in the extent item and uses as a source some other file

[PATCH] fstests: test btrfs send for reflinked files

From: Filipe Manana Test that a send operation works correctly with reflinked files (cloned extents which multiple files point to). The btrfs issue was fixed by the linux kernel patch titled: "Btrfs: send, fix file corruption due to incorrect cloning operations"

[PATCH] Btrfs: fix deadlock when finalizing block group creation

From: Filipe Manana Josef ran into a deadlock while a transaction handle was finalizing the creation of its block groups, which produced the following trace: [260445.593112] fio D 88022a9df468 0 8924 4518 0x0084 [260445.593119]

[PATCH] fstests: test for btrfs incremental send after replacing a file

From: Filipe Manana Test that an incremental send works after a file from the parent snapshot gets replaced in the send snapshot by another one at the same exact location, with the same name and with the same inode number. This test used to fail after the linux kernel commit

  1   2   3   4   5   >