| Message ID | 4DDABADD.7090209@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Monday 23 May 2011 21:51:57 Josef Bacik wrote: > On 05/23/2011 07:57 AM, Elric Milon wrote: > > On Monday 16 May 2011 18:28:49 you wrote: > >> On 05/16/2011 11:01 AM, Whirm wrote: > >>> On Monday 16 May 2011 16:11:19 Josef Bacik wrote: > >>> > >>> > >>> Sorry yes, I meant this is how I managed to get the corrupted > >>> filesystem. > >>> > >>> Ill try to break it again. > >> > >> Oh ok perfect, yeah I will try and do the same sort of things and see if > >> I can get it to happen as well. Thanks, > > > > Great, btw, I tried to see if I can mount the corrupted filesystem with > > the patch you told me about applied, and it fails, here's the log: > > > > http://pastebin.com/raw.php?i=4Kfv927B > > > > That happens using 2.6.39-rc7+ from git with the following patch applied > > (its > > > the debug patch and the possible fix you told me about): > Ok so this is a different kind of corruption, wooo! Can you apply this > debug patch and get me the output so we can try and fix this bit? Thanks, > > Josef > Sorry for the delay, here's the log: http://pastebin.com/raw.php?i=zNqJVpA1 Thanks,
On 05/30/2011 07:12 AM, Elric Milon wrote: > On Monday 23 May 2011 21:51:57 Josef Bacik wrote: >> On 05/23/2011 07:57 AM, Elric Milon wrote: >>> On Monday 16 May 2011 18:28:49 you wrote: >>>> On 05/16/2011 11:01 AM, Whirm wrote: >>>>> On Monday 16 May 2011 16:11:19 Josef Bacik wrote: >>>>> >>>>> >>>>> Sorry yes, I meant this is how I managed to get the corrupted >>>>> filesystem. >>>>> >>>>> Ill try to break it again. >>>> >>>> Oh ok perfect, yeah I will try and do the same sort of things and see if >>>> I can get it to happen as well. Thanks, >>> >>> Great, btw, I tried to see if I can mount the corrupted filesystem with >>> the patch you told me about applied, and it fails, here's the log: >>> >>> http://pastebin.com/raw.php?i=4Kfv927B >>> >>> That happens using 2.6.39-rc7+ from git with the following patch applied >>> (its >> >>> the debug patch and the possible fix you told me about): >> Ok so this is a different kind of corruption, wooo! Can you apply this >> debug patch and get me the output so we can try and fix this bit? Thanks, >> >> Josef >> > > Sorry for the delay, here's the log: > > http://pastebin.com/raw.php?i=zNqJVpA1 > Ok so you have a corrupt extent entry in your tree. I will come up with something so we deal with this case better than panicing. Thanks for running these debug patches, Josef -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c index cd5e82e..54a8df5 100644 --- a/fs/btrfs/file.c +++ b/fs/btrfs/file.c @@ -365,6 +365,9 @@ next_slot: extent_end = key.offset + btrfs_file_extent_inline_len(leaf, fi); } else { + printk(KERN_ERR "Weird entry at slot=%d, type=%lu\n", + path->slots[0], extent_type); + btrfs_print_leaf(root, leaf); WARN_ON(1); extent_end = search_start; } diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index dc8fb2b..f951053 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -145,6 +145,9 @@ static noinline int insert_inline_extent(struct btrfs_trans_handle *trans, inode_add_bytes(inode, size); ret = btrfs_insert_empty_item(trans, root, path, &key, datasize); + if (ret) + printk(KERN_ERR "ret=%d, inode=%d, start=%llu, size=%llu\n", + ret, inode->i_ino, start, size); BUG_ON(ret); if (ret) {