Hi all, Here''s a traceback from a failed attempt to mount a btrfs in lvm in luks filesystem. Note that if I mount it readonly it mounts successfully (haven''t tried to recover any data as I have recent backups). Yesterday I defragmented both / and /home with: find /home -xdev -type f -print0 | xargs -0 sudo ./btrfs filesystem defragment -c with btrfs-tools v0.19-35-g1b444cd and rebooted a couple of times. And today I got this traceback while trying to mount home at boot time (/ is working ok) btrfsck fails with the following error: couldn''t open because of unsupported option features (8). btrfsck: disk-io.c:682: open_ctree_fd: Assertion `!(1)'' failed. I''m using a 2.6.39-rc5+ kernel from Linus'' tree. If someone needs any extra info, just ask for it, Ill keep the corrupted filesystem for a few days before destroying it. Thanks. -- Elric Milon
On 05/04/2011 10:26 AM, whirm@gmx.com wrote:> Hi all, > > Here''s a traceback from a failed attempt to mount a btrfs in lvm in luks > filesystem. > > Note that if I mount it readonly it mounts successfully (haven''t tried to > recover any data as I have recent backups). > > Yesterday I defragmented both / and /home with: > > find /home -xdev -type f -print0 | xargs -0 sudo ./btrfs filesystem defragment > -c > > with btrfs-tools v0.19-35-g1b444cd and rebooted a couple of times. And today I > got this traceback while trying to mount home at boot time (/ is working ok) > > btrfsck fails with the following error: > > couldn''t open because of unsupported option features (8). > btrfsck: disk-io.c:682: open_ctree_fd: Assertion `!(1)'' failed. > > I''m using a 2.6.39-rc5+ kernel from Linus'' tree. > > If someone needs any extra info, just ask for it, Ill keep the corrupted > filesystem for a few days before destroying it. > > Thanks. >I just posted a patch for this, please try [PATCH] Btrfs: fix how we do space reservation for truncate thanks, 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
On Wednesday 04 May 2011 16:46:44 Josef Bacik wrote:> On 05/04/2011 10:26 AM, whirm@gmx.com wrote: > > Hi all, > > > > Here''s a traceback from a failed attempt to mount a btrfs in lvm in luks > > filesystem. > > > > Note that if I mount it readonly it mounts successfully (haven''t tried to > > recover any data as I have recent backups). > > > > Yesterday I defragmented both / and /home with: > > > > find /home -xdev -type f -print0 | xargs -0 sudo ./btrfs filesystem > > defragment -c > > > > with btrfs-tools v0.19-35-g1b444cd and rebooted a couple of times. And > > today I got this traceback while trying to mount home at boot time (/ is > > working ok) > > > > btrfsck fails with the following error: > > > > couldn''t open because of unsupported option features (8). > > btrfsck: disk-io.c:682: open_ctree_fd: Assertion `!(1)'' failed. > > > > I''m using a 2.6.39-rc5+ kernel from Linus'' tree. > > > > If someone needs any extra info, just ask for it, Ill keep the corrupted > > filesystem for a few days before destroying it. > > > > Thanks. > > I just posted a patch for this, please try > > [PATCH] Btrfs: fix how we do space reservation for truncate > > thanks, > > JosefStill getting the same traceback when trying to mount the filesystem (see file attached). Thanks,
On 05/04/2011 01:43 PM, whirm@gmx.com wrote:> On Wednesday 04 May 2011 16:46:44 Josef Bacik wrote: >> On 05/04/2011 10:26 AM, whirm@gmx.com wrote: >>> Hi all, >>> >>> Here''s a traceback from a failed attempt to mount a btrfs in lvm in luks >>> filesystem. >>> >>> Note that if I mount it readonly it mounts successfully (haven''t tried to >>> recover any data as I have recent backups). >>> >>> Yesterday I defragmented both / and /home with: >>> >>> find /home -xdev -type f -print0 | xargs -0 sudo ./btrfs filesystem >>> defragment -c >>> >>> with btrfs-tools v0.19-35-g1b444cd and rebooted a couple of times. And >>> today I got this traceback while trying to mount home at boot time (/ is >>> working ok) >>> >>> btrfsck fails with the following error: >>> >>> couldn''t open because of unsupported option features (8). >>> btrfsck: disk-io.c:682: open_ctree_fd: Assertion `!(1)'' failed. >>> >>> I''m using a 2.6.39-rc5+ kernel from Linus'' tree. >>> >>> If someone needs any extra info, just ask for it, Ill keep the corrupted >>> filesystem for a few days before destroying it. >>> >>> Thanks. >> >> I just posted a patch for this, please try >> >> [PATCH] Btrfs: fix how we do space reservation for truncate >> >> thanks, >> >> Josef > > Still getting the same traceback when trying to mount the filesystem (see file > attached).Argh sorry I was looking at the wrong part of that warning. Can you run with this debug patch and send me the log? Thanks, Josef
On Thu, May 05, 2011 at 02:12:03PM +0200, whirm@gmx.com wrote:> Seems like the mail didn''t get trough, trying again with the logfile > compressed. > > Thanks, > > On Wednesday 04 May 2011 20:21:54 you wrote: > [...] > > Argh sorry I was looking at the wrong part of that warning. Can you run > > with this debug patch and send me the log? Thanks, > > > > Josef > > I hope that''s enough, the log buffer was too small to keep the whole thing. >Hmm I didn''t see what I needed, can you do it again and try to get kernel messages to go to /var/log/messages so you don''t have to worry about the log buffer? The other option is to setup netconsole which would grab everything. Thanks, 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
On 05/05/2011 01:54 PM, whirm@gmx.com wrote:> On Thursday 05 May 2011 19:53:52 Josef Bacik wrote: > [...] >> Hmm I didn''t see what I needed, can you do it again and try to get kernel >> messages to go to /var/log/messages so you don''t have to worry about the >> log buffer? The other option is to setup netconsole which would grab >> everything. Thanks, > > Ok, this is all of it. >It doesn''t look like that bit had my debugging output. Thanks, 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
On Thursday 05 May 2011 20:57:17 Josef Bacik wrote: [..]> It doesn''t look like that bit had my debugging output. Thanks, > > JosefLooks like the last message I sent didn''t make to the list. Here''s the link to the debug log: http://pastebin.com/raw.php?i=fnfsnVZS Thanks, -- Elric Milon -- 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
On 05/13/2011 01:19 PM, whirm@gmx.com wrote:> On Thursday 05 May 2011 20:57:17 Josef Bacik wrote: > [..] >> It doesn''t look like that bit had my debugging output. Thanks, >> >> Josef > > Looks like the last message I sent didn''t make to the list. Here''s the link to > the debug log: >So unfortunately I don''t know how we ended up with duplicate entries in the free space cache, but I can make it so we discard the cache if this happens. Please try the patch I just sent to the list [PATCH] Btrfs: check for duplicate entries in the free space cache this will make your fs able to be mounted at the very least. I''ll try and figure out how this sort of thing happens. If you manage to make it happen on purpose let me know how you did it so I can figure out what I''m doing wrong. Thanks, 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
On Friday 13 May 2011 20:52:22 Josef Bacik wrote:> On 05/13/2011 01:19 PM, whirm@gmx.com wrote: > > On Thursday 05 May 2011 20:57:17 Josef Bacik wrote: > > [..] > > > >> It doesn''t look like that bit had my debugging output. Thanks, > >> > >> Josef > > > > Looks like the last message I sent didn''t make to the list. Here''s the > > link to > > > the debug log: > So unfortunately I don''t know how we ended up with duplicate entries in > the free space cache, but I can make it so we discard the cache if this > happens. Please try the patch I just sent to the list > > [PATCH] Btrfs: check for duplicate entries in the free space cache > > this will make your fs able to be mounted at the very least. I''ll try > and figure out how this sort of thing happens. If you manage to make it > happen on purpose let me know how you did it so I can figure out what > I''m doing wrong. Thanks,I was able to mount it readonly and copy all the content from it without problems (with vanilla linus'' tree). The only out of ordinary thing I did before the error coming up, was to defrag the filesystem (find ~/ -xdev -type f -print0 | xargs -0 sudo ./btrfs filesystem defragment -c) with btrfs-tools from the latest git. After this I think I rebooted once the same day and everything was working ok. The day after in the morning I powered up the laptop and I wasn''t able to mount the home volume. I''m on a 64 bit Debian SID with custom kernel. Using btrfs on home and root and ext4 in 3 or 4 other FS, everything is on lvm in luks. The only thing I think of I can try is to recreate the filesystem, copy the same data on it, defrag and try to umount/remount several times... (although the data will not be fragmented so we may not hit this error) What do you say? Thanks, -- Elric Milon -- Elric Milon -- 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
On 05/16/2011 05:17 AM, whirm@gmx.com wrote:> On Friday 13 May 2011 20:52:22 Josef Bacik wrote: >> On 05/13/2011 01:19 PM, whirm@gmx.com wrote: >>> On Thursday 05 May 2011 20:57:17 Josef Bacik wrote: >>> [..] >>> >>>> It doesn''t look like that bit had my debugging output. Thanks, >>>> >>>> Josef >>> >>> Looks like the last message I sent didn''t make to the list. Here''s the >>> link to >> >>> the debug log: >> So unfortunately I don''t know how we ended up with duplicate entries in >> the free space cache, but I can make it so we discard the cache if this >> happens. Please try the patch I just sent to the list >> >> [PATCH] Btrfs: check for duplicate entries in the free space cache >> >> this will make your fs able to be mounted at the very least. I''ll try >> and figure out how this sort of thing happens. If you manage to make it >> happen on purpose let me know how you did it so I can figure out what >> I''m doing wrong. Thanks, > > I was able to mount it readonly and copy all the content from it without > problems (with vanilla linus'' tree). The only out of ordinary thing I did > before the error coming up, was to defrag the filesystem (find ~/ -xdev -type > f -print0 | xargs -0 sudo ./btrfs filesystem defragment -c) with btrfs-tools > from the latest git. After this I think I rebooted once the same day and > everything was working ok. The day after in the morning I powered up the > laptop and I wasn''t able to mount the home volume. > I''m on a 64 bit Debian SID with custom kernel. Using btrfs on home and root > and ext4 in 3 or 4 other FS, everything is on lvm in luks. > > The only thing I think of I can try is to recreate the filesystem, copy the > same data on it, defrag and try to umount/remount several times... (although > the data will not be fragmented so we may not hit this error) What do you say? >Sorry I''m having problems following what you are saying. You mean this is how you got into this current situation, or that this is what is currently happening to you. If it''s the first one then cool, if you can try and make it happen again I would be grateful. If it''s the second one then my patch didn''t work and I need to try and figure out whats going wrong. Thanks, 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
On Monday 16 May 2011 16:11:19 Josef Bacik wrote:> On 05/16/2011 05:17 AM, whirm@gmx.com wrote: > > On Friday 13 May 2011 20:52:22 Josef Bacik wrote: > >> On 05/13/2011 01:19 PM, whirm@gmx.com wrote: > >>> On Thursday 05 May 2011 20:57:17 Josef Bacik wrote: > >>> [..] > >>> > >>>> It doesn''t look like that bit had my debugging output. Thanks, > >>>> > >>>> Josef > >>> > >>> Looks like the last message I sent didn''t make to the list. Here''s the > >>> link to > >> > >>> the debug log: > >> So unfortunately I don''t know how we ended up with duplicate entries in > >> the free space cache, but I can make it so we discard the cache if this > >> happens. Please try the patch I just sent to the list > >> > >> [PATCH] Btrfs: check for duplicate entries in the free space cache > >> > >> this will make your fs able to be mounted at the very least. I''ll try > >> and figure out how this sort of thing happens. If you manage to make it > >> happen on purpose let me know how you did it so I can figure out what > >> I''m doing wrong. Thanks, > > > > I was able to mount it readonly and copy all the content from it without > > problems (with vanilla linus'' tree). The only out of ordinary thing I did > > before the error coming up, was to defrag the filesystem (find ~/ -xdev > > -type f -print0 | xargs -0 sudo ./btrfs filesystem defragment -c) with > > btrfs-tools from the latest git. After this I think I rebooted once the > > same day and everything was working ok. The day after in the morning I > > powered up the laptop and I wasn''t able to mount the home volume. > > I''m on a 64 bit Debian SID with custom kernel. Using btrfs on home and > > root and ext4 in 3 or 4 other FS, everything is on lvm in luks. > > > > The only thing I think of I can try is to recreate the filesystem, copy > > the same data on it, defrag and try to umount/remount several times... > > (although the data will not be fragmented so we may not hit this error) > > What do you say? > > Sorry I''m having problems following what you are saying. You mean this > is how you got into this current situation, or that this is what is > currently happening to you. If it''s the first one then cool, if you can > try and make it happen again I would be grateful. If it''s the second > one then my patch didn''t work and I need to try and figure out whats > going wrong. Thanks, > > JosefSorry yes, I meant this is how I managed to get the corrupted filesystem. Ill try to break it again. Thanks, -- 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
On 05/16/2011 11:01 AM, Whirm wrote:> On Monday 16 May 2011 16:11:19 Josef Bacik wrote: >> On 05/16/2011 05:17 AM, whirm@gmx.com wrote: >>> On Friday 13 May 2011 20:52:22 Josef Bacik wrote: >>>> On 05/13/2011 01:19 PM, whirm@gmx.com wrote: >>>>> On Thursday 05 May 2011 20:57:17 Josef Bacik wrote: >>>>> [..] >>>>> >>>>>> It doesn''t look like that bit had my debugging output. Thanks, >>>>>> >>>>>> Josef >>>>> >>>>> Looks like the last message I sent didn''t make to the list. Here''s the >>>>> link to >>>> >>>>> the debug log: >>>> So unfortunately I don''t know how we ended up with duplicate entries in >>>> the free space cache, but I can make it so we discard the cache if this >>>> happens. Please try the patch I just sent to the list >>>> >>>> [PATCH] Btrfs: check for duplicate entries in the free space cache >>>> >>>> this will make your fs able to be mounted at the very least. I''ll try >>>> and figure out how this sort of thing happens. If you manage to make it >>>> happen on purpose let me know how you did it so I can figure out what >>>> I''m doing wrong. Thanks, >>> >>> I was able to mount it readonly and copy all the content from it without >>> problems (with vanilla linus'' tree). The only out of ordinary thing I did >>> before the error coming up, was to defrag the filesystem (find ~/ -xdev >>> -type f -print0 | xargs -0 sudo ./btrfs filesystem defragment -c) with >>> btrfs-tools from the latest git. After this I think I rebooted once the >>> same day and everything was working ok. The day after in the morning I >>> powered up the laptop and I wasn''t able to mount the home volume. >>> I''m on a 64 bit Debian SID with custom kernel. Using btrfs on home and >>> root and ext4 in 3 or 4 other FS, everything is on lvm in luks. >>> >>> The only thing I think of I can try is to recreate the filesystem, copy >>> the same data on it, defrag and try to umount/remount several times... >>> (although the data will not be fragmented so we may not hit this error) >>> What do you say? >> >> Sorry I''m having problems following what you are saying. You mean this >> is how you got into this current situation, or that this is what is >> currently happening to you. If it''s the first one then cool, if you can >> try and make it happen again I would be grateful. If it''s the second >> one then my patch didn''t work and I need to try and figure out whats >> going wrong. Thanks, >> >> Josef > > > 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, 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
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): diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c index 63731a1..419f91f 100644 --- a/fs/btrfs/free-space-cache.c +++ b/fs/btrfs/free-space-cache.c @@ -417,10 +417,19 @@ int load_free_space_cache(struct btrfs_fs_info *fs_info, } if (entry->type == BTRFS_FREE_SPACE_EXTENT) { + printk(KERN_ERR "adding extent [%llu-%llu]\n", + e->offset, e->bytes); spin_lock(&block_group->tree_lock); ret = link_free_space(block_group, e); spin_unlock(&block_group->tree_lock); - BUG_ON(ret); + if (ret) { + printk(KERN_ERR "Duplicate entries in " + "free space cache, dumping\n"); + kunmap(page); + unlock_page(page); + page_cache_release(page); + goto free_cache; + } } else { e->bitmap = kzalloc(PAGE_CACHE_SIZE, GFP_NOFS); if (!e->bitmap) { @@ -430,7 +439,17 @@ int load_free_space_cache(struct btrfs_fs_info *fs_info, unlock_page(page); page_cache_release(page); goto free_cache; + if (ret) { + printk(KERN_ERR "Duplicate entries in " + "free space cache, dumping\n"); + kunmap(page); + unlock_page(page); + page_cache_release(page); + goto free_cache; + } } + printk(KERN_ERR "adding bitmap [%llu-%llu]\n", + e->offset, e->bytes); spin_lock(&block_group->tree_lock); ret = link_free_space(block_group, e); block_group->total_bitmaps++; @@ -909,10 +928,16 @@ static int tree_insert_offset(struct rb_root *root, u64 offset, * logically. */ if (bitmap) { - WARN_ON(info->bitmap); + if (info->bitmap) { + WARN_ON_ONCE(1); + return -EEXIST; + } p = &(*p)->rb_right; } else { - WARN_ON(!info->bitmap); + if (!info->bitmap) { + WARN_ON_ONCE(1); + return -EEXIST; + } p = &(*p)->rb_left; } } Do you want me to try some other patch before I destroy the filesystem to make the other tests? Thanks, -- Elric Milon -- 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
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 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) { err = ret; -- 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
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, -- Elric Milon -- 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
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