Re: OOM killer and Btrfs
On Sun, Sep 4, 2016, at 12:06, Markus Trippelsdorf wrote: > On 2016.09.04 at 11:59 +0200, Francesco Turco wrote: > > Is the problem already known? Should I report a bug? Is there a patch I > > can try? Thanks. > > This issue was recently fixed by: > > commit 6b4e3181d7bd5ca5ab6f45929e4a5ffa7ab4ab7f > Author: Michal Hocko <mho...@suse.com> > Date: Thu Sep 1 16:14:41 2016 -0700 > > mm, oom: prevent premature OOM killer invocation for high order > request > > It will be backported to the 4.7.x stable kernel, too. Great, I will wait for a new 4.7.x release then :) Thank you for the info! -- https://www.fturco.net/ -- 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
OOM killer and Btrfs
I use Btrfs on a Gentoo Linux system with kernel 4.7.2. When my computer is under heavy I/O load some application often crashes, for example ClamAV, Firefox or Portage. I suspect the problem is due to Btrfs, but I may be wrong. These are the most recent error messages from journalctl, but I have many other similar ones in my logs: *** BEGIN *** Sep 04 10:13:26 desktop kernel: gpg-agent invoked oom-killer: gfp_mask=0x27080c0(GFP_KERNEL_ACCOUNT|__GFP_ZERO|__GFP_NOTRACK), order=2, oom_ Sep 04 10:13:26 desktop kernel: gpg-agent cpuset=/ mems_allowed=0 Sep 04 10:13:26 desktop kernel: CPU: 1 PID: 15883 Comm: gpg-agent Not tainted 4.7.2-gentoo #6 Sep 04 10:13:26 desktop kernel: Hardware name: /DQ35JO, BIOS JOQ3510J.86A.1143.2010.1209.0048 12/09/2010 Sep 04 10:13:26 desktop kernel: 8801258ebbb0 813db638 8801258ebd48 Sep 04 10:13:26 desktop kernel: 88009510c800 8801258ebbe8 811bbe3d 8801258ebd48 Sep 04 10:13:26 desktop kernel: 88009510c800 81e30816 001c Sep 04 10:13:26 desktop kernel: Call Trace: Sep 04 10:13:26 desktop kernel: [] dump_stack+0x4d/0x65 Sep 04 10:13:26 desktop kernel: [] dump_header+0x56/0x16e Sep 04 10:13:26 desktop kernel: [] oom_kill_process+0x218/0x3e0 Sep 04 10:13:26 desktop kernel: [] out_of_memory+0x3ba/0x460 Sep 04 10:13:26 desktop kernel: [] __alloc_pages_nodemask+0xedd/0xf00 Sep 04 10:13:26 desktop kernel: [] alloc_kmem_pages_node+0x4a/0xc0 Sep 04 10:13:26 desktop kernel: [] copy_process.part.50+0x104/0x1760 Sep 04 10:13:26 desktop kernel: [] ? check_preempt_wakeup+0x10a/0x240 Sep 04 10:13:26 desktop kernel: [] ? __set_task_blocked+0x2d/0x70 Sep 04 10:13:26 desktop kernel: [] _do_fork+0xc5/0x370 Sep 04 10:13:26 desktop kernel: [] ? SyS_pselect6+0x13a/0x220 Sep 04 10:13:26 desktop kernel: [] SyS_clone+0x14/0x20 Sep 04 10:13:26 desktop kernel: [] do_syscall_64+0x4b/0xa0 Sep 04 10:13:26 desktop kernel: [] entry_SYSCALL64_slow_path+0x25/0x25 Sep 04 10:13:26 desktop kernel: Mem-Info: Sep 04 10:13:26 desktop kernel: active_anon:173869 inactive_anon:274253 isolated_anon:0 active_file:888485 inactive_file:366424 isolated_file:0 unevictable:8 dirty:231 writeback:0 unstable:0 slab_reclaimable:240788 slab_unreclaimable:10484 mapped:46080 shmem:2372 pagetables:8521 bounce:0 free:36342 free_pcp:0 free_cma:0 Sep 04 10:13:26 desktop kernel: Node 0 DMA free:15768kB min:20kB low:32kB high:44kB active_anon:0kB inactive_anon:0kB active_file:0kB inacti Sep 04 10:13:26 desktop kernel: lowmem_reserve[]: 0 3219 7890 7890 Sep 04 10:13:26 desktop kernel: Node 0 DMA32 free:48736kB min:4632kB low:7928kB high:11224kB active_anon:164348kB inactive_anon:560608kB act Sep 04 10:13:26 desktop kernel: lowmem_reserve[]: 0 0 4671 4671 Sep 04 10:13:26 desktop kernel: Node 0 Normal free:80864kB min:6720kB low:11500kB high:16280kB active_anon:531128kB inactive_anon:536404kB a Sep 04 10:13:26 desktop kernel: lowmem_reserve[]: 0 0 0 0 Sep 04 10:13:26 desktop kernel: Node 0 DMA: 2*4kB (U) 2*8kB (U) 2*16kB (U) 1*32kB (U) 1*64kB (U) 0*128kB 1*256kB (U) 0*512kB 1*1024kB (U) 1* Sep 04 10:13:26 desktop kernel: Node 0 DMA32: 7240*4kB (UME) 2472*8kB (UME) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0 Sep 04 10:13:26 desktop kernel: Node 0 Normal: 19846*4kB (UMEH) 29*8kB (UH) 12*16kB (H) 7*32kB (H) 0*64kB 1*128kB (H) 3*256kB (H) 0*512kB 0* Sep 04 10:13:26 desktop kernel: Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB Sep 04 10:13:26 desktop kernel: 1261746 total pagecache pages Sep 04 10:13:26 desktop kernel: 4498 pages in swap cache Sep 04 10:13:26 desktop kernel: Swap cache stats: add 927111, delete 922613, find 398281/626731 Sep 04 10:13:26 desktop kernel: Free swap = 8024748kB Sep 04 10:13:26 desktop kernel: Total swap = 8388604kB Sep 04 10:13:26 desktop kernel: 2079412 pages RAM Sep 04 10:13:26 desktop kernel: 0 pages HighMem/MovableOnly Sep 04 10:13:26 desktop kernel: 53317 pages reserved Sep 04 10:13:26 desktop kernel: [ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj name Sep 04 10:13:26 desktop kernel: [ 1655] 0 16554624610346 88 3 79 0 systemd-journal Sep 04 10:13:26 desktop kernel: [ 1665] 0 166525033 145 16 3 60 0 lvmetad Sep 04 10:13:26 desktop kernel: [ 1686] 0 1686 8671 251 19 3 469 -1000 systemd-udevd Sep 04 10:13:26 desktop kernel: [ 1805] 108 180528434 243 26 4 101 0 systemd-timesyn Sep 04 10:13:26 desktop kernel: [ 1813] 109 1813 9863 1398 24
Kernel bug detected in journalctl
I discovered error messages in my systemd log after my computer froze a couple of times. This is the relevant part from journalctl: Jul 16 12:24:01 desktop kernel: BTRFS error (device dm-3): err add delayed dir index item(index: 71778) into the deletion tree of the delayed node(root id: 5, inode id: 1050941, errno: -17) Jul 16 12:24:01 desktop kernel: [ cut here ] Jul 16 12:24:01 desktop kernel: kernel BUG at fs/btrfs/delayed-inode.c:1579! Jul 16 12:24:01 desktop kernel: invalid opcode: [#1] PREEMPT SMP Jul 16 12:24:01 desktop kernel: Modules linked in: fuse mei_wdt coretemp gpio_ich iTCO_wdt iTCO_vendor_support nouveau ppdev psmouse serio_raw mxm_wmi wmi video ttm drm_kms_helper evdev drm syscopyarea input_leds mousedev sysfillrect sysimgblt kvm_intel fb_sys_fops i2c_algo_bit kvm irqbypass led_class pcspkr mac_hid i2c_i801 acpi_cpufreq snd_hda_codec_hdmi lpc_ich tpm_tis tpm parport_pc parport e1000e fjes snd_hda_codec_realtek snd_hda_codec_generic ptp snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer snd soundcore shpchp pps_core mei_me mei intel_agp intel_gtt processor button sch_fq_codel ip_tables x_tables xts gf128mul algif_skcipher af_alg dm_crypt dm_mod hid_generic usbhid hid uas usb_storage crc32c_generic btrfs xor ata_generic pata_acpi raid6_pq atkbd libps2 uhci_hcd firewire_ohci firewire_core Jul 16 12:24:01 desktop kernel: crc_itu_t pata_marvell ehci_pci ehci_hcd usbcore usb_common i8042 serio ext4 crc16 jbd2 mbcache sd_mod ahci libahci libata scsi_mod Jul 16 12:24:01 desktop kernel: CPU: 1 PID: 12815 Comm: QThread Not tainted 4.6.3-gnu-1 #1 Jul 16 12:24:01 desktop kernel: Hardware name: /DQ35JO, BIOS JOQ3510J.86A.1143.2010.1209.0048 12/09/2010 Jul 16 12:24:01 desktop kernel: task: 88019601 ti: 880069dec000 task.ti: 880069dec000 Jul 16 12:24:01 desktop kernel: RIP: 0010:[] [] btrfs_delete_delayed_dir_index+0x1f5/0x200 [btrfs] Jul 16 12:24:01 desktop kernel: RSP: 0018:880069defd38 EFLAGS: 00010246 Jul 16 12:24:01 desktop kernel: RAX: RBX: 880067139560 RCX: Jul 16 12:24:01 desktop kernel: RDX: RSI: 88022bc8db98 RDI: 88022bc8db98 Jul 16 12:24:01 desktop kernel: RBP: 880069defd88 R08: 0389 R09: 0005 Jul 16 12:24:01 desktop kernel: R10: R11: 81a746ad R12: 8800671395a8 Jul 16 12:24:01 desktop kernel: R13: 88021dbd4000 R14: 00011862 R15: 8801980e3f80 Jul 16 12:24:01 desktop kernel: FS: 7f71abfff700() GS:88022bc8() knlGS: Jul 16 12:24:01 desktop kernel: CS: 0010 DS: ES: CR0: 80050033 Jul 16 12:24:01 desktop kernel: CR2: 7f95cc00 CR3: 6a078000 CR4: 000406e0 Jul 16 12:24:01 desktop kernel: Stack: Jul 16 12:24:01 desktop kernel: 880221a23be0 3dff8800b692da78 60001009 00011862 Jul 16 12:24:01 desktop kernel: 1f383142 88006715ba38 8800b692da78 002c3a16 Jul 16 12:24:01 desktop kernel: 0010093d 880067206070 880069defe10 a02d6f81 Jul 16 12:24:01 desktop kernel: Call Trace: Jul 16 12:24:01 desktop kernel: [] __btrfs_unlink_inode+0x1b1/0x470 [btrfs] Jul 16 12:24:01 desktop kernel: [] btrfs_unlink_inode+0x1c/0x40 [btrfs] Jul 16 12:24:01 desktop kernel: [] btrfs_unlink+0x6b/0xc0 [btrfs] Jul 16 12:24:01 desktop kernel: [] vfs_unlink+0x117/0x1a0 Jul 16 12:24:01 desktop kernel: [] do_unlinkat+0x27c/0x2f0 Jul 16 12:24:01 desktop kernel: [] SyS_unlink+0x16/0x20 Jul 16 12:24:01 desktop kernel: [] entry_SYSCALL_64_fastpath+0x1a/0xa4 Jul 16 12:24:01 desktop kernel: Code: ff ff 0f 0b 48 8b 53 10 49 8b bd f0 01 00 00 41 89 c1 4c 8b 03 48 c7 c6 50 cc 35 a0 48 8b 8a 48 03 00 00 4c 89 f2 e8 1b 56 f7 ff <0f> 0b e8 14 e7 d4 e0 0f 1f 40 00 66 66 66 66 90 55 48 89 e5 53 Jul 16 12:24:01 desktop kernel: RIP [] btrfs_delete_delayed_dir_index+0x1f5/0x200 [btrfs] Jul 16 12:24:01 desktop kernel: RSP Jul 16 12:24:01 desktop kernel: ---[ end trace 86b4a59cf9b82060 ]--- I checked my btrfs partitions with "btrfs check" and fortunately they seem OK. Device dm-3 is my home partition. # btrfs filesystem show /home Label: none uuid: f5392b4f-5d1c-4c7d-89e6-0324c2860a73 Total devices 1 FS bytes used 219.82GiB devid1 size 400.00GiB used 228.06GiB path /dev/mapper/Desktop-home I'm using linux 4.6.3 and btrfs-progs 4.6.1 on a Parabola GNU/Linux-libre system. Please notice that I formatted my btrfs partitions with a live usb that may have slightly different (older) package versions. Please tell me if you need other details. -- Website: http://www.fturco.net/ GPG key: 6712 2364 B2FE 30E1 4791 EB82 7BB1 1F53 29DE CD34 -- 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: Frequent btrfs corruption on a USB flash drive
On 2016-07-07 19:57, Chris Murphy wrote: > Use F3 to test flash: > http://oss.digirati.com.br/f3/ I tested my USB flash drive with F3 as you suggested, and there's no indication it is a fake device. --- # f3probe --destructive /dev/sdb F3 probe 6.0 Copyright (C) 2010 Digirati Internet LTDA. This is free software; see the source for copying conditions. WARNING: Probing normally takes from a few seconds to 15 minutes, but it can take longer. Please be patient. Good news: The device `/dev/sdb' is the real thing Device geometry: *Usable* size: 57.69 GB (120979456 blocks) Announced size: 57.69 GB (120979456 blocks) Module: 64.00 GB (2^36 Bytes) Approximate cache size: 0.00 Byte (0 blocks), need-reset=no Physical block size: 512.00 Byte (2^9 Bytes) Probe time: 2'23" -- $ f3read /run/media/fturco/a7d8a7b1-e0c2-4fbb-879f-e17046989f3c SECTORS ok/corrupted/changed/overwritten Validating file 1.h2w ... 2097152/0/ 0/ 0 Validating file 2.h2w ... 2097152/0/ 0/ 0 Validating file 3.h2w ... 2097152/0/ 0/ 0 Validating file 4.h2w ... 2097152/0/ 0/ 0 Validating file 5.h2w ... 2097152/0/ 0/ 0 Validating file 6.h2w ... 2097152/0/ 0/ 0 Validating file 7.h2w ... 2097152/0/ 0/ 0 Validating file 8.h2w ... 2097152/0/ 0/ 0 Validating file 9.h2w ... 2097152/0/ 0/ 0 Validating file 10.h2w ... 2097152/0/ 0/ 0 Validating file 11.h2w ... 2097152/0/ 0/ 0 Validating file 12.h2w ... 2097152/0/ 0/ 0 Validating file 13.h2w ... 2097152/0/ 0/ 0 Validating file 14.h2w ... 2097152/0/ 0/ 0 Validating file 15.h2w ... 2097152/0/ 0/ 0 Validating file 16.h2w ... 2097152/0/ 0/ 0 Validating file 17.h2w ... 2097152/0/ 0/ 0 Validating file 18.h2w ... 2097152/0/ 0/ 0 Validating file 19.h2w ... 2097152/0/ 0/ 0 Validating file 20.h2w ... 2097152/0/ 0/ 0 Validating file 21.h2w ... 2097152/0/ 0/ 0 Validating file 22.h2w ... 2097152/0/ 0/ 0 Validating file 23.h2w ... 2097152/0/ 0/ 0 Validating file 24.h2w ... 2097152/0/ 0/ 0 Validating file 25.h2w ... 2097152/0/ 0/ 0 Validating file 26.h2w ... 2097152/0/ 0/ 0 Validating file 27.h2w ... 2097152/0/ 0/ 0 Validating file 28.h2w ... 2097152/0/ 0/ 0 Validating file 29.h2w ... 2097152/0/ 0/ 0 Validating file 30.h2w ... 2097152/0/ 0/ 0 Validating file 31.h2w ... 2097152/0/ 0/ 0 Validating file 32.h2w ... 2097152/0/ 0/ 0 Validating file 33.h2w ... 2097152/0/ 0/ 0 Validating file 34.h2w ... 2097152/0/ 0/ 0 Validating file 35.h2w ... 2097152/0/ 0/ 0 Validating file 36.h2w ... 2097152/0/ 0/ 0 Validating file 37.h2w ... 2097152/0/ 0/ 0 Validating file 38.h2w ... 2097152/0/ 0/ 0 Validating file 39.h2w ... 2097152/0/ 0/ 0 Validating file 40.h2w ... 2097152/0/ 0/ 0 Validating file 41.h2w ... 2097152/0/ 0/ 0 Validating file 42.h2w ... 2097152/0/ 0/ 0 Validating file 43.h2w ... 2097152/0/ 0/ 0 Validating file 44.h2w ... 2097152/0/ 0/ 0 Validating file 45.h2w ... 2097152/0/ 0/ 0 Validating file 46.h2w ... 2097152/0/ 0/ 0 Validating file 47.h2w ... 2097152/0/ 0/ 0 Validating file 48.h2w ... 2097152/0/ 0/ 0 Validating file 49.h2w ... 2097152/0/ 0/ 0 Validating file 50.h2w ... 2097152/0/ 0/ 0 Validating file 51.h2w ... 2097152/0/ 0/ 0 Validating file 52.h2w ... 2097152/0/ 0/ 0 Validating file 53.h2w ... 2097152/0/ 0/ 0 Validating file 54.h2w ... 2097152/0/ 0/ 0 Validating file 55.h2w ... 2097152/0/ 0/ 0 Validating file 56.h2w ... 1364266/0/ 0/ 0 Data OK: 55.65 GB (116707626 sectors) Data LOST: 0.00 Byte (0 sectors) Corrupted: 0.00 Byte (0 sectors) Slightly changed: 0.00 Byte (0 sectors) Overwritten: 0.00 Byte (0 sectors) Average reading speed: 34.73 MB/s > Read more, and also includes a much faster alternative for GNOME: > https://blogs.gnome.org/hughsie/2015/01/28/detecting-fake-flash/ I also tested my flash drive with gnome-multi-writer-probe, and it says it is not fake: # gnome-multi-writer-probe /dev/sdb Device is GOOD I also created a big
Re: Frequent btrfs corruption on a USB flash drive
On 2016-07-07 23:11, Andrew E. Mileski wrote: > How large is this USB flash device? 64 GB. -- Website: http://www.fturco.net/ GPG key: 6712 2364 B2FE 30E1 4791 EB82 7BB1 1F53 29DE CD34 -- 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: Frequent btrfs corruption on a USB flash drive
On 2016-07-07 20:25, Chris Murphy wrote: > On Thu, Jul 7, 2016 at 8:55 AM, Francesco Turco <ftu...@fastmail.fm> wrote: >> Perhaps I >> should try to rule out an hardware problem by filling my USB flash drive >> with a large random file and then checking if its SHA-1 checksum >> corresponds to the original copy on the hard disk. But first I probably >> should backup the current Btrfs filesystem with the dd command. Can I >> proceed? > > https://btrfs.wiki.kernel.org/index.php/Gotchas Thank you for the link, I didn't know that using LVM snapshots or mounting dd copies can create problems! That could explain the reason for some of the problems I had in the past. -- Website: http://www.fturco.net/ GPG key: 6712 2364 B2FE 30E1 4791 EB82 7BB1 1F53 29DE CD34 -- 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: Frequent btrfs corruption on a USB flash drive
On 2016-07-07 16:27, Austin S. Hemmelgarn wrote: > This seems odd, are you trying to access anything over NFS or some other > network filesystem protocol here? If not, then I believe you've found a > bug, because I'm pretty certain we shouldn't be returning -ESTALE for > anything. No, I don't use NFS or any other network filesystem. > The question here is: Do you get any data corruption when using ext4? > Quite often when there's a hardware issue, you won't see _any_ > indication of it other than corrupted files when using something like > ext4 or XFS, but it will show up almost immediately with BTRFS because > we validate checksums on almost everything. There have been at least a > couple of times I've found disk issues while converting from ext4 to > BTRFS that I didn't know existed before, and then going back was able to > reliable reproduce using other tools. > > Also, FWIW, badblocks is not necessarily a reliable test method for > flash drives, they often handle serialized reads like badblocks does > very well even when failing. I'm not sure. Commands don't fail explicitely when I use ext4, but I agree with you that I may get corruption silently nonetheless. Perhaps I should try to rule out an hardware problem by filling my USB flash drive with a large random file and then checking if its SHA-1 checksum corresponds to the original copy on the hard disk. But first I probably should backup the current Btrfs filesystem with the dd command. Can I proceed? > Just to clarify, you're using BTRFS on top of disk encryption (LUKS? Or > is it just raw encryption, or even something completely different?), on > a USB flash drive (not a USB to SATA adapter with an SSD or HDD in it), > correct? I'm using a btrfs filesystem on a GUID partition encrypted with LUKS. It's a Kingston USB flash drive connected directly to my desktop machine via USB. It's definitively not a SSD or a HDD, and I'm not using any adapter. -- Website: http://www.fturco.net/ GPG key: 6712 2364 B2FE 30E1 4791 EB82 7BB1 1F53 29DE CD34 -- 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
Frequent btrfs corruption on a USB flash drive
I have a USB flash drive with an encrypted Btrfs filesystem where I
store daily backups. My problem is that this btrfs filesystem gets
corrupted very often, after a few days of usage. Usually I just reformat
it and move along, but this time I'd like to understand the root cause
of the problem and fix it.
I can mount the partition without problems, but then when using commands
such as rsync or even humble ls I get the following error message:
$ rsync /home/fturco/Buffer/E-book/
/run/media/fturco/5283147c-b7b4-448f-97b0-b235344a56a3/Buffer/E-book/
--recursive
rsync:
readlink_stat("/run/media/fturco/5283147c-b7b4-448f-97b0-b235344a56a3/Riviste")
failed: Stale file handle (116)
rsync:
readlink_stat("/run/media/fturco/5283147c-b7b4-448f-97b0-b235344a56a3/Backup")
failed: Stale file handle (116)
rsync:
readdir("/run/media/fturco/5283147c-b7b4-448f-97b0-b235344a56a3/Calibre
(TMSU)"): Input/output error (5)
The previous command gets stuck and I had to manually stop it.
The following command doesn't return any output, but its exit code is 1
(failure):
$ btrfs filesystem show
/run/media/fturco/5283147c-b7b4-448f-97b0-b235344a56a3
$
Btrfs-check reports many errors. I attached the output to this e-mail
message.
Output from dmesg:
$ dmesg | tail
[18756.159963] BTRFS error (device dm-4): bad tree block start
6592115285688248773 35323904
[18756.160828] BTRFS error (device dm-4): bad tree block start
8533404122473270145 35323904
[18756.161821] BTRFS error (device dm-4): bad tree block start
6592115285688248773 35323904
[18756.163047] BTRFS error (device dm-4): bad tree block start
8533404122473270145 35323904
[18756.163921] BTRFS error (device dm-4): bad tree block start
6592115285688248773 35323904
[18756.164806] BTRFS error (device dm-4): bad tree block start
8533404122473270145 35323904
[18756.165673] BTRFS error (device dm-4): bad tree block start
6592115285688248773 35323904
[18756.166548] BTRFS error (device dm-4): bad tree block start
8533404122473270145 35323904
[18757.950603] BTRFS error (device dm-4): bad tree block start
6592115285688248773 35323904
[18757.951492] BTRFS error (device dm-4): bad tree block start
8533404122473270145 35323904
I checked this USB flash drive with badblocks in non-destructive
read-write mode. No errors.
If I format this partition as Ext4 instead of Btrfs I can use it without
problems, but my goal is to use Btrfs on all devices.
My GNU/Linux distribution is Parabola GNU/Linux-libre.
Kernel version is: 4.6.3.
Btrfs-progs version is: 4.6
Please tell me if you need other details. Thanks.
--
Website: http://www.fturco.net/
GPG key: 6712 2364 B2FE 30E1 4791 EB82 7BB1 1F53 29DE CD34
# btrfs check --readonly /dev/mapper/luks-08e23ed4-a2a1-41f0-a5f6-794ff0647ada
Checking filesystem on /dev/mapper/luks-08e23ed4-a2a1-41f0-a5f6-794ff0647ada
UUID: 5283147c-b7b4-448f-97b0-b235344a56a3
checking extents
checksum verify failed on 35274752 found E042416D wanted 4CD1CFA0
checksum verify failed on 35274752 found E042416D wanted 4CD1CFA0
checksum verify failed on 35274752 found E8B38F1B wanted B3F4F728
checksum verify failed on 35274752 found E042416D wanted 4CD1CFA0
bytenr mismatch, want=35274752, have=6970279768983377651
checksum verify failed on 35291136 found 6B9667D1 wanted CDED2E29
checksum verify failed on 35291136 found 6B9667D1 wanted CDED2E29
checksum verify failed on 35291136 found 607F5103 wanted F21126A3
checksum verify failed on 35291136 found 6B9667D1 wanted CDED2E29
bytenr mismatch, want=35291136, have=16962852950865328208
checksum verify failed on 35307520 found 088ACE59 wanted 22164173
checksum verify failed on 35307520 found 088ACE59 wanted 22164173
checksum verify failed on 35307520 found F59BACEE wanted E647A1CD
checksum verify failed on 35307520 found 088ACE59 wanted 22164173
bytenr mismatch, want=35307520, have=16013504349018505369
checksum verify failed on 35323904 found CA154283 wanted 10E9FA6B
checksum verify failed on 35323904 found CA154283 wanted 10E9FA6B
checksum verify failed on 35323904 found 4DA7B234 wanted 794014C7
checksum verify failed on 35323904 found 4DA7B234 wanted 794014C7
bytenr mismatch, want=35323904, have=8533404122473270145
parent transid verify failed on 35340288 wanted 44 found 37
parent transid verify failed on 35340288 wanted 44 found 37
parent transid verify failed on 35340288 wanted 44 found 37
parent transid verify failed on 35340288 wanted 44 found 37
Ignoring transid failure
leaf parent key incorrect 35340288
bad block 35340288
Errors found in extent allocation tree or chunk allocation
checking free space cache
checking fs roots
parent transid verify failed on 35340288 wanted 44 found 37
Ignoring transid failure
parent transid verify failed on 35340288 wanted 44 found 37
Ignoring transid failure
parent transid verify failed on 35340288 wanted 44 found 37
Ignoring transid failure
parent transid verify failed on 35340288 wanted 44 found 37
Ignoring transid failure
checksum verify failed on 35274752 found E042416D wanted 4CD1CFA0
checksum
Re: Btrfs check command fails with "assertion failed" error
On 2016-06-28 20:20, Francesco Turco wrote: > So I'm going to submit a bug as you suggested. Done: https://bugzilla.kernel.org/show_bug.cgi?id=12 I also found another similar bug: https://bugzilla.kernel.org/show_bug.cgi?id=104821 -- Website: http://www.fturco.net/ GPG key: 6712 2364 B2FE 30E1 4791 EB82 7BB1 1F53 29DE CD34 -- 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: Btrfs check command fails with "assertion failed" error
On 2016-06-28 20:05, Chris Murphy wrote: > Well it probably shouldn't crash but the question is why is device 4 > missing? We have no information what version of btrfs-progs or kernel > is used, or what the layout of this volume is: how many devices, > what's the profile breakdown, etc. Are you attempting to fix a > degraded volume and are the minimum number of devices present? Btrfs > fi show would be useful for this. > > If it's relatively recent version of btrfs-progs then I'd file a bug > just because it shouldn't crash, it should give some sort of coherent > message about why it can't proceed. Sorry for the missing informations. Here you are: - linux-libre: 4.6.2 - btrfs-progs: 4.5.3 # btrfs filesystem show /dev/loop0 warning, device 4 is missing Label: none uuid: 34fb5b58-f50f-47c3-a5b8-91d81a30eade Total devices 2 FS bytes used 5.17GiB devid1 size 30.00GiB used 30.00GiB path /dev/loop0 *** Some devices missing If I remember correctly I extended that root filesystem with some additional space from a file in the home directory, in the hope of fixing a problem with btrfs balance and not enough space. I don't have the additional file anymore, so I probably won't be able to mount this image file anymore. Anyway as you said btrfs-check shouldn't crash. So I'm going to submit a bug as you suggested. Thanks. -- Website: http://www.fturco.net/ GPG key: 6712 2364 B2FE 30E1 4791 EB82 7BB1 1F53 29DE CD34 -- 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 check command fails with "assertion failed" error
When trying to repair a btrfs root filesystem I get the following error message: # losetup -f /home/fturco/Buffer/root-20160616.img # btrfs check --repair /dev/loop0 enabling repair mode warning, device 4 is missing Checking filesystem on /dev/loop0 UUID: 34fb5b58-f50f-47c3-a5b8-91d81a30eade checking extents Unable to find block group for 0 extent-tree.c:289: find_search_start: Assertion `1` failed. btrfs[0x44882e] btrfs(btrfs_reserve_extent+0xaa9)[0x44d639] btrfs(btrfs_alloc_free_block+0x5f)[0x44d6ff] btrfs(__btrfs_cow_block+0xc4)[0x43e9d4] btrfs(btrfs_cow_block+0x35)[0x43efd5] btrfs[0x4442e6] btrfs(btrfs_commit_transaction+0x95)[0x446115] btrfs[0x42b58e] btrfs(cmd_check+0x76c)[0x42c60c] btrfs(main+0x7b)[0x40ac3b] /usr/lib/libc.so.6(__libc_start_main+0xf1)[0x7f272f658741] btrfs(_start+0x29)[0x40ad39] This is an unmountable filesystem: # mount /dev/loop0 /mnt/ mount: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so. # dmesg | tail [ 9185.503571] scsi 8:0:0:1: Direct-Access Samsung File-CD Gadget PQ: 0 ANSI: 2 [ 9185.513943] sd 8:0:0:0: [sdb] Attached SCSI removable disk [ 9185.514565] sd 8:0:0:1: [sdc] Attached SCSI removable disk [13773.533435] usb 1-4: USB disconnect, device number 8 [31454.672925] loop: module loaded [31455.600069] BTRFS: device fsid 34fb5b58-f50f-47c3-a5b8-91d81a30eade devid 1 transid 81460 /dev/loop0 [32584.640398] BTRFS info (device loop0): disk space caching is enabled [32584.640403] BTRFS: has skinny extents [32584.654196] BTRFS: failed to read the system array on loop0 [32584.666774] BTRFS: open_ctree failed Fortunately I have no valuable content in that image file and I restored the system from a recent backup, but I still wonder if there's a bug somewhere in btrfs-check. Do you need other debug informations perhaps? -- Website: http://www.fturco.net/ GPG key: 6712 2364 B2FE 30E1 4791 EB82 7BB1 1F53 29DE CD34 -- 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: Btrfs full balance command fails due to ENOSPC (bug 121071)
On 2016-06-27 23:47, Hans van Kranenburg wrote: > Since the existence of python-btrfs, it has gathered a few useful > example scripts: > > git clone https://github.com/knorrie/python-btrfs > cd python-btrfs/examples/ > (get root prompt) > > ./show_usage.py /mountpoint <- view sorted by 'virtual' address space > ./show_dev_extents.py /mountpoint <- view sorted by physical layout > > The show_usage in the btrfs-heatmap repo is almost gone. I'm currently > replacing all the proof of concept playing around stuff in there with > dedicated png-creation code that uses the python-btrfs lib. I also issued the show_dev_extents.py command as you suggested. Hope it helps. -- Website: http://www.fturco.net/ GPG key: 6712 2364 B2FE 30E1 4791 EB82 7BB1 1F53 29DE CD34 -- 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: Btrfs full balance command fails due to ENOSPC (bug 121071)
On 2016-06-27 23:26, Henk Slager wrote: > btrfs-debug does not show metadata ans system chunks; the balancing > problem might come from those. > This script does show all chunks: > https://github.com/knorrie/btrfs-heatmap/blob/master/show_usage.py > > You might want to use vrange or drange balance filters so that you can > just target a certain chunk and maybe that gives a hint where the > problem might be. But anyhow, the behavior experienced is a bug. Updated the bug with the output log from your script. I simply ran it as: ./show_usage.py / I don't know how to use vrange/drange balance filters. Can you show me how to do that, please? -- Website: http://www.fturco.net/ GPG key: 6712 2364 B2FE 30E1 4791 EB82 7BB1 1F53 29DE CD34 -- 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: Btrfs full balance command fails due to ENOSPC (bug 121071)
On 2016-06-27 20:18, Chris Murphy wrote: > If you can grab btrfs-debugfs from > https://github.com/kdave/btrfs-progs/blob/master/btrfs-debugfs > > And then attach the output to the bug report it might be useful for a > developer. But really your case is an odd duck, because there's fully > 14GiB unallocated, so it should be able to create a new one without > problem. > > $ sudo ./btrfs-debugfs -b / Done! Thank you, I was not aware of the existence of btrfs-debug... -- Website: http://www.fturco.net/ GPG key: 6712 2364 B2FE 30E1 4791 EB82 7BB1 1F53 29DE CD34 -- 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 full balance command fails due to ENOSPC (bug 121071)
Note: I already filed bug 121071 but perhaps I should have written to this mailing list first. I get the ENOSPC error when running a btrfs full balance command for my root partition, even if it seems I have a lot of free/unallocated space. # btrfs filesystem show / Label: none uuid: 27150b83-7d90-4031-8e83-581315b9a254 Total devices 1 FS bytes used 10.79GiB devid1 size 25.00GiB used 13.31GiB path /dev/mapper/Desktop-root # btrfs filesystem df / Data, single: total=11.00GiB, used=10.40GiB System, DUP: total=32.00MiB, used=16.00KiB Metadata, DUP: total=1.12GiB, used=392.08MiB GlobalReserve, single: total=144.00MiB, used=0.00B # btrfs balance start --full-balance / ERROR: error during balancing '/': No space left on device There may be more info in syslog - try dmesg | tail # dmesg | tail [29807.441930] BTRFS info (device dm-2): found 13206 extents [29807.879845] BTRFS info (device dm-2): relocating block group 47542435840 flags 1 [29827.116083] BTRFS info (device dm-2): found 12909 extents [29830.500110] BTRFS info (device dm-2): found 12909 extents [29830.976485] BTRFS info (device dm-2): relocating block group 46468694016 flags 1 [29848.924188] BTRFS info (device dm-2): found 5129 extents [29851.533076] BTRFS info (device dm-2): found 5129 extents [29851.994787] BTRFS info (device dm-2): relocating block group 46435139584 flags 34 [29852.399460] BTRFS info (device dm-2): found 1 extents [29852.657983] BTRFS info (device dm-2): 1 enospc errors during balance I have successfully balanced both the boot and home partitions before. Only root gives me problems. Is there anything I can try? Should I run the command from a live CD? Is this a real bug or a mistake from an unexperienced btrfs user like me? Thanks. -- Website: http://www.fturco.net/ GPG key: 6712 2364 B2FE 30E1 4791 EB82 7BB1 1F53 29DE CD34 -- 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
