Re: Unable to boot btrfs filesystem, and btrfsck aborts
On Mon, Mar 11, 2013 at 11:49 PM, Harald Glatt wrote: > On Mon, Mar 11, 2013 at 11:44 PM, Matthew Booth wrote: >> My laptop crashed hard earlier today. It reset immediately to a black >> screen followed by the BIOS. I have no idea why. >> >> However, it now fails to boot. I took a picture of the kernel panic >> that results from trying to mount the root filesystem: >> https://plus.google.com/107763699965053810188/posts/QZZt7GYzBZi >> >> To make things worse, btrfsck aborts with a double free, without >> fixing it. I took a picture of that, too: >> https://plus.google.com/107763699965053810188/posts/gKYqGgFhWyT >> >> As the kernel panic mentions btrfs_remove_free_space, I also tried >> mounting with clear_cache. Unfortunately it didn't dislodge anything. >> >> This is on a fully updated Fedora 18 system. I would really like to >> get this data back. If anybody could offer a suggestion I'd be very >> grateful. > If you can make a complete image backup of the drive before trying any > things to bring it back. > Try mounting with -o nospace_cache, also try -o ro and -o recovery as > well as -o recovery,ro. I think the bug happens during log recovery, so btrfs-zero-log might get it mountable again, with the caveat of losing the most recently fsynced changes. -- 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: Is my btrfs filesystem definitely dead?
On Sat, Feb 23, 2013 at 11:48 PM, Sébastien Luttringer wrote: > Trying to mount the FS i got a OOPS. > # mount /dev/sdd2 /new_root > [ 60.602232] device label bitumefs devid 1 transid 40042 /dev/sdd2 > [ 60.603629] btrfs: disk space caching is enabled > [ 60.615642] Btrfs detected SSD devices, enabling SSD mode > [ 60.769651] [ cut here ] > [ 60.769709] kernel BUG at fs/btrfs/free-space-cache.c:1553! The BUG_ON in question is this one: /* * We need to search for bits in this bitmap. We could only cover some * of the extent in this bitmap thanks to how we add space, so we need * to search for as much as it as we can and clear that amount, and then * go searching for the next bit. */ search_start = *offset; search_bytes = ctl->unit; search_bytes = min(search_bytes, end - search_start + 1); ret = search_bitmap(ctl, bitmap_info, &search_start, &search_bytes); BUG_ON(ret < 0 || search_start != *offset); /* <-- 1553 */ /* We may have found more bits than what we need */ search_bytes = min(search_bytes, *bytes); Since the bug happens during log replay, I expect btrfs-zero-log will get the partition mountable again, albeit with some data loss. However, if you can, make an image of the affected partition first, to further help debug this. -- 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: kernel BUG at fs/btrfs/extent-tree.c:6185!
On Sun, Feb 3, 2013 at 1:19 PM, Radek Machulka wrote: > Hi guys, > > my computer suddenly failed to boot. It seams that it is unable to mount > /home which is btrfs. Here are the messages I get during the boot (the > relevant part; hopefully): > > Feb 02 13:59:58 Edge kernel: kernel BUG at fs/btrfs/extent-tree.c:6185! > Feb 02 13:59:58 Edge kernel: invalid opcode: [#1] PREEMPT SMP > Feb 02 13:59:58 Edge kernel: Modules linked in: joydev coretemp kvm_intel > kvm arc4 ghash_clmulni_intel aesni_intel aes_x86_64 ablk_helper snd_hda_cod > Feb 02 13:59:58 Edge kernel: CPU 1 > Feb 02 13:59:58 Edge systemd[1]: home.mount mount process exited, > code=killed status=11 > Feb 02 13:59:58 Edge kernel: Pid: 314, comm: mount Tainted: G C > 3.7.5-1-ARCH #1 LENOVO 129886G/129886G > Feb 02 13:59:58 Edge kernel: RIP: 0010:[] > [] btrfs_alloc_logged_file_extent+0x1c7/0x1e0 [btrfs] > Feb 02 13:59:58 Edge kernel: RSP: 0018:880138b53758 EFLAGS: 00010286 > Feb 02 13:59:58 Edge kernel: RAX: fff5 RBX: 880135bc4200 > RCX: 0001a7c0 > Feb 02 13:59:58 Edge kernel: RDX: ea0004dea100 RSI: 0002 > RDI: 880138bdd840 > Feb 02 13:59:58 Edge kernel: RBP: 880138b537d8 R08: 880138b53fd8 > R09: 880134ace400 > Feb 02 13:59:58 Edge kernel: R10: a029aa6c R11: 880138b53fd8 > R12: 880138b538a3 > Feb 02 13:59:58 Edge kernel: R13: R14: 00017f8f1000 > R15: 8801388b6000 > Feb 02 13:59:58 Edge kernel: FS: 7f9c55f20780() > GS:88013fa4() knlGS: > Feb 02 13:59:58 Edge kernel: CS: 0010 DS: ES: CR0: > 80050033 > Feb 02 13:59:58 Edge kernel: CR2: 0161ceb0 CR3: 000138b5c000 > CR4: 000407e0 > Feb 02 13:59:58 Edge kernel: DR0: DR1: > DR2: > Feb 02 13:59:58 Edge systemd[1]: Failed to mount /home. > Feb 02 13:59:58 Edge systemd-journal[345]: Allowing runtime journal files to > grow to 193.5M. > Feb 02 13:59:58 Edge kernel: Process mount (pid: 314, threadinfo > 880138b52000, task 880134bcc920) > Feb 02 13:59:58 Edge kernel: Stack: > Feb 02 13:59:58 Edge kernel: 0001 8000 > 880138b53788 a023a1ea > Feb 02 13:59:58 Edge kernel: 00614000 0430 > 0005 880137a81000 > Feb 02 13:59:58 Edge kernel: 8000 00ff88013788a560 > a800017f8f10 8801388b6000 > Feb 02 13:59:58 Edge kernel: Call Trace: > Feb 02 13:59:58 Edge kernel: [] ? > btrfs_free_path+0x2a/0x40 [btrfs] > Feb 02 13:59:58 Edge kernel: [] > replay_one_extent+0x620/0x690 [btrfs] > Feb 02 13:59:58 Edge kernel: [] ? > add_inode_ref+0x638/0x9e0 [btrfs] > Feb 02 13:59:58 Edge kernel: [] ? > btrfs_destroy_inode+0x1c0/0x2e0 [btrfs] > Feb 02 13:59:58 Edge kernel: [] > replay_one_buffer+0x2db/0x3a0 [btrfs] > Feb 02 13:59:58 Edge kernel: [] ? > alloc_extent_buffer+0x9d/0x490 [btrfs] > Feb 02 13:59:58 Edge kernel: [] > walk_down_log_tree+0x212/0x400 [btrfs] > Feb 02 13:59:58 Edge kernel: [] walk_log_tree+0x9d/0x1f0 > [btrfs] > Feb 02 13:59:58 Edge kernel: [] > btrfs_recover_log_trees+0x21b/0x3a0 [btrfs] > Feb 02 13:59:58 Edge kernel: [] ? > replay_one_dir_item+0xf0/0xf0 [btrfs] > Feb 02 13:59:58 Edge kernel: [] open_ctree+0x1587/0x1ba0 > [btrfs] > Feb 02 13:59:58 Edge kernel: [] ? disk_name+0x61/0xc0 > Feb 02 13:59:58 Edge kernel: [] btrfs_mount+0x633/0x770 > [btrfs] > Feb 02 13:59:58 Edge kernel: [] ? > alloc_pages_current+0xb0/0x120 > Feb 02 13:59:58 Edge kernel: [] mount_fs+0x43/0x1b0 > Feb 02 13:59:58 Edge kernel: [] vfs_kern_mount+0x74/0x110 > Feb 02 13:59:58 Edge kernel: [] do_kern_mount+0x54/0x110 > Feb 02 13:59:58 Edge kernel: [] do_mount+0x315/0x8e0 > Feb 02 13:59:58 Edge kernel: [] ? > copy_mount_options+0x3a/0x180 > Feb 02 13:59:58 Edge kernel: [] sys_mount+0x8e/0xe0 > Feb 02 13:59:58 Edge kernel: [] > system_call_fastpath+0x1a/0x1f > Feb 02 13:59:58 Edge kernel: Code: 0b 0f 1f 00 48 8d bb 80 00 00 00 e8 c4 68 > ff ff 85 c0 74 1d 48 8b 55 c0 4c 89 f6 48 89 df e8 01 c8 04 00 85 c0 0f 84 > 29 ff ff ff <0f> 0b 0f 0b 0f 0b 0f 0b 0f 0b 66 66 66 66 66 66 2e 0f 1f 84 00 > Feb 02 13:59:58 Edge kernel: RIP [] > btrfs_alloc_logged_file_extent+0x1c7/0x1e0 [btrfs] > Feb 02 13:59:58 Edge kernel: RSP > Feb 02 13:59:58 Edge kernel: ---[ end trace 03c331f97cd8632d ]--- > > > I was however able to save my data with btrfs-restore command (it boots into > some systemd emergency shell or I can use recovery cd). I tried to mount it > manually and after no success (the mount command does not end) mount it with > -o recovery option, but it does not do anything nether (well the command is > 'running' for hours without any output until I turn the pc off, so I do not > know > wheather it is recovering something or not). So before doing any btrfsck > --repair or btrfs-zero-log (which are pretty much all commands for > 'repairing' btrfs I founded over the net) I would like to ask for so
Re: cleaning old entries
On Sat, Jan 5, 2013 at 3:12 PM, Helmut Hullen wrote: > Has "mkfs.btrfs" to delete the "/dev/sdb" data when it overwrites the > configuration with data for partitions? Or has the user to run something > like "dd if=/dev/zero ..."? Take a look at: https://btrfs.wiki.kernel.org/index.php/Problem_FAQ#How_to_clean_up_old_superblock_.3F -- 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: BUG during log recovery
On Wed, Jan 2, 2013 at 6:32 PM, Josef Bacik wrote: > I posted a patch for this before I left for Christmas vacation, it is here > > http://git.kernel.org/?p=linux/kernel/git/josef/btrfs-next.git;a=commit;h=ee2399d8a7dd1d49b0996beda5b728b35bf1 > > in btrfs-next. Can you give it a whirl and let me know if it fixes your > problem? Thanks, > > Josef I'll try it when I encounter the problem again (remember I used btrfs-zero-log). I think I already told you that: We talked on Freenode, if I recall correctly. Jan -- 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: BUG during log recovery
On Tue, Dec 18, 2012 at 2:40 PM, Josef Bacik wrote:
> On Fri, Dec 14, 2012 at 03:04:08PM -0700, Jan Steffens wrote:
>> After a lockup requiring a hard reset, the btrfs could not be mounted,
>> throwing the following error:
>>
>
> Could you tell me what line this comes out to? Give me a few lines of context
> so I can figure out where it's happening. Thanks,
>
> Josef
Sure, here:
caching_ctl = get_caching_control(block_group);
if (!caching_ctl) {
BUG_ON(!block_group_cache_done(block_group));
ret = btrfs_remove_free_space(block_group, start, num_bytes);
BUG_ON(ret); /* -ENOMEM */ // <<< 6185
} else {
mutex_lock(&caching_ctl->mutex);
if (start >= caching_ctl->progress) {
ret = add_excluded_extent(root, start, num_bytes);
--
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
Snapshot bug (run_one_delayed_ref; Object already exists)
me, so more debugging on this particular filesystem will be impossible. :( btrfs-debug-tree output is available, though, if wanted (321.7 MiB xz-compressed; 3,805.0 MiB uncompressed). Regards, Jan Steffens -- 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: enquiry about defrag
On Sun, Sep 9, 2012 at 2:03 AM, ching wrote: > 2. Is there any command for the fragmentation status of a file/dir ? e.g. > fragment size, number of fragments. Use the "filefrag" command, part of e2fsprogs. -- 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: kernel BUG at fs/btrfs/inode.c:4676!
On Mon, Jun 6, 2011 at 12:19 PM, 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. > > Attached dmesg follows. > > Thank you, > Mark > > mount options: > /dev/mapper/homeDevice /home btrfs > defaults,relatime,nodev,nosuid,compress-force=lzo 0 2 # /dev/sda9 home > > dmesg: > [ 56.994241] loop: module loaded > [ 57.172283] Btrfs loaded > [ 57.191655] device label store devid 1 transid 26106 /dev/dm-3 > [ 57.218783] device label home devid 1 transid 450932 /dev/dm-2 > [ 57.459448] scsi 4:0:0:0: Direct-Access Generic- Multi-Card 1.00 > PQ: 0 ANSI: 0 CCS > [ 57.460293] sd 4:0:0:0: Attached scsi generic sg1 type 0 > [ 57.467030] sd 4:0:0:0: [sdb] Attached SCSI removable disk > [ 61.585618] EXT4-fs (sda4): warning: checktime reached, running e2fsck is > recommended > [ 61.671534] EXT4-fs (sda4): re-mounted. Opts: (null) > [ 62.211037] device label home devid 1 transid 450932 /dev/mapper/homeDevice > [ 62.212058] btrfs: force lzo compression > [ 65.335194] [ cut here ] > [ 65.335308] kernel BUG at fs/btrfs/inode.c:4676! > [ 65.335406] invalid opcode: [#1] PREEMPT SMP > [ 65.335532] last sysfs file: /sys/devices/virtual/bdi/btrfs-1/uevent > [ 65.337833] Modules linked in: btrfs zlib_deflate crc32c libcrc32c loop > uas ums_realtek uvcvideo usb_storage msr videodev media btusb bluetooth sbs > sbshc arc4 ecb b43 mac80211 joydev cfg80211 ssb mmc_core pcmcia sg fuse tg3 > uhci_hcd ideapad_laptop evdev sparse_keymap psmouse pcspkr > snd_hda_codec_realtek iTCO_wdt iTCO_vendor_support rfkill serio_raw ehci_hcd > snd_hda_intel pcmcia_core i2c_i801 libphy usbcore ac wmi battery thermal > snd_hda_codec snd_hwdep snd_pcm snd_timer snd soundcore snd_page_alloc > acpi_cpufreq freq_table processor mperf sha256_generic sha512_generic ext4 > mbcache jbd2 crc16 cryptd aes_i586 aes_generic xts gf128mul dm_crypt dm_mod > sd_mod ata_piix libata scsi_mod i915 drm_kms_helper drm i2c_algo_bit button > i2c_core video intel_agp intel_gtt agpgart > [ 65.337833] > [ 65.337833] Pid: 883, comm: mount Not tainted 2.6.39-ARCH #1 LENOVO > 41875QG /Kuril > [ 65.337833] EIP: 0060:[] EFLAGS: 00010282 CPU: 1 > [ 65.337833] EIP is at btrfs_add_link+0x172/0x200 [btrfs] > [ 65.337833] EAX: ffef EBX: ef448908 ECX: 0119 EDX: 0111 > [ 65.337833] ESI: 004255d9 EDI: 0020 EBP: eec77ba4 ESP: eec77b48 > [ 65.337833] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 > [ 65.337833] Process mount (pid: 883, ti=eec76000 task=f4c8c450 > task.ti=eec76000) > [ 65.337833] Stack: > [ 65.396712] 0020 004255d9 eec77b87 0001 e55e > f960d6f8 > [ 65.396712] eec77b88 eec77b8c eec77b90 eec77b94 ef472000 f5076800 > ef448ba8 6f43c090 > [ 65.396712] 46ab 0100 0046ab6f > eec77c0c > [ 65.396712] Call Trace: > [ 65.396712] [] ? btrfs_inode_ref_index+0xd8/0xe0 [btrfs] > [ 65.396712] [] add_inode_ref+0x28f/0x320 [btrfs] > [ 65.396712] [] replay_one_buffer+0x239/0x320 [btrfs] > [ 65.396712] [] ? alloc_extent_buffer+0x77/0x3a0 [btrfs] > [ 65.396712] [] walk_down_log_tree+0x1d9/0x370 [btrfs] > [ 65.396712] [] walk_log_tree+0x99/0x1c0 [btrfs] > [ 65.396712] [] btrfs_recover_log_trees+0x1da/0x2a0 [btrfs] > [ 65.396712] [] ? replay_one_dir_item+0xb0/0xb0 [btrfs] > [ 65.396712] [] open_ctree+0x1129/0x1490 [btrfs] > [ 65.396712] [] ? strlcpy+0x39/0x50 > [ 65.396712] [] btrfs_mount+0x4ab/0x5b0 [btrfs] > [ 65.396712] [] mount_fs+0x31/0x170 > [ 65.396712] [] vfs_kern_mount+0x4c/0x90 > [ 65.396712] [] do_kern_mount+0x39/0xd0 > [ 65.396712] [] do_mount+0x161/0x700 > [ 65.396712] [] sys_mount+0x66/0xa0 > [ 65.396712] [] sysenter_do_call+0x12/0x28 > [ 65.396712] Code: 44 24 08 00 00 00 00 89 4c 24 0c 8b 4d 08 89 34 24 e8 73 > cc fe ff 85 c0 0f 84 f0 fe ff ff 8b 5d f4 8b 75 f8 8b 7d fc 89 ec 5d c3 <0f> > 0b 8b 81 d8 fe ff ff 8d 55 e3 b9 11 00 00 00 89 d7 05 03 01 > [ 65.396712] EIP: [] btrfs_add_link+0x172/0x200 [btrfs] SS:ESP > 0068:eec77b48 > [ 65.397464] ---[ end trace 5f278c10a67bc917 ]--- > [ 65.519660] Adding 2561304k swap on /dev/mapper/swapDevice. Priority:-1 > extents:1 across:2561304k > [ 67.243199] microcode: CPU0 sig=0x106c2, pf=0x4, revision=0x20a > [ 67.292031] microcode: CPU1 sig=0x106c2, pf=0x4, revision=0x20a > [ 67.298402] microcode: Microcode Update Driver: v2.00 > , Peter Oruba > [ 67.305857] microcode: CPU0 updated to revision 0x218, date = 2009-04-10 > [ 67.315268] microcode: CPU1 updated to revision 0x218, date = 2009-04-10 > [ 70.985116] Bluetooth: BNEP (Ethernet Emulation
Re: Unable to perform online resize
On Wed, Apr 13, 2011 at 12:15 AM, Ali Lown wrote: > I am using btrfs-progs latest git head in gentoo, along with a 2.6.37 kernel. > I am unable to resize the filesystem online (or offline - though that > doesn't seem to be an option). > > with brtfs: > --- > alipc-gentoo% sudo btrfs filesystem resize +20g ~/.wine/drive_c > Resize '/home/ali/.wine/drive_c' of '+20g' > ERROR: unable to resize '/home/ali/.wine/drive_c' > --- > > with btrfs-ctl: > --- > alipc-gentoo% sudo btrfsctl -r +20g ~/.wine/drive_c > ioctl:: File too large > --- > > fdisk -l of the the drive that partiion is on (sda9 = ~/.wine/drive_c): > --- > Disk /dev/sda: 1000.2 GB, 1000204886016 bytes > 255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors > Units = sectors of 1 * 512 = 512 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 512 bytes > Disk identifier: 0x000e3826 > Device Boot Start End Blocks Id System > /dev/sda1 63 1953520064 976760001 5 Extended > /dev/sda5 1009797705 1953520064 471861180 83 Linux > /dev/sda6 642391218 1009797704 183703243+ 83 Linux > /dev/sda7 189 41945714 20972763 7 HPFS/NTFS > /dev/sda8 41945778 104856254 31455238+ 83 Linux > /dev/sda9 104856318 209712509 52428096 83 Linux > /dev/sda10 386250858 468166229 40957686 83 Linux > Partition table entries are not in disk order > --- > For help in comprehending this, here is an image from gparted: > http://img833.imageshack.us/i/gpartedd.png/ > > Apart from the hideous numbering and arrangement - I used gparted, and > made it up gradually, as and when I needed partitions. > In short for sda9, it is a logical partition inside an extended > partion (sda1), and has approximately 85GB of unpartioned space > (inside the extended partition) following it, into which I would like > to resize it. > Thanks. > -Ali > -- > 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 > btrfs resizing (like resize2fs) does not manipulate the size of partitions. First, you need to expand the partition using fdisk or gparted. Afterwards you can use "btrfs filesystem resize max ~/.wine/drive_c" to grow the filesystem to the size of the partition. -- 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
parent transid verify failed
After an unclean shutdown, my btrfs is now unmountable: device label root devid 1 transid 375202 /dev/sdc4 parent transid verify failed on 53984886784 wanted 375202 found 375201 parent transid verify failed on 53984886784 wanted 375202 found 375201 parent transid verify failed on 53984886784 wanted 375202 found 375201 btrfs: open_ctree failed btrfsck aborts: couldn't open because of unsupported option features (2). btrfsck: disk-io.c:682: open_ctree_fd: Assertion `!(1)' failed. [1]14899 abort btrfsck /dev/sdc4 Is there any way to recover the filesystem? -- 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
