On Wed, 2011-06-22 at 12:09 -0400, Josef Bacik wrote: > 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, While repeatedly crashing 3.0-rc7 with attempts to make Broadcom wireless work, I've seen something very similar to this. Like Marek, I have to boot 2.6.38 to recover, and then I can boot 3.0 again. I've been seeing it for a while, but upon looking in to the mailing list I saw it was already being discussed and even had a test case more useful than "sometimes when I crash my kernel...", so I figured it was already in hand. I'll try to crash it tonight so I can hand it to Chris in the morning. Obviously, my attempts to reproduce it on demand so far have failed :) -- 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
