similar to: about btrfs patches

I converted btrfs_truncate to do sane reservations for truncate, but didn''t convert btrfs_evict_inode. Basically we need to save the orphan_rsv for deleting the orphan item, and do normal reservations for our truncate. Thanks, Signed-off-by: Josef Bacik <josef@redhat.com> --- fs/btrfs/inode.c | 31 +++++++++++++++++++------------ 1 files changed, 19 insertions(+), 12

I''ve been watching how many btrfs_search_slot()''s we do and I noticed that when we create a file with selinux enabled we were doing 2 each time we initialize the security context. That''s because we lookup the xattr first so we can delete it if we''re setting a new value to an existing xattr. But in the create case we don''t have any xattrs, so it is

This fixes bugzilla 57491. If we take a snapshot of a fs with a unlink ongoing and then try to send that root we will run into problems. When comparing with a parent root we will search the parents and the send roots commit_root, which if we''ve just created the snapshot will include the file that needs to be evicted by the orphan cleanup. So when we find a changed extent we will try

I fixed a problem where we weren''t reserving space for an orphan item when we had to fallback to using the global reserve for an unlink, but I introduced another problem. I was migrating the bytes from the transaction reserve to the global reserve and then releasing from the global reserve in btrfs_end_transaction(). The problem with this is that a migrate will jack up the size for the

The new xfstests will run fsck against the volume to make sure we didn''t introduce any inconsistencies, which is nice except we will error out immediately if we mount with inode_cache. We need to make btrfsck skip the special free space cache items and then just assume that we have a link for the free space cache inode item. This makes btrfsck pass with success on a fs with inode cache

Hi Josef, Smatch complains about this change introduces a double unlock. fs/btrfs/async-thread.c +608 find_worker(49) error: double unlock ''spin_lock:&workers->lock'' 579 spin_unlock_irqrestore(&workers->lock, flags); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ We unlock here. 580

I''m trying to use this feature of qgroup: btrfs qgroup assign <srcid> <destid> <path> Assigns the lower level qgroup src to the higher level qgroup dest in the btrfs found in <path>. It is used to build qgroup hierarchies. However, I fail to understand how this feature should work, and I''m getting "ERROR: bad relation requested":

If cow_file_range_inline fails with ENOSPC we abort the transaction which isn''t very nice. This really shouldn''t be happening anyways but there''s no sense in making it a horrible error when we can easily just go allocate normal data space for this stuff. Thanks, Signed-off-by: Josef Bacik <josef@redhat.com> --- fs/btrfs/inode.c | 5 ++++- 1 files changed, 4

When making btrfs filesystem. we firstly write root leaf to specified filed, and then we recow the root. If we don''t recow, some trees are not in the correct block group. Steps to reproduce: dd if=/dev/zero of=test.img bs=1M count=100 mkfs.btrfs -f test.img btrfs-debug-tree test.img extent tree key (EXTENT_TREE ROOT_ITEM 0) leaf 4210688 items 10 free space 3349 generation 4 owner 2

We can just return an error and we''ll bail out properly. We still want to catch this case to make sure we don''t have a bug somewhere, so just warn if this pops up. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com> --- fs/btrfs/inode.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index 961ae6f..db6e11f

We unconditionally search for the EXTENT_ITEM_KEY for metadata during balance, and then check the key that we found to see if it is actually a METADATA_ITEM_KEY, but this doesn''t work right because METADATA is a higher key value, so if what we are looking for happens to be the first item in the leaf the search will dump us out at the previous leaf, and we won''t find our item. So

Martin Steigerwald reported a BUG_ON() where we were given a bogus bytenr to map. Turns out he is using > PAGESIZE leafsizes. The readahead stuff is called every time we do a completion, but we may not have finished reading in all the pages, so the bytenr we read off the node could be completely bogus. Fix this by only calling the readahead hook once all pages have been read in. Thanks,

A user reported that fsck was complaining about unresolved refs for some snapshots. You can reproduce this by doing mkfs.btrfs /dev/sdb mount /dev/sdb /mnt btrfs subvol snap /mnt/ /mnt/a btrfs subvol snap /mnt/ /mnt/b btrfs subvol del /mnt/a umount /mnt btrfsck /dev/sdb and you''d get this unresolved ref root 258 dir 256 index 2 namelen 1 name a error 600 because snapshot b has a dir

Because orphan cleanup now happens well after the fs is all initialized and such, we can run into this problem where we find orphan entries that were just added to the fs, not ones that were added previously during a crash. This does not bode well for the system, and results in a couple of odd things happening, like truncate being run on non-regular files. In order to fix this we just check and

Josef has implemented mixed data/metadata chunks, we must add those chunks'' space just like data chunks. Signed-off-by: Miao Xie <miaox@cn.fujitsu.com> --- fs/btrfs/super.c | 7 +++---- 1 files changed, 3 insertions(+), 4 deletions(-) diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c index 61bd79a..1d21208 100644 --- a/fs/btrfs/super.c +++ b/fs/btrfs/super.c @@ -768,11 +768,10

Older kernels would generally be able to still mount the filesystem with the default subvolume set, but it would result in a different volume being mounted, which could be an even more unpleasant suprise for users. So if you set your default subvolume, you can''t go back to older kernels. Thanks, Signed-off-by: Josef Bacik <josef@redhat.com> --- fs/btrfs/ctree.h | 4 +++-

So when I added the clear_cache option I screwed up and took the break out of the space_cache case statement, so whenever you mount with space_cache you also get clear_cache, which does you no good if you say set space_cache in fstab so it always gets set. This patch adds the break back in properly. Thanks, Signed-off-by: Josef Bacik <josef@redhat.com> --- fs/btrfs/super.c | 1 + 1

A user reported getting spammed when moving to 3.0 by this message. Since we switched to the normal checksumming infrastructure all old free space caches will be wrong and need to be regenerated so people are likely to see this message a lot, so ratelimit it so it doesn''t fill up their logs and freak them out. Thanks, Reported-by: Andrew Lutomirski <luto@mit.edu> Signed-off-by:

Hello Josef, FYI build failure occured in fs/btrfs/ctree.h. CC fs/btrfs/super.o In file included from fs/btrfs/delayed-inode.h:30:0, from fs/btrfs/super.c:45: fs/btrfs/ctree.h:3235:1: error: expected identifier or ‘(’ before ‘<<’ token make[3]: *** [fs/btrfs/super.o] Error 1 make[2]: *** [fs/btrfs] Error 2 make[1]: *** [fs] Error 2 make[1]: Leaving directory ` make:

Apparently it is ok to submit a read to an IDE device with the same target page for different offsets. This is what Windows does under qemu. The problem is under DIO we expect them to be different buffers for checksumming reasons, and so this sort of thing will result in checksum errors, when in reality the file is fine. So when reading, check to make sure that all iov bases are different, and