On 06/10/2011 05:52 PM, Marek Otahal wrote: > On Friday 10 of June 2011 16:52:36 Josef Bacik wrote: >> On 06/10/2011 02:43 PM, Marek Otahal wrote: >>> On Friday 10 of June 2011 15:33:20 Josef Bacik wrote: >>>> On 06/09/2011 10:06 PM, Daniel J Blueman wrote: >>>>> On 10 June 2011 09:57, Andy Lutomirski <luto@xxxxxxx> wrote: >>>>>> On 06/06/2011 06:19 AM, Marek Otahal wrote: >>>>>>> >>>>>>> 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: >>>>> [] >>>>>> [ 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. >>> >>> 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? >>> 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 > I've not been able to hit this at all. Can you try on 3.0-rc4 and see if you are still hitting it? Maybe it accidently got fixed already :). Thanks, Josef -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
