On 06/01/2011 03:44 PM, liubo wrote: > On 05/31/2011 08:27 AM, Tsutomu Itoh wrote: >> > The panic occurred when 'btrfs fi bal /test5' was executed. >> > >> > /test5 is as follows: >> > # mount -o space_cache,compress=lzo /dev/sdc3 /test5 >> > # >> > # btrfs fi sh /dev/sdc3 >> > Label: none uuid: 38ec48b2-a64b-4225-8cc6-5eb08024dc64 >> > Total devices 5 FS bytes used 7.87MB >> > devid 1 size 10.00GB used 2.02GB path /dev/sdc3 >> > devid 2 size 15.01GB used 3.00GB path /dev/sdc5 >> > devid 3 size 15.01GB used 3.00GB path /dev/sdc6 >> > devid 4 size 20.01GB used 2.01GB path /dev/sdc7 >> > devid 5 size 10.00GB used 2.01GB path /dev/sdc8 >> > >> > Btrfs v0.19-50-ge6bd18d >> > # btrfs fi df /test5 >> > Data, RAID0: total=10.00GB, used=3.52MB >> > Data: total=8.00MB, used=1.60MB >> > System, RAID1: total=8.00MB, used=4.00KB >> > System: total=4.00MB, used=0.00 >> > Metadata, RAID1: total=1.00GB, used=216.00KB >> > Metadata: total=8.00MB, used=0.00 >> > > > Hi, Itoh san, > > I've come up with a patch aiming to fix this bug. > The problems is that the inode allocator stores one inode cache per root, > which is at least not good for relocation tree, cause we only find > new inode number from fs tree or file tree (subvol/snapshot). > > I've tested with your run.sh and it works well on my box, so you can try this: >
Sorry, I messed up BTRFS_FIRST_FREE_OBJECTID and BTRFS_LAST_FREE_OBJECTID, plz ignore this. > === > based on 3.0, commit d6c0cb379c5198487e4ac124728cbb2346d63b1f > === > diff --git a/fs/btrfs/inode-map.c b/fs/btrfs/inode-map.c > index 0009705..ebc2a7b 100644 > --- a/fs/btrfs/inode-map.c > +++ b/fs/btrfs/inode-map.c > @@ -372,6 +372,10 @@ int btrfs_save_ino_cache(struct btrfs_root *root, > int prealloc; > bool retry = false; > > + if (root->root_key.objectid != BTRFS_FS_TREE_OBJECTID && > + root->root_key.objectid < BTRFS_FIRST_FREE_OBJECTID) > + return 0; > + > path = btrfs_alloc_path(); > if (!path) > return -ENOMEM; > > > > thanks, > liubo > -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
