search for: csum_tree

...e: foobar item 4 key (257 INODE_ITEM 0) itemoff 3591 itemsize 160 inode generation 7 transid 7 size 0 block group 0 mode 100644 links 1 item 5 key (257 INODE_REF 256) itemoff 3575 itemsize 16 inode ref index 2 namelen 6 name: foobar checksum tree key (CSUM_TREE ROOT_ITEM 0) leaf 29429760 items 0 free space 3995 generation 7 owner 7 fs uuid 6192815c-af2a-4b75-b3db-a959ffb6166e chunk uuid b529c44b-938c-4d3d-910a-013b4700bcae uuid tree key (UUID_TREE ROOT_ITEM 0) After this patch, the data loss no longer happens after a power failure and btrfs-debug-tree sh...

...sed 12288 chunk_objectid 256 flags 2 [..snip..] item 3 key (1138688 EXTENT_ITEM 4096) itemoff 3827 itemsize 42 extent refs 1 gen 1 flags 2 tree block key (0 UNKNOWN.0 0) level 0 item 4 key (1138688 TREE_BLOCK_REF 7) itemoff 3827 itemsize 0 tree block backref [..snip..] checksum tree key (CSUM_TREE ROOT_ITEM 0) leaf 1138688 items 0 free space 3995 generation 1 owner 7 fs uuid 2e08fd93-f24d-4f44-a226-e2116fcd544f chunk uuid dc482988-6246-46ce-9329-68bcf6d3683c For the above example, csum root leaf comes into system block group which is wrong,csum root leaf should be in metadata block group....

Hi! I used to have arch linux running on 1 btrfs partition (sda1, incl. /boot). When switching to 3.2.5 recently the system fails to boot: (after udevd) /etc/rc.sysinit: line 15: 117 Bus error mountpoint -q /proc and so on, no idea. It used to boot with 3.2.4, but 1) I obviously had some corruption in the tree, when I tried to delete a certain file I hit e.g. "kernel BUG at

Hello, This is the userspace part of restriper, rebased onto the new progs infrastructure. Restriper commands are located under ''balance'' prefix, which is now the top level command group. However to not confuse existing users ''balance'' prefix is also available under ''filesystem'': btrfs [filesystem] balance start btrfs [filesystem] balance