Clean crash...

Clean crash...

[Andrea Gelmini]

Hi everyone,
  and thanks a lot for your work.
  I have an USB drive with BTRFS, on which I write with different
kernel release.
  Anyway, today I made a copy of one big file, and than powered off
the computer with a clean shutdown (Ubuntu 13.10 - 32bit).
  Now it's impossible to me to mount it (even with kernel 3.12).
  Here the kernel log:
[33109.118337] scsi 19:0:0:0: Direct-Access     WD       My Passport
0748 1019 PQ: 0 ANSI: 6
[33109.118497] sd 19:0:0:0: Attached scsi generic sg2 type 0
[33109.122721] sd 19:0:0:0: [sdb] Spinning up disk...
[33110.126799] .....ready
[33114.148252] sd 19:0:0:0: [sdb] 3906963456 512-byte logical blocks:
(2.00 TB/1.81 TiB)
[33114.148517] sd 19:0:0:0: [sdb] Write Protect is off
[33114.148521] sd 19:0:0:0: [sdb] Mode Sense: 47 00 10 08
[33114.148783] sd 19:0:0:0: [sdb] No Caching mode page found
[33114.148786] sd 19:0:0:0: [sdb] Assuming drive cache: write through
[33114.149846] sd 19:0:0:0: [sdb] No Caching mode page found
[33114.149852] sd 19:0:0:0: [sdb] Assuming drive cache: write through
[33114.156920]  sdb: sdb1 sdb2
[33114.157997] sd 19:0:0:0: [sdb] No Caching mode page found
[33114.158001] sd 19:0:0:0: [sdb] Assuming drive cache: write through
[33114.158004] sd 19:0:0:0: [sdb] Attached SCSI disk
[33125.448462] btrfs: device label GelmaWdUsb2T devid 1 transid 5356 /dev/dm-1
[33130.874900] btrfs: device label GelmaWdUsb2T devid 1 transid 5356
/dev/mapper/toshi
[33130.876116] btrfs: disk space caching is enabled
[33130.981694] parent transid verify failed on 789536112640 wanted
5356 found 5352
[33130.985050] parent transid verify failed on 789536112640 wanted
5356 found 5352
[33131.002965] btrfs: open_ctree failed
[33249.141036] kvm [3219]: vcpu0 disabled perfctr wrmsr: 0xc1 data 0xffff
[33395.534631] btrfs: device label GelmaWdUsb2T devid 1 transid 5356 /dev/dm-1
[33414.549954] btrfs: device label GelmaWdUsb2T devid 1 transid 5356
/dev/mapper/toshi
[33414.550582] btrfs: disk space caching is enabled
[33414.598941] parent transid verify failed on 789536112640 wanted
5356 found 5352
[33414.602385] parent transid verify failed on 789536112640 wanted
5356 found 5352
[33414.618747] btrfs: open_ctree failed

And here what happens trying the fix:
root@glen:/home/gelma/dev/prg/btrfs# ./btrfsck --repair /dev/mapper/toshi
enabling repair mode
parent transid verify failed on 789536112640 wanted 5356 found 5352
parent transid verify failed on 789536112640 wanted 5356 found 5352
parent transid verify failed on 789536112640 wanted 5356 found 5352
parent transid verify failed on 789536112640 wanted 5356 found 5352
Ignoring transid failure
Checking filesystem on /dev/mapper/toshi
UUID: 35eb15cd-d7e3-4be8-92f1-7b210353e241
checking extents
parent transid verify failed on 789310947328 wanted 5356 found 5354
parent transid verify failed on 789310947328 wanted 5356 found 5354
parent transid verify failed on 789311094784 wanted 5356 found 5354
parent transid verify failed on 789311094784 wanted 5356 found 5354
leaf parent key incorrect 789310947328
bad block 789310947328
leaf parent key incorrect 789311094784
bad block 789311094784
leaf parent key incorrect 789311143936
bad block 789311143936
Unable to find block group for 0
btrfsck: extent-tree.c:288: find_search_start: Assertion `!(1)' failed.
Annullato

I've got a backup of the harddrive, but I am far away from the last file.

Thanks a lot for your help,
Andrea

Re: Clean crash...

[Kai Krakow]

Hi!

Andrea Gelmini <andrea.gelmini@gmail.com> schrieb:

>   and thanks a lot for your work.
>   I have an USB drive with BTRFS, on which I write with different
> kernel release.
>   Anyway, today I made a copy of one big file, and than powered off
> the computer with a clean shutdown (Ubuntu 13.10 - 32bit).
>   Now it's impossible to me to mount it (even with kernel 3.12).

Some init systems are not clever enough to cleanly unmount filesystems under 
some circumstances, you usually see a log message similar to this then:

"Unable to unmount filesystem. Shutting down anyway. Good luck"

I don't remember the exact phrasing. What it essantially means is that a 
sync was issued, the init systems waits another few seconds, then shuts 
down.

For your USB connected btrfs these "few seconds" could probably not be 
enough. Btrfs tends to do a lot of background work from time to time which 
makes it lag on unmount for a few minutes sometimes especially for USB 
drives. The underlying problem could also be mounting through the device 
mapper. I'm not sure how it plays into the problem but it may introduce some 
sort of write behavior that btrfs is not aware of. I'm pretty sure I've read 
something about device mapper and write barriers not working correctly which 
are needed for btrfs being able to rely on transactions working correctly.

Either find an init system which handles this in a more sane way or simply 
unmount manually before shutting the system down and wait for the unmount to 
complete and return to command line (so do it from command line, not GUI). 
Maybe try to avoid the device mapper.

BTW, this is only guessing. And I'm sorry it doesn't help for the particular 
situation you are in currently.

Did you try to mount in recovery mode? This may, however, mount an older 
version of your superblock which does not refer to your latest additions of 
files on the disk but it may be newer than what you got in your backup.

HTH
Kai

Re: Clean crash... (USB memory sticks mount)

[Martin]

On 24/11/13 20:50, Kai Krakow wrote:

> something about device mapper and write barriers not working correctly which 
> are needed for btrfs being able to rely on transactions working correctly.

Re USB memory sticks:

I've found write barriers not to work for USB memory sticks (for at
least the ones I have tried) for ext4 and btrfs. You must mount with the
"nobarrier" option...


Regards,
Martin

Re: Clean crash...

[Andrea Gelmini]

2013/11/24 Kai Krakow <hurikhan77+btrfs@gmail.com>:
> Did you try to mount in recovery mode? This may, however, mount an older
> version of your superblock which does not refer to your latest additions of
> files on the disk but it may be newer than what you got in your backup.

Hi Kai,
   and thanks a lot for your deep reply.
   Actually with "-o recovery" I can access to a lot of files.

Thanks again,
Andrea