Re: kernel BUG at fs/btrfs/inode.c:4676!

On Friday 10 of June 2011 16:52:36 Josef Bacik wrote:

On 06/10/2011 02:43 PM, Marek Otahal wrote:

quoted

On Friday 10 of June 2011 15:33:20 Josef Bacik wrote:

quoted

On 06/09/2011 10:06 PM, Daniel J Blueman wrote:

quoted

On 10 June 2011 09:57, Andy Lutomirski [off-list ref] wrote:

quoted

On 06/06/2011 06:19 AM, Marek Otahal wrote:

quoted

Hello,
the issue happens every time when i have to hard power-off my notebook
(suspend problems).
With kernel 2.6.39 the partition is unmountable, solution is to boot
2.6.38 kernel which
1/ is able to mount the partition,
2/ by doing that fixes the problem so later .39 (after clean shutdown) can
mount it also.

Same problem here.  Mounting with 2.6.38 says:

[   41.906259] Btrfs loaded
[   41.906747] device fsid e040a9d60da49596-66c0275e348878bf devid 1 transid
69217 /dev/mapper/vg_midnight_ssd-home
[   41.908767] btrfs: disk space caching is enabled
[   42.232185] btrfs: unlinked 17 orphans
[   42.232189] btrfs: truncated 2 orphans

dmesg in 2.6.39.1 says:

[]

quoted

[   15.004255] kernel BUG at fs/btrfs/inode.c:4676!

[]

I've been experiencing the same issue also.

Josef/Chris, would an metadata snapshot or full block snapshot help
debug this regression? I can probably setup a small testcase to
trigger this.

If you can come up with a testcase to reproduce I would love you forever
;).  If I get done what I wanted to do today I will try and reproduce.
Thanks,

Josef

...I was getting ready for you eternal love, Josef :P...but I can't reproduce it 100%, like 70% 

success-rate. 

quoted

The test-case is quite easy, 
1. mount the FS, just with compress-force=lzo option // I didn't try without, but on my other 

btrfs partition that doesn't use compression the err never happened ...so, can the others who 
experience the bug confirm compress=lzo used?   

quoted

2. cd to it & create a file (not sure if needed)
3. hard power-off

To reproduce my tests: 
dd /dev/zero /btrfstest bs=1M count=256 (min required for default mksf.btrfs)
losetup /dev/loop0 /btrfstest
mkfs.btrfs /dev/loop0
mount -o compress-force=lzo /dev/loop0 /mnt/tmp
vim /mnt/tmp/hello.txt
---power off!

How long do you wait between these two steps?  I've not been able to
reproduce this and I've done it maybe 5 times.  Either I've fixed it in
my tree (yay!) or I'm doing something wrong (boo!).  Thanks,

Josef

Not much but not immediately too, I'd say like ~5s. Did ls, df and quit. 
Tomorrow I'll try if I can spot a difference. 
Btw, is there a way to simulate power-off on a loopback-fs? Like to kill the loopback device while 
fs is mounted or some way? So I don't have to stress the poor hw :) 
Thank you, Mark

-- 

Marek Otahal :o)