Re: duplicate automounts with btrfs RAID1
is anything in dmesg that would point to diskscontrollers being reset? or something like that? pavol On Wed, Mar 2, 2016 at 9:34 PM, Leigh Orf wrote: > Hello, > > Not entirely sure this is a btrfs issue, but here is my problem. I've > had this issue with recent Fedora and CentOS distros. > > I created a btrfs RAID 1 pair with two identical USB external drives, > following the instructions found online: > > mkfs.btrfs -m raid1 -d raid1 /dev/sdc1 /dev/sdd1 > > Then I mount it as /ext1: > > % df |grep sdc > /dev/sdc1 9767539112 1280 9765383552 1% /ext1 > > The problem? Over time, /dev/sdc1 keeps getting mounted under a > different mount point, these accrue a couple per day: > > % mount|grep sdc > /dev/sdc1 on /ext1 type btrfs (rw,relatime,space_cache) > /dev/sdc1 on /run/media/fred/----xxx38fd1 type > btrfs (rw,nosuid,nodev,relatime,space_cache) > /dev/sdc1 on /run/media/fred/----xxx38fd11 type > btrfs (rw,nosuid,nodev,relatime,space_cache) > /dev/sdc1 on /run/media/fred/----xxx38fd12 type > btrfs (rw,nosuid,nodev,relatime,space_cache) > /dev/sdc1 on /run/media/fred/----xxx38fd13 type > btrfs (rw,nosuid,nodev,relatime,space_cache) > /dev/sdc1 on /run/media/fred/----xxx38fd14 type > btrfs (rw,nosuid,nodev,relatime,space_cache) > /dev/sdc1 on /run/media/fred/----xxx38fd15 type > btrfs (rw,nosuid,nodev,relatime,space_cache) > /dev/sdc1 on /run/media/fred/----xxx38fd16 type > btrfs (rw,nosuid,nodev,relatime,space_cache) > /dev/sdc1 on /run/media/fred/----xxx38fd17 type > btrfs (rw,nosuid,nodev,relatime,space_cache) > /dev/sdc1 on /run/media/fred/----xxx38fd18 type > btrfs (rw,nosuid,nodev,relatime,space_cache) > /dev/sdc1 on /run/media/fred/----xxx38fd19 type > btrfs (rw,nosuid,nodev,relatime,space_cache) > > It's as if the OS keeps "discovering a new disk" and mounting it > under /run/media (where things like external drives, thumb drives etc. > automount). > > Here is info about my setup (up to date CentOS 7.2): > > % cat /etc/system-release > CentOS Linux release 7.2.1511 (Core) > % uname -a > Linux xxx.xxx.xxx.edu 3.10.0-123.20.1.el7.x86_64 #1 SMP Thu Jan 29 > 18:05:33 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > % btrfs --version > btrfs-progs v3.19.1 > % btrfs fi show > Label: none uuid: d9706351-609b-4c6e-9f37-7058bb038fd1 > Total devices 2 FS bytes used 640.00KiB > devid1 size 4.55TiB used 2.03GiB path /dev/sdc1 > devid2 size 4.55TiB used 2.01GiB path /dev/sdd1 > > btrfs-progs v3.19.1 > % btrfs fi df /ext1 > Data, RAID1: total=1.00GiB, used=512.00KiB > Data, single: total=8.00MiB, used=0.00B > System, RAID1: total=8.00MiB, used=16.00KiB > System, single: total=4.00MiB, used=0.00B > Metadata, RAID1: total=1.00GiB, used=112.00KiB > Metadata, single: total=8.00MiB, used=0.00B > > Periodically I manually unmount these duplicates, but they come back. > I'd like a solution that doesn't involve disabling automount all > together. > > Thanks for any pointers, and apologies if this issue is unrelated to the > btrfs project. > > Leigh > > -- > Leigh Orf > Associate Scientist > Cooperative Institute for Meteorological Satellite Studies > University of Wisconsin - Madison > > -- > 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 -- 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: duplicate automounts with btrfs RAID1
and disk/ata/usb resets? On Wed, Mar 2, 2016 at 10:56 PM, Leigh Orf wrote: > On Wed, Mar 2, 2016 at 3:34 PM, Pavol Cupka wrote: >> is anything in dmesg that would point to diskscontrollers being reset? >> >> or something like that? >> >> pavol > > Pavol, > > Hmm, yes, there are some weird things going on. I am attaching what I > see as the relevant bits from /var/log/messages (command: egrep > '(sd[cd]|mount)' /var/log/messages) > > Note, /dev/sdc is disk 1 and /dev/sdd is disk 2 (the two btrfs RAID1 members). > > Leigh > >> >> On Wed, Mar 2, 2016 at 9:34 PM, Leigh Orf wrote: >>> Hello, >>> >>> Not entirely sure this is a btrfs issue, but here is my problem. I've >>> had this issue with recent Fedora and CentOS distros. >>> >>> I created a btrfs RAID 1 pair with two identical USB external drives, >>> following the instructions found online: >>> >>> mkfs.btrfs -m raid1 -d raid1 /dev/sdc1 /dev/sdd1 >>> >>> Then I mount it as /ext1: >>> >>> % df |grep sdc >>> /dev/sdc1 9767539112 1280 9765383552 1% /ext1 >>> >>> The problem? Over time, /dev/sdc1 keeps getting mounted under a >>> different mount point, these accrue a couple per day: >>> >>> % mount|grep sdc >>> /dev/sdc1 on /ext1 type btrfs (rw,relatime,space_cache) >>> /dev/sdc1 on /run/media/fred/----xxx38fd1 type >>> btrfs (rw,nosuid,nodev,relatime,space_cache) >>> /dev/sdc1 on /run/media/fred/----xxx38fd11 type >>> btrfs (rw,nosuid,nodev,relatime,space_cache) >>> /dev/sdc1 on /run/media/fred/----xxx38fd12 type >>> btrfs (rw,nosuid,nodev,relatime,space_cache) >>> /dev/sdc1 on /run/media/fred/----xxx38fd13 type >>> btrfs (rw,nosuid,nodev,relatime,space_cache) >>> /dev/sdc1 on /run/media/fred/----xxx38fd14 type >>> btrfs (rw,nosuid,nodev,relatime,space_cache) >>> /dev/sdc1 on /run/media/fred/----xxx38fd15 type >>> btrfs (rw,nosuid,nodev,relatime,space_cache) >>> /dev/sdc1 on /run/media/fred/----xxx38fd16 type >>> btrfs (rw,nosuid,nodev,relatime,space_cache) >>> /dev/sdc1 on /run/media/fred/----xxx38fd17 type >>> btrfs (rw,nosuid,nodev,relatime,space_cache) >>> /dev/sdc1 on /run/media/fred/----xxx38fd18 type >>> btrfs (rw,nosuid,nodev,relatime,space_cache) >>> /dev/sdc1 on /run/media/fred/----xxx38fd19 type >>> btrfs (rw,nosuid,nodev,relatime,space_cache) >>> >>> It's as if the OS keeps "discovering a new disk" and mounting it >>> under /run/media (where things like external drives, thumb drives etc. >>> automount). >>> >>> Here is info about my setup (up to date CentOS 7.2): >>> >>> % cat /etc/system-release >>> CentOS Linux release 7.2.1511 (Core) >>> % uname -a >>> Linux xxx.xxx.xxx.edu 3.10.0-123.20.1.el7.x86_64 #1 SMP Thu Jan 29 >>> 18:05:33 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >>> % btrfs --version >>> btrfs-progs v3.19.1 >>> % btrfs fi show >>> Label: none uuid: d9706351-609b-4c6e-9f37-7058bb038fd1 >>> Total devices 2 FS bytes used 640.00KiB >>> devid1 size 4.55TiB used 2.03GiB path /dev/sdc1 >>> devid2 size 4.55TiB used 2.01GiB path /dev/sdd1 >>> >>> btrfs-progs v3.19.1 >>> % btrfs fi df /ext1 >>> Data, RAID1: total=1.00GiB, used=512.00KiB >>> Data, single: total=8.00MiB, used=0.00B >>> System, RAID1: total=8.00MiB, used=16.00KiB >>> System, single: total=4.00MiB, used=0.00B >>> Metadata, RAID1: total=1.00GiB, used=112.00KiB >>> Metadata, single: total=8.00MiB, used=0.00B >>> >>> Periodically I manually unmount these duplicates, but they come back. >>> I'd like a solution that doesn't involve disabling automount all >>> together. >>> >>> Thanks for any pointers, and apologies if this issue is unrelated to the >>> btrfs project. >>> >>> Leigh >>> >>> -- >>> Leigh Orf >>> Associate Scientist >>> Cooperative Institute for Meteorological Satellite Studies >>> University of Wisconsin - Madison >>> >>> -- >>> 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 >> -- >> 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 -- 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 send error
Hi all, when trying to btrfs send a snaphost I get this in dmesg: [8614395.539466] BTRFS error (device sda1): did not find backref in send_root. inode=673755, offset=131072, disk_byte=25730310144 found extent=25730310144 scrub reveals no errors scrub status for bb8094e8-a7b1-4c2d-854e-77a9921e6f7e scrub started at Wed Feb 17 08:14:32 2016 and finished after 00:15:58 total bytes scrubbed: 67.49GiB with 0 errors Is there something else that I might try to get this work? uname -a Linux 4.1.7-hardened-r1 #4 SMP Mon Nov 9 20:02:04 CET 2015 x86_64 Intel(R) Atom(TM) CPU N2800 @ 1.86GHz GenuineIntel GNU/Linux btrfs --version btrfs-progs v4.3.1 Thanks Pavol -- 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 send error
Will do. Thank you. On Wed, Feb 17, 2016 at 3:01 PM, Filipe Manana wrote: > On Wed, Feb 17, 2016 at 1:02 PM, Pavol Cupka wrote: >> Hi all, >> >> when trying to btrfs send a snaphost I get this in dmesg: >> [8614395.539466] BTRFS error (device sda1): did not find backref in >> send_root. inode=673755, offset=131072, disk_byte=25730310144 found >> extent=25730310144 >> >> scrub reveals no errors >> scrub status for bb8094e8-a7b1-4c2d-854e-77a9921e6f7e >> scrub started at Wed Feb 17 08:14:32 2016 and finished after 00:15:58 >> total bytes scrubbed: 67.49GiB with 0 errors >> >> Is there something else that I might try to get this work? > > Just upgrade to a 4.3 or 4.4 kernel, or build a kernel with the patch below. > The fix for this landed in 4.3: > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d6589101b67a55107652050dfbf414403a93e351 > > >> >> uname -a >> Linux 4.1.7-hardened-r1 #4 SMP Mon Nov 9 20:02:04 CET 2015 x86_64 >> Intel(R) Atom(TM) CPU N2800 @ 1.86GHz GenuineIntel GNU/Linux >> >> btrfs --version >> btrfs-progs v4.3.1 >> >> Thanks Pavol >> -- >> 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 > > > > -- > Filipe David Manana, > > "Reasonable men adapt themselves to the world. > Unreasonable men adapt the world to themselves. > That's why all progress depends on unreasonable men." -- 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_orphan_cleanup
Hi all, after boot I am seeing this in dmesg [ 23.874698] BTRFS info (device sda1): enabling auto defrag [ 23.874702] BTRFS info (device sda1): disk space caching is enabled [ 26.074456] Adding 4193276k swap on /dev/sda4. Priority:-1 extents:1 across:4193276k [ 26.242940] [ cut here ] [ 26.242953] WARNING: CPU: 1 PID: 1863 at fs/btrfs/inode.c:3443 btrfs_orphan_cleanup+0x2d1/0x420() [ 26.242955] Modules linked in: vboxnetadp(O) vboxnetflt(O) vboxdrv(O) tun nvidia(PO) cdc_ether usbnet mii cdc_acm cdc_wdm iwldvm iwlwifi intel_agp intel_gtt efivarfs [ 26.242977] CPU: 1 PID: 1863 Comm: mount Tainted: PW O 4.1.7-hardened-r1 #3 [ 26.242979] Hardware name: Dell Inc. Latitude E6510/0N5KHN, BIOS A16 12/05/2013 [ 26.242982] 81c113c4 c90001633918 819d1e43 81e3a0f8 [ 26.242986] c90001633958 8107cf25 88021f57f800 [ 26.242989] 88021f57f800 880222c39e10 8802217d74e0 [ 26.242993] Call Trace: [ 26.243004] [] dump_stack+0x45/0x5d [ 26.243012] [] warn_slowpath_common+0x85/0xd0 [ 26.243016] [] warn_slowpath_null+0x15/0x20 [ 26.243019] [] btrfs_orphan_cleanup+0x2d1/0x420 [ 26.243023] [] btrfs_lookup_dentry+0x380/0x530 [ 26.243027] [] btrfs_lookup+0x11/0x50 [ 26.243033] [] lookup_real+0x2c/0x80 [ 26.243036] [] __lookup_hash+0x2e/0x40 [ 26.243041] [] path_lookupat+0x88e/0xd10 [ 26.243048] [] ? idr_get_empty_slot+0x1be/0x4e0 [ 26.243056] [] ? kmem_cache_alloc+0x2c/0x150 [ 26.243058] [] ? getname_kernel+0x2f/0x130 [ 26.243060] [] filename_lookup+0x1f/0x100 [ 26.243062] [] vfs_path_lookup+0x62/0xc0 [ 26.243065] [] ? proc_alloc_inum+0x2e/0xb0 [ 26.243069] [] ? __list_add+0x1b/0x40 [ 26.243073] [] mount_subtree+0x3b/0x90 [ 26.243075] [] ? kfree+0x38/0x180 [ 26.243079] [] btrfs_mount+0x273/0x970 [ 26.243081] [] mount_fs+0x3f/0x1a0 [ 26.243085] [] ? __alloc_percpu+0x10/0x20 [ 26.243087] [] vfs_kern_mount+0x63/0x120 [ 26.243089] [] do_mount+0x557/0xdc0 [ 26.243091] [] ? alloc_pages_current+0x95/0x120 [ 26.243094] [] ? __get_free_pages+0x9/0xb0 [ 26.243096] [] ? copy_mount_options+0x35/0x1c0 [ 26.243098] [] SyS_mount+0x8a/0xf0 [ 26.243101] [] system_call_fastpath+0x12/0x79 [ 26.243102] ---[ end trace 666fc5daa976e384 ]--- [ 26.243108] BTRFS error (device sda1): Error removing orphan entry, stopping orphan cleanup [ 26.243110] BTRFS error (device sda1): could not do orphan cleanup -22 Linux 4.1.7-hardened-r1 #3 SMP Thu Dec 24 14:19:04 CET 2015 x86_64 Intel(R) Core(TM) i7 CPU M 640 @ 2.80GHz GenuineIntel GNU/Linux btrfs-progs v4.3.1 Is there something I can do about it? Thank you in advance Pavol -- 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
filesystem corruption/unable to scrub
Hello, I am having trouble with my btrfs setup. An unwanted reset probably caused the corruption. I can mount the filesystem, but cannot perform scrub as this ends with GPF. uname -a Linux sysresccd 3.14.24-alt441-amd64 #2 SMP Sun Nov 16 08:27:16 UTC 2014 x86_64 AMD Phenom(tm) II X4 965 Processor AuthenticAMD GNU/Linux btrfs --version Btrfs v3.17.1 btrfs fi show Label: 'suc_storage' uuid: 76bf605a-936b-4fce-8a74-1eb2c750f51c Total devices 2 FS bytes used 2.57TiB devid1 size 3.64TiB used 3.63TiB path /dev/sda1 devid2 size 3.64TiB used 3.63TiB path /dev/sdb1 btrfs fi df /home # Replace /home with the mount point of your btrfs-filesystem Data, RAID1: total=3.63TiB, used=2.56TiB System, RAID1: total=32.00MiB, used=532.00KiB Metadata, RAID1: total=7.00GiB, used=5.83GiB dmesg > dmesg.log [14408.258515] general protection fault: [#1] SMP [14408.258520] Modules linked in: ppdev microcode parport_pc parport acpi_cpufreq serio_raw edac_core edac_mce_amd k10temp sp5100_tco i2c_piix4 shpchp raid10 raid456 async_raid6_recov async_pq async_xor async_memcpy async_tx raid1 raid0 multipath linear ata_generic pata_acpi usb_storage nouveau firewire_ohci firewire_core pata_atiixp ttm drm_kms_helper drm r8169 mii i2c_algo_bit i2c_core mxm_wmi video wmi [14408.258543] CPU: 3 PID: 3100 Comm: btrfs-scrub-2 Not tainted 3.14.24-alt441-amd64 #2 [14408.258546] Hardware name: Gigabyte Technology Co., Ltd. GA-MA785GT-UD3H/GA-MA785GT-UD3H, BIOS F8 05/25/2010 [14408.258549] task: 88007158a600 ti: 88011b9e4000 task.ti: 88011b9e4000 [14408.258551] RIP: 0010:[] [] scrub_bio_end_io_worker+0xb6/0x5fb [14408.258558] RSP: :88011b9e5d28 EFLAGS: 00010287 [14408.258560] RAX: 8800779ace00 RBX: fffe880118114e40 RCX: 8800b79dd800 [14408.258562] RDX: 8800b79dd8a8 RSI: 0001 RDI: 0014 [14408.258564] RBP: 88011b9e5df8 R08: ea0004604518 R09: 88011b9e5ce8 [14408.258566] R10: 81420d8a R11: 88010001 R12: 8800779ac100 [14408.258568] R13: R14: 8800779ac100 R15: [14408.258570] FS: () GS:88013fcc() knlGS:f75ccb40 [14408.258572] CS: 0010 DS: ES: CR0: 8005003b [14408.258574] CR2: f77c6000 CR3: 3ee94000 CR4: 07e0 [14408.258575] Stack: [14408.258577] 88011b9e5d88 88011b9e5da8 880139ab7200 8801 [14408.258581] 880118114f00 8800b79dd940 8800b7fa1800 000100d8f612 [14408.258583] 8800b79dd8a8 00158107d8ca 8800b79dd800 8800b7fa1800 [14408.258586] Call Trace: [14408.258592] [] ? schedule_timeout+0xa1/0xbd [14408.258596] [] ? lock_timer_base+0x4d/0x4d [14408.258600] [] worker_loop+0x194/0x527 [14408.258604] [] ? btrfs_queue_worker+0x239/0x239 [14408.258607] [] kthread+0xc9/0xd1 [14408.258611] [] ? kthread_freezable_should_stop+0x60/0x60 [14408.258614] [] ret_from_fork+0x7c/0xb0 [14408.258617] [] ? kthread_freezable_should_stop+0x60/0x60 [14408.258618] Code: 02 48 8b 09 80 a1 98 00 00 00 fb 48 8b 4d 80 48 83 c2 08 3b 81 38 01 00 00 7c dc eb 9c 48 8b 95 70 ff ff ff 48 8b 42 38 48 8b 18 ff 8b 84 00 00 00 0f 94 c0 84 c0 0f 84 2c 04 00 00 f6 83 98 [14408.258639] RIP [] scrub_bio_end_io_worker+0xb6/0x5fb [14408.258642] RSP [14408.258645] ---[ end trace 168b2c0c1e0d1fcc ]--- Running btrfsck with --repair ends also with errors. ... Device extent[2, 1522566955008, 1073741824] didn't find its device. Device extent[2, 1523640696832, 1073741824] didn't find its device. Device extent[2, 1524714438656, 1073741824] didn't find its device. Device extent[2, 1525788180480, 1073741824] didn't find its device. Device extent[2, 1526861922304, 1073741824] didn't find its device. Device extent[2, 1527935664128, 1073741824] didn't find its device. Errors found in extent allocation tree or chunk allocation checking free space cache cache and super generation don't match, space cache will be invalidated checking fs roots bad key ordering 1 2 Deleting bad dir index [618631,96,57124] root 270 volumes.c:978: btrfs_alloc_chunk: Assertion `ret` failed. btrfs check[0x8083f7d] btrfs check[0x8087624] btrfs check[0x807d132] btrfs check[0x807d4fc] btrfs check[0x807dfc4] btrfs check[0x80710d7] btrfs check[0x8071774] btrfs check[0x80737c0] btrfs check[0x808060a] btrfs check[0x805f56d] btrfs check[0x8061f82] btrfs check[0x8067797] btrfs check[0x804afd9] /lib/libc.so.6(__libc_start_main+0xe6)[0xf7619346] btrfs check[0x804ac31] Could you please help me as how could I correct current state. Thank you in advance Pavol -- 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
how does --init-csum-tree work?
Hi all, I just want to ask, how does init-csum-tree work on a raid1 two disk setup? Does it read the blocks from both of the drives and compare them? Or does it simply take the first disk and generate new crc's from all the blocks on the first disk completely ignoring the second disk? Thanks Pavol -- 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
unable to finish init-extent-tree
hi all, I am having trouble finishing a init-extent-tree rebuild on a raid1 btrfs that became corrupted, I was unable to finish a scrub on the system although the disks don't have any bad blocks. So I tried to repair the system, but that didn't help it either. btrfs check --repair /dev/sda1 enabling repair mode Checking filesystem on /dev/sda1 UUID: 76bf605a-936b-4fce-8a74-1eb2c750f51c checking extents Errors found in extent allocation tree or chunk allocation Error: could not find extent items for root 258 uname -r 3.19.0-gentoo x86_64 AMD Phenom(tm) II X4 965 Processor AuthenticAMD GNU/Linux Btrfs v3.18.2 if I try to --repair with --init-extent-tree I get this: # btrfs check --repair --init-extent-tree /dev/sda1 enabling repair mode Checking filesystem on /dev/sda1 UUID: 76bf605a-936b-4fce-8a74-1eb2c750f51c Creating a new extent tree Failed to find [4849148100608, 168, 4096] btrfs unable to find ref byte nr 4849148100608 parent 0 root 1 owner 2 offset 0 Failed to find [4849148141568, 168, 4096] btrfs unable to find ref byte nr 4849148141568 parent 0 root 1 owner 1 offset 1 Failed to find [4849148145664, 168, 4096] btrfs unable to find ref byte nr 4849148145664 parent 0 root 1 owner 0 offset 1 Failed to find [4849148104704, 168, 4096] btrfs unable to find ref byte nr 4849148104704 parent 0 root 1 owner 1 offset 1 Failed to find [4849148108800, 168, 4096] btrfs unable to find ref byte nr 4849148108800 parent 0 root 1 owner 0 offset 1 checking extents parent transid verify failed on 4849148104704 wanted 219108 found 219724 parent transid verify failed on 4849148104704 wanted 219108 found 219724 parent transid verify failed on 4849148104704 wanted 219108 found 219724 parent transid verify failed on 4849148104704 wanted 219108 found 219724 Ignoring transid failure bad block 4849148104704 parent transid verify failed on 4849148116992 wanted 219108 found 219723 parent transid verify failed on 4849148116992 wanted 219108 found 219723 parent transid verify failed on 4849148116992 wanted 219108 found 219723 parent transid verify failed on 4849148116992 wanted 219108 found 219723 Ignoring transid failure bad block 4849148116992 parent transid verify failed on 4849148121088 wanted 219108 found 219723 parent transid verify failed on 4849148121088 wanted 219108 found 219723 parent transid verify failed on 4849148121088 wanted 219108 found 219723 parent transid verify failed on 4849148121088 wanted 219108 found 219723 Ignoring transid failure leaf parent key incorrect 4849148121088 bad block 4849148121088 parent transid verify failed on 2078793535488 wanted 118799 found 219724 parent transid verify failed on 2078793535488 wanted 118799 found 219724 parent transid verify failed on 2078793535488 wanted 118799 found 219724 parent transid verify failed on 2078793535488 wanted 118799 found 219724 Ignoring transid failure bad block 2078793535488 parent transid verify failed on 2078793539584 wanted 118799 found 219724 parent transid verify failed on 2078793539584 wanted 118799 found 219724 parent transid verify failed on 2078793539584 wanted 118799 found 219724 parent transid verify failed on 2078793539584 wanted 118799 found 219724 Ignoring transid failure leaf parent key incorrect 2078793539584 bad block 2078793539584 parent transid verify failed on 2078793543680 wanted 118799 found 219724 parent transid verify failed on 2078793543680 wanted 118799 found 219724 parent transid verify failed on 2078793543680 wanted 118799 found 219724 parent transid verify failed on 2078793543680 wanted 118799 found 219724 Ignoring transid failure leaf parent key incorrect 2078793543680 bad block 2078793543680 parent transid verify failed on 2078793547776 wanted 118799 found 219722 parent transid verify failed on 2078793547776 wanted 118799 found 219722 parent transid verify failed on 2078793547776 wanted 118799 found 219722 parent transid verify failed on 2078793547776 wanted 118799 found 219722 Ignoring transid failure leaf parent key incorrect 2078793547776 bad block 2078793547776 parent transid verify failed on 2078793560064 wanted 118799 found 219723 parent transid verify failed on 2078793560064 wanted 118799 found 219723 parent transid verify failed on 2078793560064 wanted 118799 found 219723 parent transid verify failed on 2078793560064 wanted 118799 found 219723 Ignoring transid failure leaf parent key incorrect 2078793560064 bad block 2078793560064 parent transid verify failed on 2078793564160 wanted 118799 found 219723 parent transid verify failed on 2078793564160 wanted 118799 found 219723 parent transid verify failed on 2078793564160 wanted 118799 found 219723 parent transid verify failed on 2078793564160 wanted 118799 found 219723 Ignoring transid failure leaf parent key incorrect 2078793564160 bad block 2078793564160 parent transid verify failed on 4849148137472 wanted 219108 found 219716 parent transid verify failed on 4849148137472 wanted 219108 found 219716 parent tran
Error: btrfs check --repair --init-csum-tree --init-extent-tree
When running btrfs check on a RAID1 system using btrfs-progs v3.19-rc2 and running the 4.0.0-rc4 linux kernel. I get this: btrfs check --repair --init-csum-tree --init-extent-tree /dev/sda1 ... ... Incorrect local backref count on 2019737948160 parent 2541793873920 owner 0 offset 0 found 1 wanted 0 back 0x624dece0 backpointer mismatch on [2019737948160 4096] ref mismatch on [2019737952256 4096] extent item 0, found 5 adding new data backref on 2019737952256 root 271 owner 615 offset 0 found 1 adding new data backref on 2019737952256 parent 2935248711680 owner 0 offset 0 found 1 adding new data backref on 2019737952256 parent 3289312481280 owner 0 offset 0 found 1 ctree.c:1595: leaf_space_used: Assertion `data_len < 0` failed. btrfs[0x43324d] btrfs[0x43380c] btrfs(btrfs_leaf_free_space+0x24)[0x434f64] btrfs(btrfs_check_leaf+0xa5)[0x435065] btrfs[0x435432] btrfs(btrfs_search_slot+0x305)[0x437025] btrfs(btrfs_insert_empty_items+0x8a)[0x4384aa] btrfs[0x43ebe9] btrfs[0x43edb7] btrfs(btrfs_inc_extent_ref+0xf1)[0x440151] btrfs[0x40b512] btrfs[0x412fe5] btrfs(cmd_check+0x77d)[0x426afd] btrfs(main+0x82)[0x413742] /lib64/libc.so.6(__libc_start_main+0xf5)[0x7f9078031a65] btrfs[0x413843] is someone from the devs interested on debuging this? Let me know Pavol -- 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
