I've noticed that the btrfs-unstable-standalone repository hasn't been
updated in over three weeks. It seems all active development is taking
place on btrfs-unstable. What is happening to the
btfs-unstable-standalone repository? Will all future development only be
on btrfs-unstable or is there
Hello,
Theres a slight problem with finish_current_insert, if we set all to 1 and then
go through and don't actually skip any of the extents on the pending list, we
could exit right after we've added new extents. This is a problem because by
inserting the new extents we could have gotten new
Since for the past three weeks all new patches have been submitted only
to btrfs-unstable I have updated my backport patch for btrfs-unstable.
This patch only works with 2.6.27 and 2.6.26(thanks Michele for testing
it for me)
Lee
diff -Naur btrfs-old/async-thread.c btrfs/async-thread.c
---
btrfs_read_block_groups returns an ambiguous value. Whether it finds
a block group or not, it will return -ENOENT. find_first_block_group
will eventually return -ENOENT when it reaches past the last block
group, and that is what is returned to the caller.
Also, if the kzalloc fails, it will
This patch changes start_transaction() to return an ERR_PTR instead of
NULL. Things like I/O errors and allocation failures can be handled
differently.
It also checks every start_transaction call. Where the error can be
handled simply, we clean up state and return an error.
If the recovery
Since btrfs_alloc_path is universally used, there's no point in keeping
btrfs_init_path around.
This patch removes it, and just uses the __GFP_ZERO flag for
kmem_cache_alloc to zero out the object.
Signed-off-by: Jeff Mahoney je...@suse.com
---
fs/btrfs/ctree.c | 12 ++--
While running a few tests with the btrfs sources pulled from
btrfs-unstable patched with my patch to compile under 2.6.26 I
encountered a very weird problem. Everything works fine the first time I
mount the file system (either actual disk or loop back). When I
unmounted the file system and mounted
