Re: Unmountable btrfs after power failure
Thank you all for the quick response! For anyone running into similar issues: I updated my kernel, and then ran btrfs-zero-log. Everything worked fine, and the drive is mountable with no issues so far. -Jon On Wed, Sep 9, 2015 at 12:27 PM, Roman Mamedov wrote: > On Wed, 9 Sep 2015 17:19:51 + > Hugo Mills wrote: > >>The bug you've hit is almost certainly fixed in more recent >> kernels. I can't recommend stongly enough that you upgrade it (or >> contact your vendor's support department to find out how they will >> support your use of btrfs on a kernel that old). 3.19 is about the >> earliest kernel I'd feel happy about using at this point. > > 3.19 is EOL and is not featured on https://www.kernel.org/ anymore. > > I hope 3.18 is also good enough, for those of us who prefer to stay on a > "longterm" kernel and not jump every time onto a new series only to find out > that it's in fact destined to go into the EOL trashcan. (There's a certain > amount of tinkering with the .config required each time when switching > releases, and I'd like to minimize that). > > -- > With respect, > Roman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unmountable btrfs after power failure
On Wed, 9 Sep 2015 17:19:51 + Hugo Mills wrote: >The bug you've hit is almost certainly fixed in more recent > kernels. I can't recommend stongly enough that you upgrade it (or > contact your vendor's support department to find out how they will > support your use of btrfs on a kernel that old). 3.19 is about the > earliest kernel I'd feel happy about using at this point. 3.19 is EOL and is not featured on https://www.kernel.org/ anymore. I hope 3.18 is also good enough, for those of us who prefer to stay on a "longterm" kernel and not jump every time onto a new series only to find out that it's in fact destined to go into the EOL trashcan. (There's a certain amount of tinkering with the .config required each time when switching releases, and I'd like to minimize that). -- With respect, Roman signature.asc Description: PGP signature
Re: Unmountable btrfs after power failure
uOn Wed, Sep 09, 2015 at 10:30:33AM -0500, Jon Keane wrote: > I recently had a power failure, and ever since I have been unable to > mount one of my btrfs drives (data is the one that is failing to > mount, store is fine). I’m running: > > jkeane@bet:~$ uname -a > > Linux bet 3.8.0-33-generic #48-Ubuntu SMP Wed Oct 23 09:16:58 UTC 2013 > x86_64 x86_64 x86_64 GNU/Linux This is almost certainly why you're having the problem in the first place. This is an old kernel (2 years old, even by the compilation date -- the code base is probably even older), and back then, btrfs didn't really cope with power loss or unclean reboots very well. [snip] > Sep 9 10:12:06 bet kernel: [ 1515.314122] [] > replay_one_buffer+0x2ab/0x350 [btrfs] > > Sep 9 10:12:06 bet kernel: [ 1515.314161] [] ? > alloc_extent_buffer+0x97/0x400 [btrfs] > > Sep 9 10:12:06 bet kernel: [ 1515.314200] [] ? > check_buffer_tree_ref+0x3c/0x50 [btrfs] > > Sep 9 10:12:06 bet kernel: [ 1515.314239] [] > walk_down_log_tree+0x212/0x400 [btrfs] > > Sep 9 10:12:06 bet kernel: [ 1515.314277] [] > walk_log_tree+0x9d/0x1f0 [btrfs] > > Sep 9 10:12:06 bet kernel: [ 1515.314313] [] ? > btrfs_read_fs_root_no_name+0x1d3/0x310 [btrfs] > > Sep 9 10:12:06 bet kernel: [ 1515.314352] [] > btrfs_recover_log_trees+0x215/0x390 [btrfs] [snip] -- > > > Many of these look similar to the ones described at > https://btrfs.wiki.kernel.org/index.php/Btrfs-zero-log I have not yet > tried zeroing the log, because I’m not seeing all of the messages that > are specific on the FAQ. I suspect that is what I need to do, but I > wanted to check here first. Yes, zeroing the log here will probably help. > Please let me know if there is any more information I can provide to > help track this down. Thanks! The bug you've hit is almost certainly fixed in more recent kernels. I can't recommend stongly enough that you upgrade it (or contact your vendor's support department to find out how they will support your use of btrfs on a kernel that old). 3.19 is about the earliest kernel I'd feel happy about using at this point. Hugo. -- Hugo Mills | UNIX: Japanese brand of food containers hugo@... carfax.org.uk | http://carfax.org.uk/ | PGP: E2AB1DE4 | signature.asc Description: Digital signature
Unmountable btrfs after power failure
I recently had a power failure, and ever since I have been unable to mount one of my btrfs drives (data is the one that is failing to mount, store is fine). I’m running: jkeane@bet:~$ uname -a Linux bet 3.8.0-33-generic #48-Ubuntu SMP Wed Oct 23 09:16:58 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux jkeane@bet:~$ btrfs --version Btrfs v3.12 jkeane@bet:~$ sudo btrfs fi show -d Label: 'store' uuid: 91f14b43-16d6-4411-9f0c-48b7959c6e48 Total devices 2 FS bytes used 684.82GiB devid1 size 1.82TiB used 688.03GiB path /dev/sdd devid2 size 1.82TiB used 688.01GiB path /dev/sde Label: 'data' uuid: f526f5d4-591a-4983-90e8-57ec5d991951 Total devices 2 FS bytes used 1.72TiB devid1 size 3.64TiB used 1.73TiB path /dev/sdb devid2 size 3.64TiB used 1.73TiB path /dev/sdc Btrfs v3.12 When I try and mount the drive, I get the following errors: Sep 9 10:11:38 bet kernel: [ 1487.751656] device label data devid 1 transid 42367 /dev/sdb Sep 9 10:11:38 bet kernel: [ 1487.776604] btrfs: enabling auto recovery Sep 9 10:11:38 bet kernel: [ 1487.776618] btrfs: disabling disk space caching Sep 9 10:11:38 bet sec[1462]: Feeding event 'Wed Sep 9 10:11:38 2015: Sep 9 10:11:38 bet kernel: [ 1487.776604] btrfs: enabling auto recovery' to shell command '/usr/bin/mail -s "sec: Btrfs unexpected log" root' Sep 9 10:11:38 bet sec[1462]: Child 5492 created for command '/usr/bin/mail -s "sec: Btrfs unexpected log" root' Sep 9 10:11:38 bet postfix/pickup[2127]: F36183606EF: uid=0 from= Sep 9 10:11:39 bet postfix/cleanup[5498]: F36183606EF: message-id=<20150909151138.F36183606EF@bet.localdomain> Sep 9 10:11:39 bet postfix/qmgr[2128]: F36183606EF: from=, size=455, nrcpt=1 (queue active) Sep 9 10:11:39 bet postfix/local[5500]: warning: dict_nis_init: NIS domain name not set - NIS lookups disabled Sep 9 10:11:39 bet postfix/local[5500]: F36183606EF: to=, orig_to=, relay=local, delay=0.06, delays=0.03/0.02/0/0, dsn=2.0.0, status=sent (delivered to mailbox) Sep 9 10:11:39 bet postfix/qmgr[2128]: F36183606EF: removed Sep 9 10:12:06 bet kernel: [ 1515.313696] [ cut here ] Sep 9 10:12:06 bet kernel: [ 1515.313708] Kernel BUG at a01472c7 [verbose debug info unavailable] Sep 9 10:12:06 bet kernel: [ 1515.313714] invalid opcode: [#1] SMP Sep 9 10:12:06 bet kernel: [ 1515.313721] Modules linked in: rfcomm bnep binfmt_misc(F) snd_hda_codec_hdmi hid_generic kvm_amd(F) kvm(F) microcode(F) serio_raw(F) k10temp edac_core edac_mce_amd usbhid hid sp5100_tco i2c_piix4 snd_hda_codec_via btusb snd_hda_intel snd_hda_codec bluetooth snd_hwdep(F) snd_pcm(F) snd_page_alloc(F) snd_seq_midi(F) snd_seq_midi_event(F) snd_rawmidi(F) snd_seq(F) snd_seq_device(F) snd_timer(F) snd(F) nvidia(POF) drm soundcore(F) asus_atk0110 wmi mac_hid parport_pc(F) ppdev(F) shpchp lp(F) parport(F) btrfs(F) zlib_deflate(F) libcrc32c(F) raid10(F) raid456(F) async_raid6_recov(F) async_memcpy(F) async_pq(F) async_xor(F) xor(F) async_tx(F) pata_acpi psmouse(F) pata_atiixp r8169 raid6_pq(F) raid1(F) raid0(F) ahci(F) libahci(F) multipath(F) linear(F) Sep 9 10:12:06 bet kernel: [ 1515.313808] CPU 1 Sep 9 10:12:06 bet kernel: [ 1515.313818] Pid: 5477, comm: mount Tainted: PF O 3.8.0-33-generic #48-Ubuntu System manufacturer System Product Name/M4A77TD Sep 9 10:12:06 bet kernel: [ 1515.313824] RIP: 0010:[] [] remove_from_bitmap+0x1b7/0x1c0 [btrfs] Sep 9 10:12:06 bet kernel: [ 1515.313873] RSP: 0018:88011b6df7a8 EFLAGS: 00010287 Sep 9 10:12:06 bet kernel: [ 1515.313878] RAX: 01a061e3a000 RBX: 880111d5fdc0 RCX: 880106c352e4 Sep 9 10:12:06 bet kernel: [ 1515.313883] RDX: a000 RSI: 8000 RDI: 3dc0 Sep 9 10:12:06 bet kernel: [ 1515.313887] RBP: 88011b6df7f0 R08: 8801190ad850 R09: 4240 Sep 9 10:12:06 bet kernel: [ 1515.313892] R10: ea0004c5d2c0 R11: a00f3044 R12: 880106c352c0 Sep 9 10:12:06 bet kernel: [ 1515.313896] R13: 88011b6df810 R14: 88011b6df808 R15: 01a065c0 Sep 9 10:12:06 bet kernel: [ 1515.313902] FS: 7f2bad846880() GS:880137c4() knlGS:f73a8700 Sep 9 10:12:06 bet kernel: [ 1515.313907] CS: 0010 DS: ES: CR0: 8005003b Sep 9 10:12:06 bet kernel: [ 1515.313911] CR2: 7f2ca5144000 CR3: 000119699000 CR4: 07e0 Sep 9 10:12:06 bet kernel: [ 1515.313916] DR0: DR1: DR2: Sep 9 10:12:06 bet kernel: [ 1515.313921] DR3: DR6: 0ff0 DR7: 0400 Sep 9 10:12:06 bet kernel: [ 1515.313926] Process mount (pid: 5477, threadinfo 88011b6de000, task 88012dab45c0) Sep 9 10:12:06 bet kernel: [ 1515.313929] Stack: Sep 9 10:12:06 bet kernel: [ 1515.313933] 880106c352e4 01a061e3c000 a000 Sep 9 10:12:06 bet kernel: [ 1515.313942] 880106c352c0 880106c352e4 0001 8801
