The comment is for btrfs_attach_transaction_barrier, not for
btrfs_attach_transaction. Fix the typo.
Signed-off-by: Wang Sheng-Hui shh...@gmail.com
---
fs/btrfs/transaction.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c
index
On Thu, 13 Jun 2013 10:19:46 -0400, Josef Bacik wrote:
On Wed, Jun 12, 2013 at 05:51:20AM -0600, Frederik Himpe wrote:
I just encoutered this btrfs bug. When this happened, I was compiling
stuff in a qemu/kvm virtual machine running as guest on this host, so
this might be related. The guest
On fri, 14 Jun 2013 16:21:24 +0800, Wang Sheng-Hui wrote:
The comment is for btrfs_attach_transaction_barrier, not for
btrfs_attach_transaction. Fix the typo.
Signed-off-by: Wang Sheng-Hui shh...@gmail.com
My miss, sorry.
Acked-by: Miao Xie mi...@cn.fujitsu.com
---
On Mon, May 06, 2013 at 04:17:24AM -0600, Miao Xie wrote:
Using the structure btrfs_sector_sum to keep the checksum value is
unnecessary, because the extents that btrfs_sector_sum points to are
continuous, we can find out the expected checksums by btrfs_ordered_sum's
bytenr and the offset, so
On Fri, Jun 14, 2013 at 02:21:24AM -0600, Wang Sheng-Hui wrote:
The comment is for btrfs_attach_transaction_barrier, not for
btrfs_attach_transaction. Fix the typo.
Signed-off-by: Wang Sheng-Hui shh...@gmail.com
---
fs/btrfs/transaction.c | 2 +-
1 file changed, 1 insertion(+), 1
This is a nice debugging help. I'm thinking about introducing a single
option to take names of all the trees to print. Something like
btrfs-debug-tree --tree uuid,csum,root,extent /dev
(or -t for the short option). Fortunatelly the number of trees is quite
small so we would not run out of
This is just an oddity with the commit stuff in btrfs-progs. It will just
update the generation of the root you call with, which in btrfsck case would
have been the fs_root. But because we didn't actually update the fs_root we
wouldn't have cow'ed the fs root and therefore the generation will
A user reported a deadlock where the async submit thread was blocked on the
lock_extent() lock, and then everybody behind him was locked on the page lock
for the page he was holding. Looking at the code I noticed we do not unlock the
extent range when we get ENOSPC and goto retry. This is bad
