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 -- 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
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 -- 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 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 -- 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
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 -- 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