* Fwd: Unmountable fs after power outage [not found] <CAM7-wL0OzZU9UvFHG0GauXz+ZSHg58CaPQR33CkxNRyPg6+SSg@mail.gmail.com> @ 2016-01-22 15:11 ` Radek Sprta 2016-01-22 15:25 ` Hugo Mills 0 siblings, 1 reply; 5+ messages in thread From: Radek Sprta @ 2016-01-22 15:11 UTC (permalink / raw) To: linux-btrfs Hello everybody, after a recent power outage attempting to mount a my btrfs partition fails with the following error: mount: wrong fs type, bad option, bad superblock on /dev/sda8, missing codepage or helper program, or other error This is what dmesg shows: [ 1035.236081] BTRFS (device sda8): parent transid verify failed on 410124288 wanted 85753 found 85755 [ 1035.240756] BTRFS (device sda8): parent transid verify failed on 410124288 wanted 85753 found 85755 [ 1035.240780] BTRFS: failed to read tree root on sda8 [ 1035.252025] BTRFS: open_ctree failed Below is the result of btrfs check: Checking filesystem on /dev/sda8 UUID: b0486700-ff9f-4979-8735-257ff1428a0d checking extents checking free space cache checking fs roots checking csums checking root refs found 311702978854 bytes used err is 0 total csum bytes: 271057636 total tree bytes: 1859862528 total fs tree bytes: 1473953792 total extent tree bytes: 72876032 btree space waste bytes: 377740163 file data blocks allocated: 11278336921600 referenced 975937630208 btrfs-progs v4.0 I tried googling the "open_ctree failed" error, but couldn't find any definite answers. Here's some additional info: uname -a: Linux Computer 4.2.0-22-generic #27-Ubuntu SMP Thu Dec 17 22:57:08 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux btrfs fi show: Label: none uuid: b0486700-ff9f-4979-8735-257ff1428a0d Total devices 1 FS bytes used 290.37GiB devid 1 size 301.32GiB used 295.04GiB path /dev/sda8 Thanks in advance for any help, Radek ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Fwd: Unmountable fs after power outage 2016-01-22 15:11 ` Fwd: Unmountable fs after power outage Radek Sprta @ 2016-01-22 15:25 ` Hugo Mills 2016-02-08 12:46 ` Radek Sprta 2016-02-08 13:05 ` Qu Wenruo 0 siblings, 2 replies; 5+ messages in thread From: Hugo Mills @ 2016-01-22 15:25 UTC (permalink / raw) To: Radek Sprta; +Cc: linux-btrfs [-- Attachment #1: Type: text/plain, Size: 2541 bytes --] On Fri, Jan 22, 2016 at 04:11:53PM +0100, Radek Sprta wrote: > Hello everybody, > > after a recent power outage attempting to mount a my btrfs partition > fails with the following error: > > mount: wrong fs type, bad option, bad superblock on /dev/sda8, > missing codepage or helper program, or other error > > This is what dmesg shows: > [ 1035.236081] BTRFS (device sda8): parent transid verify failed on > 410124288 wanted 85753 found 85755 > [ 1035.240756] BTRFS (device sda8): parent transid verify failed on > 410124288 wanted 85753 found 85755 > [ 1035.240780] BTRFS: failed to read tree root on sda8 > [ 1035.252025] BTRFS: open_ctree failed Try mounting with -orecovery. That's the main approach for dealing with transid failures. > Below is the result of btrfs check: > Checking filesystem on /dev/sda8 > UUID: b0486700-ff9f-4979-8735-257ff1428a0d > checking extents > checking free space cache > checking fs roots > checking csums > checking root refs > found 311702978854 bytes used err is 0 > total csum bytes: 271057636 > total tree bytes: 1859862528 > total fs tree bytes: 1473953792 > total extent tree bytes: 72876032 > btree space waste bytes: 377740163 > file data blocks allocated: 11278336921600 > referenced 975937630208 > btrfs-progs v4.0 That looks reasonably promising -- nothing seriously damaged that btrfs check could find, at least. > I tried googling the "open_ctree failed" error, but couldn't find any > definite answers. Here's some additional info: "open_ctree failed" is a really generic error message, unfortunately. Almost every case that leads to a failure to mount will output that message, so there's no single solution you can find from just that error. The "parent transid verify failed" is a much better indication of what's happened here, and the small difference in transid numbers would indicate that -orecovery might actually have a chance of working. Hugo. > uname -a: > Linux Computer 4.2.0-22-generic #27-Ubuntu SMP Thu Dec 17 22:57:08 UTC > 2015 x86_64 x86_64 x86_64 GNU/Linux > > btrfs fi show: > Label: none uuid: b0486700-ff9f-4979-8735-257ff1428a0d > Total devices 1 FS bytes used 290.37GiB > devid 1 size 301.32GiB used 295.04GiB path /dev/sda8 > > Thanks in advance for any help, > Radek -- Hugo Mills | Always be sincere, whether you mean it or not. hugo@... carfax.org.uk | http://carfax.org.uk/ | Flanders & Swann PGP: E2AB1DE4 | The Reluctant Cannibal [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Fwd: Unmountable fs after power outage 2016-01-22 15:25 ` Hugo Mills @ 2016-02-08 12:46 ` Radek Sprta 2016-02-08 13:05 ` Qu Wenruo 1 sibling, 0 replies; 5+ messages in thread From: Radek Sprta @ 2016-02-08 12:46 UTC (permalink / raw) To: Hugo Mills, Radek Sprta, linux-btrfs 2016-01-22 16:25 GMT+01:00 Hugo Mills <hugo@carfax.org.uk>: > Try mounting with -orecovery. That's the main approach for dealing > with transid failures. Tried that, but I still get the same error. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Fwd: Unmountable fs after power outage 2016-01-22 15:25 ` Hugo Mills 2016-02-08 12:46 ` Radek Sprta @ 2016-02-08 13:05 ` Qu Wenruo 2016-02-15 10:42 ` Radek Sprta 1 sibling, 1 reply; 5+ messages in thread From: Qu Wenruo @ 2016-02-08 13:05 UTC (permalink / raw) To: Hugo Mills, Radek Sprta, linux-btrfs On 01/22/2016 11:25 PM, Hugo Mills wrote: > On Fri, Jan 22, 2016 at 04:11:53PM +0100, Radek Sprta wrote: >> Hello everybody, >> >> after a recent power outage attempting to mount a my btrfs partition >> fails with the following error: >> >> mount: wrong fs type, bad option, bad superblock on /dev/sda8, >> missing codepage or helper program, or other error >> >> This is what dmesg shows: >> [ 1035.236081] BTRFS (device sda8): parent transid verify failed on >> 410124288 wanted 85753 found 85755 >> [ 1035.240756] BTRFS (device sda8): parent transid verify failed on >> 410124288 wanted 85753 found 85755 >> [ 1035.240780] BTRFS: failed to read tree root on sda8 >> [ 1035.252025] BTRFS: open_ctree failed > > Try mounting with -orecovery. That's the main approach for dealing > with transid failures. IIRC, current "recovery" will only try to use backup roots. And that's why I am going to rename the mount option to "usebackuproot" in next kernel release. It's quite strange that current kernel doesn't have mount option to ignore transid error any longer. Just grep "RECOVERY" in btrfs modules sources, and it should be quite easy to find this fact. > >> Below is the result of btrfs check: >> Checking filesystem on /dev/sda8 >> UUID: b0486700-ff9f-4979-8735-257ff1428a0d >> checking extents >> checking free space cache >> checking fs roots >> checking csums >> checking root refs >> found 311702978854 bytes used err is 0 >> total csum bytes: 271057636 >> total tree bytes: 1859862528 >> total fs tree bytes: 1473953792 >> total extent tree bytes: 72876032 >> btree space waste bytes: 377740163 >> file data blocks allocated: 11278336921600 >> referenced 975937630208 >> btrfs-progs v4.0 > > That looks reasonably promising -- nothing seriously damaged that > btrfs check could find, at least. Quite strange. IIRC, btrfsck should at least report transid error. As written in disk-io.c, verify_parent_transid() function. Since btrfsck reports no error, I think btrfs-image could dump the metadata without problem. So, would you please dump a btrfs-image dump, by the following command? # btrfs-image -c9 /dev/sda8 Such dump will only contain your metadata(dir/file hierarchy including dir/file names), no data will be dump. And if you think the filename can leak important data, you can use '-ss' or '-s' to sanitize them. Thanks, Qu > >> I tried googling the "open_ctree failed" error, but couldn't find any >> definite answers. Here's some additional info: > > "open_ctree failed" is a really generic error message, > unfortunately. Almost every case that leads to a failure to mount will > output that message, so there's no single solution you can find from > just that error. The "parent transid verify failed" is a much better > indication of what's happened here, and the small difference in > transid numbers would indicate that -orecovery might actually have a > chance of working. > > Hugo. > >> uname -a: >> Linux Computer 4.2.0-22-generic #27-Ubuntu SMP Thu Dec 17 22:57:08 UTC >> 2015 x86_64 x86_64 x86_64 GNU/Linux >> >> btrfs fi show: >> Label: none uuid: b0486700-ff9f-4979-8735-257ff1428a0d >> Total devices 1 FS bytes used 290.37GiB >> devid 1 size 301.32GiB used 295.04GiB path /dev/sda8 >> >> Thanks in advance for any help, >> Radek > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Fwd: Unmountable fs after power outage 2016-02-08 13:05 ` Qu Wenruo @ 2016-02-15 10:42 ` Radek Sprta 0 siblings, 0 replies; 5+ messages in thread From: Radek Sprta @ 2016-02-15 10:42 UTC (permalink / raw) To: Qu Wenruo; +Cc: linux-btrfs 2016-02-08 14:05 GMT+01:00 Qu Wenruo <quwenruo.btrfs@gmx.com>: > Quite strange. > IIRC, btrfsck should at least report transid error. > As written in disk-io.c, verify_parent_transid() function. > > Since btrfsck reports no error, I think btrfs-image could dump the metadata > without problem. > > So, would you please dump a btrfs-image dump, by the following command? > # btrfs-image -c9 /dev/sda8 > > Such dump will only contain your metadata(dir/file hierarchy including > dir/file names), no data will be dump. > > And if you think the filename can leak important data, you can use '-ss' or > '-s' to sanitize them. > > Thanks, > Qu Here's the link fot the dump with -c9 -s options: http://uloz.to/xkhERuoJ/dump-txt R. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-02-15 11:08 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <CAM7-wL0OzZU9UvFHG0GauXz+ZSHg58CaPQR33CkxNRyPg6+SSg@mail.gmail.com>
2016-01-22 15:11 ` Fwd: Unmountable fs after power outage Radek Sprta
2016-01-22 15:25 ` Hugo Mills
2016-02-08 12:46 ` Radek Sprta
2016-02-08 13:05 ` Qu Wenruo
2016-02-15 10:42 ` Radek Sprta
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.