[PATCH v2] btrfs-progs: there is devid 0 when replace is running
During disk replacement a new disk is temporarily
added to the fs devlist with devid 0 and fs num_device is
incremented by 1. However when progs reads the devlist it
fail to obtain details of devid 0 because it doesn't query
devid 0 at all.
reproducer:
btrfs rep start /dev/sdb /dev/sdf /btrfs
btrfs fi show
Label: none uuid: f8fb9819-16c8-47b7-b62f-0ff90f8c56cd
Total devices 3 FS bytes used 1.94GiB
devid1 size 1.10GiB used 1.10GiB path /dev/sdb
devid2 size 1.10GiB used 1.08GiB path /dev/sdc
devid0 size 0.00 used 0.00 path
this patch will make it proper by querying devid 0.
btrfs repl start /dev/sdb /dev/sdf /btrfs
btrfs fi show /btrfs
Label: none uuid: f8fb9819-16c8-47b7-b62f-0ff90f8c56cd
Total devices 3 FS bytes used 1.94GiB
devid0 size 1.10GiB used 1.10GiB path /dev/sdf
devid1 size 1.10GiB used 1.10GiB path /dev/sdb
devid2 size 1.10GiB used 1.08GiB path /dev/sdc
Its fine to query devid 0 when there is no replace
activity as well, because we just skip the error ENODEV
btrfs fi show /btrfs
Label: none uuid: f8fb9819-16c8-47b7-b62f-0ff90f8c56cd
Total devices 2 FS bytes used 1.94GiB
devid1 size 1.10GiB used 1.10GiB path /dev/sdf
devid2 size 1.10GiB used 1.08GiB path /dev/sdc
---
v2: fix commit message
utils.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/utils.c b/utils.c
index de513b6..a045ffd 100644
--- a/utils.c
+++ b/utils.c
@@ -1696,7 +1696,7 @@ int get_fs_info(char *path, struct
btrfs_ioctl_fs_info_args *fi_args,
goto out;
}
- for (; i = fi_args-max_id; ++i) {
+ for (i = 0; i = fi_args-max_id; ++i) {
BUG_ON(ndevs = fi_args-num_devices);
ret = get_device_info(fd, i, di_args[ndevs]);
if (ret == -ENODEV)
--
1.7.1
--
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 raid5 unmountable
Hello Duncan, Of course if you'd been following the list as btrfs testers really should still be doing at this point, you'd have seen all this covered before. And of course, if you had done pre-deployment testing before you stuck valuable data on that btrfs raid5, you'd have noted the problems, even without reading about it on-list or on the wiki. But of course hindsight is 20/20, as they say, and at least you DO have backups, even if they'll take awhile to restore. =:^) That's already vastly better than a lot of the reports we unfortunately get here. =:^\ yeah, i saw it. Main reason for me toying with btrfs is my work. We rent Linux servers to customers. While they install and manage them by them self, there will be questions about btrfs to our support, sooner or later. So getting your hands on it early saves some headache later. It is just inconvient for me now, so no big deal. I first tried degraded, I also tried repair, no luck. What I do now is, getting as much data from the broken fs with btrfs recover and do a rsync after. It is just faster then downloading all the data from my own mirror in the datacenter. ;) After that I will even be so crazy and try it again. Next on my list is send/receive. Tetja -- 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
[cmds-scrub.c:539]: (style) Array index 'i' is used before limits check.
Hello there,
Static analyser cppcheck says many things
about btrfs-progs, including the subject line.
Source code is
while (isspace(l[i]) i avail) {
Suggest code rework. I checked the latest source
code and the bug exists there too.
Regards
David Binderman --
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: [PATCH] Btrfs: disable snapshot aware defrag for now
On 02/03/2014 10:19 PM, Roger Binns wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/02/14 09:27, Josef Bacik wrote: It is so totally broken that I don't want it being turned on by anybody who can't edit this and change it themselves. The symptoms I saw are huge amounts of kernel memory consumption, possibly till exhaustion of swap. Are there other ways in which is it broken (eg corruption)? Also is this patch making its way to the various stables? No corruption, and frankly if you had just small files and a small number of snapshots it worked just fine, but otherwise it would use all of your ram. I cc'ed stable@ so it should make it back to all the stables. Thanks, Josef -- 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: [PATCH] Btrfs: throttle delayed refs better
On 02/03/2014 05:53 PM, Johannes Hirte wrote: On Mon, 3 Feb 2014 16:08:08 -0500 Josef Bacik jba...@fb.com wrote: On 02/03/2014 01:28 PM, Johannes Hirte wrote: On Thu, 23 Jan 2014 13:07:52 -0500 Josef Bacik jba...@fb.com wrote: On one of our gluster clusters we noticed some pretty big lag spikes. This turned out to be because our transaction commit was taking like 3 minutes to complete. This is because we have like 30 gigs of metadata, so our global reserve would end up being the max which is like 512 mb. So our throttling code would allow a ridiculous amount of delayed refs to build up and then they'd all get run at transaction commit time, and for a cold mounted file system that could take up to 3 minutes to run. So fix the throttling to be based on both the size of the global reserve and how long it takes us to run delayed refs. This patch tracks the time it takes to run delayed refs and then only allows 1 seconds worth of outstanding delayed refs at a time. This way it will auto-tune itself from cold cache up to when everything is in memory and it no longer has to go to disk. This makes our transaction commits take much less time to run. Thanks, Signed-off-by: Josef Bacik jba...@fb.com This one breaks my system. Shortly after boot the btrfs-freespace thread goes up to 100% CPU usage and the system is nearly unresponsive. I've seen it first with the full pull request for 3.14-rc1 and was able to track it down to this patch. Could you turn on the softlockup timer and see if you can get a backtrace of where it is stuck? In the meantime I will go through and see if I can pinpoint where it may be happening. Thanks, Josef This is what I've got with Hrm I was hoping that was going to be more helpful. Can you get perf record -ag and then perf report while it's at full cpu and get the first 3 or 4 things with their traces? I'm going to try and reproduce today, is there anything special about your fs? Compression, large blocksizes, skinny metadata? Thanks, Josef -- 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: Booting with syslinux not possible
I also had some problems with syslinux. For me it only works if I put boot folder to root of btrfs. Didn't have a chance to do more test, but I copied /boot from default subvolume to subvolume 0 and it boots OK. -- regards Blaz Balon On 01/31/2014 11:00 PM, Alex wrote: Sorry KC: All my VM's are on syslinux (actually extlinux) and btrfs: Device Boot Start End Blocks Id System /dev/vda1 *2048 7938047 3968000 83 Linux /dev/vda2 7938048 8388607 225280 82 Linux swap / Solaris root@VM ~ # ll /boot total 19452 -rw-r--r-- 1 root root 2319932 Jan 21 06:12 System.map-3.12-1-amd64 -rw-r--r-- 1 root root 149029 Jan 21 06:12 config-3.12-1-amd64 drwxr-xr-x 1 root root 176 Jan 28 22:32 extlinux/ -rw-r--r-- 1 root root 14240605 Jan 28 22:32 initrd.img-3.12-1-amd64 -rw-r--r-- 1 root root 176764 Nov 13 2011 memtest86+.bin -rw-r--r-- 1 root root 178944 Nov 13 2011 memtest86+_multiboot.bin -rw-r--r-- 1 root root 2842064 Jan 21 06:08 vmlinuz-3.12-1-amd64 root@china ~ # Occasionally I get excited and decide to fix it 'til it breaks (usually I turn compression on, and /boot can't be accessed), but it's been working fine for a few years now. Kind regards. Al. -- 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 crash with a corrupted(?) filesystem
Hello, My server had a period of instability (PSU-related issues), some lockups, some strange crashes, and some files became corrupted, and perhaps parts of a filesystem too. One BTRFS partition now fails with the following errors. On an attempt to make a snapshot: [ 48.035664] btrfs: corrupt leaf, bad key order: block=193529446400,root=1, slot=9 [ 48.035795] [ cut here ] [ 48.035840] kernel BUG at fs/btrfs/inode.c:873! [ 48.035884] invalid opcode: [#1] SMP [ 48.036000] Modules linked in: cpufreq_stats cpufreq_userspace cpufreq_powersave cpufreq_conservative nfsd auth_rpcgss oid_registry nfs_acl nfs lockd dns_resolver fscache sunrpc 8021q garp mrp bridge stp llc fuse ext3 jbd it87 hwmon_vid ecryptfs snd_hda_codec_hdmi acpi_cpufreq snd_hda_codec_realtek mperf snd_hda_intel snd_hda_codec kvm_amd snd_pcsp snd_hwdep kvm fglrx(PO) snd_pcm_oss sp5100_tco snd_mixer_oss crc32c_intel ghash_clmulni_intel snd_pcm eeepc_wmi aesni_intel asus_wmi sparse_keymap uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core psmouse rfkill snd_page_alloc video videodev edac_mce_amd snd_timer edac_core aes_x86_64 serio_raw evdev fam15h_power media snd ablk_helper joydev i2c_piix4 cp210x cryptd processor usbserial k10temp lrw i2c_core mxm_wmi thermal_sys gf128mul wmi glue_helper soundcore ehci_pci button ext4 crc16 jbd2 mbcache btrfs zlib_deflate crc32c libcrc32c dm_mod raid1 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq md_mod nbd sata_nv sg sd_mod crc_t10dif hid_generic usbhid hid sata_promise ohci_hcd ehci_hcd microcode xhci_hcd ahci ata_generic libahci libata usbcore r8169 mii usb_common scsi_mod [ 48.040775] CPU: 4 PID: 4145 Comm: btrfs Tainted: P O 3.10.28-rm1+ #54 [ 48.040825] Hardware name: To be filled by O.E.M. To be filled by O.E.M./M5A97 LE R2.0, BIOS 1903 07/11/2013 [ 48.040876] task: 88040b4dc300 ti: 880409c14000 task.ti: 880409c14000 [ 48.040926] RIP: 0010:[a023f225] [a023f225] __cow_file_range+0x445/0x4e0 [btrfs] [ 48.041042] RSP: 0018:880409c15328 EFLAGS: 00010203 [ 48.041086] RAX: 1000 RBX: RCX: 0102 [ 48.041131] RDX: 0103 RSI: 88042e16a2e0 RDI: 88042e146e50 [ 48.041177] RBP: 880409c153e8 R08: R09: 0003 [ 48.041222] R10: 0004 R11: 0001 R12: 8804352eb0a0 [ 48.041267] R13: R14: 88042e16a2e0 R15: [ 48.041318] FS: 7f064ac9e780() GS:88044ed0() knlGS: [ 48.041367] CS: 0010 DS: ES: CR0: 8005003b [ 48.041411] CR2: 0046a9f0 CR3: 0004388dc000 CR4: 000407e0 [ 48.041456] DR0: DR1: DR2: [ 48.041532] DR3: DR6: 0ff0 DR7: 0400 [ 48.041576] Stack: [ 48.041617] 880409c15388 880430a2e800 8804352eb130 880409c15350 [ 48.041813] 0003 88042e16a100 880409c15350 ea000eb312c8 [ 48.042006] 88042e146e50 ffff16a0 8804347c0800 [ 48.042200] Call Trace: [ 48.042274] [a0255a89] ? free_extent_buffer+0x59/0xa0 [btrfs] [ 48.042348] [a023f668] run_delalloc_nocow+0x3a8/0xaf0 [btrfs] [ 48.042421] [a02401c0] run_delalloc_range+0x330/0x390 [btrfs] [ 48.042495] [a0254641] __extent_writepage+0x2f1/0x750 [btrfs] [ 48.042570] [a0254d52] extent_write_cache_pages.isra.31.constprop.47+0x2b2/0x3c0 [btrfs] [ 48.042650] [a02550d7] extent_writepages+0x47/0x60 [btrfs] [ 48.042752] [a023bee0] ? can_nocow_odirect+0x330/0x330 [btrfs] [ 48.042823] [a0239873] btrfs_writepages+0x23/0x30 [btrfs] [ 48.042873] [8110ea19] do_writepages+0x19/0x40 [ 48.042921] [81104711] __filemap_fdatawrite_range+0x51/0x60 [ 48.042969] [811054ce] filemap_fdatawrite_range+0xe/0x10 [ 48.043042] [a024f9e8] btrfs_wait_ordered_range+0x48/0x110 [btrfs] [ 48.043116] [a027499a] __btrfs_write_out_cache+0x76a/0x990 [btrfs] [ 48.043187] [a0232405] ? btrfs_buffer_uptodate+0x65/0x80 [btrfs] [ 48.043261] [a0274ec2] btrfs_write_out_cache+0xb2/0xf0 [btrfs] [ 48.045346] [a0255a89] ? free_extent_buffer+0x59/0xa0 [btrfs] [ 48.045414] [a0227383] btrfs_write_dirty_block_groups+0x573/0x660 [btrfs] [ 48.045489] [a02353a4] commit_cowonly_roots+0x164/0x260 [btrfs] [ 48.045560] [a023724c] btrfs_commit_transaction+0x59c/0xab0 [btrfs] [ 48.045614] [81075030] ? finish_wait+0x80/0x80 [ 48.045686] [a026692a] btrfs_mksubvol.isra.49+0x3aa/0x450 [btrfs] [ 48.045759] [a0266aba] btrfs_ioctl_snap_create_transid+0xea/0x170 [btrfs] [ 48.045838] [a0266bfa] ? btrfs_ioctl_snap_create_v2+0x3a/0x140
Re: btrfs crash with a corrupted(?) filesystem
On Tue, Feb 04, 2014 at 10:23:10PM +0600, Roman Mamedov wrote: Hello, My server had a period of instability (PSU-related issues), some lockups, some strange crashes, and some files became corrupted, and perhaps parts of a filesystem too. One BTRFS partition now fails with the following errors. On an attempt to make a snapshot: [ 48.035664] btrfs: corrupt leaf, bad key order: block=193529446400,root=1, slot=9 [snip] Bad key order is pretty much always down to hardware corrupting data at some point -- which would go well with your list of hardware problems above. Currently I have it mounted read-only, and all data seems to be accessible. Short of copying everything away and recreating the FS, how can I bring it to a working order. Is btrfsck a good option here? The first investigation to do would be to look at the block in question and see if it's got an obvious problem with it. If you post the output of btrfs-debug-tree -b 193529446400 /dev/whatever, we can take a look at the indexing. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- You're never alone with a rubber duck... --- signature.asc Description: Digital signature
Re: btrfs crash with a corrupted(?) filesystem
On Tue, 4 Feb 2014 16:32:35 + Hugo Mills h...@carfax.org.uk wrote: On Tue, Feb 04, 2014 at 10:23:10PM +0600, Roman Mamedov wrote: Hello, My server had a period of instability (PSU-related issues), some lockups, some strange crashes, and some files became corrupted, and perhaps parts of a filesystem too. One BTRFS partition now fails with the following errors. On an attempt to make a snapshot: [ 48.035664] btrfs: corrupt leaf, bad key order: block=193529446400,root=1, slot=9 [snip] Bad key order is pretty much always down to hardware corrupting data at some point -- which would go well with your list of hardware problems above. Currently I have it mounted read-only, and all data seems to be accessible. Short of copying everything away and recreating the FS, how can I bring it to a working order. Is btrfsck a good option here? The first investigation to do would be to look at the block in question and see if it's got an obvious problem with it. If you post the output of btrfs-debug-tree -b 193529446400 /dev/whatever, we can take a look at the indexing. Thanks; here it is: # btrfs-debug-tree -b 193529446400 /dev/md4 leaf 193529446400 items 81 free space 46 generation 565572 owner 7 fs uuid dd12de99-bbe5-45cf-b869-6313c1f58431 chunk uuid b61f845a-ada5-4bcf-b995-7c5e1affa63d item 0 key (EXTENT_CSUM EXTENT_CSUM 4278808576) itemoff 3955 itemsize 40 extent csum item item 1 key (EXTENT_CSUM EXTENT_CSUM 4278853632) itemoff 3895 itemsize 60 extent csum item item 2 key (EXTENT_CSUM EXTENT_CSUM 4278919168) itemoff 3883 itemsize 12 extent csum item item 3 key (EXTENT_CSUM EXTENT_CSUM 4278931456) itemoff 3843 itemsize 40 extent csum item item 4 key (EXTENT_CSUM EXTENT_CSUM 4278976512) itemoff 3819 itemsize 24 extent csum item item 5 key (EXTENT_CSUM EXTENT_CSUM 4279001088) itemoff 3815 itemsize 4 extent csum item item 6 key (EXTENT_CSUM EXTENT_CSUM 4279005184) itemoff 3787 itemsize 28 extent csum item item 7 key (EXTENT_CSUM EXTENT_CSUM 4279033856) itemoff 3715 itemsize 72 extent csum item item 8 key (EXTENT_CSUM EXTENT_CSUM 4279107584) itemoff 3619 itemsize 96 extent csum item item 9 key (EXTENT_CSUM EXTENT_CSUM 72998785024) itemoff 3599 itemsize 20 extent csum item item 10 key (EXTENT_CSUM EXTENT_CSUM 4279345152) itemoff 3583 itemsize 16 extent csum item item 11 key (EXTENT_CSUM EXTENT_CSUM 4279369728) itemoff 3575 itemsize 8 extent csum item item 12 key (EXTENT_CSUM EXTENT_CSUM 4279463936) itemoff 3551 itemsize 24 extent csum item item 13 key (EXTENT_CSUM EXTENT_CSUM 4279496704) itemoff 3523 itemsize 28 extent csum item item 14 key (EXTENT_CSUM EXTENT_CSUM 4279525376) itemoff 3515 itemsize 8 extent csum item item 15 key (EXTENT_CSUM EXTENT_CSUM 4279533568) itemoff 3511 itemsize 4 extent csum item item 16 key (EXTENT_CSUM EXTENT_CSUM 4279537664) itemoff 3491 itemsize 20 extent csum item item 17 key (EXTENT_CSUM EXTENT_CSUM 4279562240) itemoff 3463 itemsize 28 extent csum item item 18 key (EXTENT_CSUM EXTENT_CSUM 4279607296) itemoff 3459 itemsize 4 extent csum item item 19 key (EXTENT_CSUM EXTENT_CSUM 4279615488) itemoff 3403 itemsize 56 extent csum item item 20 key (EXTENT_CSUM EXTENT_CSUM 4280020992) itemoff 3395 itemsize 8 extent csum item item 21 key (EXTENT_CSUM EXTENT_CSUM 4280033280) itemoff 3391 itemsize 4 extent csum item item 22 key (EXTENT_CSUM EXTENT_CSUM 4280053760) itemoff 3379 itemsize 12 extent csum item item 23 key (EXTENT_CSUM EXTENT_CSUM 4280082432) itemoff 3331 itemsize 48 extent csum item item 24 key (EXTENT_CSUM EXTENT_CSUM 4280135680) itemoff 3311 itemsize 20 extent csum item item 25 key (EXTENT_CSUM EXTENT_CSUM 4280156160) itemoff 3299 itemsize 12 extent csum item item 26 key (EXTENT_CSUM EXTENT_CSUM 4280168448) itemoff 3255 itemsize 44 extent csum item item 27 key (EXTENT_CSUM EXTENT_CSUM 4280229888) itemoff 3243 itemsize 12 extent csum item item 28 key (EXTENT_CSUM EXTENT_CSUM 4280262656) itemoff 3231 itemsize 12 extent csum item item 29 key (EXTENT_CSUM EXTENT_CSUM 4280360960) itemoff 3223 itemsize 8 extent csum item item 30 key (EXTENT_CSUM EXTENT_CSUM 4280369152) itemoff 3123 itemsize 100 extent csum item item 31 key (EXTENT_CSUM EXTENT_CSUM 4280496128) itemoff 3115 itemsize
Re: btrfs crash with a corrupted(?) filesystem
On Tue, Feb 04, 2014 at 10:35:06PM +0600, Roman Mamedov wrote: On Tue, 4 Feb 2014 16:32:35 + Hugo Mills h...@carfax.org.uk wrote: On Tue, Feb 04, 2014 at 10:23:10PM +0600, Roman Mamedov wrote: Hello, My server had a period of instability (PSU-related issues), some lockups, some strange crashes, and some files became corrupted, and perhaps parts of a filesystem too. One BTRFS partition now fails with the following errors. On an attempt to make a snapshot: [ 48.035664] btrfs: corrupt leaf, bad key order: block=193529446400,root=1, slot=9 [snip] Bad key order is pretty much always down to hardware corrupting data at some point -- which would go well with your list of hardware problems above. Currently I have it mounted read-only, and all data seems to be accessible. Short of copying everything away and recreating the FS, how can I bring it to a working order. Is btrfsck a good option here? The first investigation to do would be to look at the block in question and see if it's got an obvious problem with it. If you post the output of btrfs-debug-tree -b 193529446400 /dev/whatever, we can take a look at the indexing. Thanks; here it is: # btrfs-debug-tree -b 193529446400 /dev/md4 leaf 193529446400 items 81 free space 46 generation 565572 owner 7 fs uuid dd12de99-bbe5-45cf-b869-6313c1f58431 chunk uuid b61f845a-ada5-4bcf-b995-7c5e1affa63d item 0 key (EXTENT_CSUM EXTENT_CSUM 4278808576) itemoff 3955 itemsize 40 extent csum item item 1 key (EXTENT_CSUM EXTENT_CSUM 4278853632) itemoff 3895 itemsize 60 extent csum item item 2 key (EXTENT_CSUM EXTENT_CSUM 4278919168) itemoff 3883 itemsize 12 extent csum item item 3 key (EXTENT_CSUM EXTENT_CSUM 4278931456) itemoff 3843 itemsize 40 extent csum item item 4 key (EXTENT_CSUM EXTENT_CSUM 4278976512) itemoff 3819 itemsize 24 extent csum item item 5 key (EXTENT_CSUM EXTENT_CSUM 4279001088) itemoff 3815 itemsize 4 extent csum item item 6 key (EXTENT_CSUM EXTENT_CSUM 4279005184) itemoff 3787 itemsize 28 extent csum item item 7 key (EXTENT_CSUM EXTENT_CSUM 4279033856) itemoff 3715 itemsize 72 extent csum item item 8 key (EXTENT_CSUM EXTENT_CSUM 4279107584) itemoff 3619 itemsize 96 extent csum item item 9 key (EXTENT_CSUM EXTENT_CSUM 72998785024) itemoff 3599 itemsize 20 extent csum item ^^^ Here it is. The previous key (item 8): hex(4279107584) '0xff0eL' This key (item 9): hex(72998785024) '0x10ff111000L' So it looks likely that you've got a single bit flip in the key. Josef had a patch for fsck some time before Christmas that would deal with (some of) these cases, but I'm not sure if this is one of them. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- You're never alone with a rubber duck... --- signature.asc Description: Digital signature
Re: Booting with syslinux not possible
Blaz Balon blaz.balon at laly.si writes: I also had some problems with syslinux. For me it only works if I put boot folder to root of btrfs. Didn't have a chance to do more test, but I copied /boot from default subvolume to subvolume 0 and it boots OK. Not sure I understand your /boot comment. I have some /boots on the main btrfs partition and some mounted ext(x)s (can't remember, don't care). I have quite an (overly) complicated setup. All major directories are subvols eg. /etc /usr etc so that I can snapshot at almost every level. if you create the subvol you want as a tree, debootstrap (Debian) and git clone the stages (funtoo) are quite happy, but I guess you know that. Transforming from standard directory to subvol is easy with any live distro (sysrescuecd). -- 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
[PATCH] Btrfs: introduce commit_root_sem to protect commit roots
Btrfs send uses the commit roots to avoid locking and such when sending
snapshots. The problem with this it doesn't lock anything to make sure the
commit roots don't get swapped out from underneath it. This can cause issues if
you are trying to send a snapshot and then snapshot that snapshot which will
cause us to cow the root and screw everything up. So add commit_root_sem and
hold it when we're swapping everything out during the commit. This will make
sure we don't have to hold a transaction open while doing a send and we can
still use our commit roots. This fixes Wang's reproducer that he turned into an
xfstest. Thanks,
Reported-by: Wang Shilong wangsl.f...@cn.fujitsu.com
Signed-off-by: Josef Bacik jba...@fb.com
---
fs/btrfs/backref.c | 14 ++
fs/btrfs/ctree.h | 2 +-
fs/btrfs/disk-io.c | 1 +
fs/btrfs/send.c| 8 ++--
fs/btrfs/transaction.c | 5 +
5 files changed, 23 insertions(+), 7 deletions(-)
diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
index aded3ef..e70f181 100644
--- a/fs/btrfs/backref.c
+++ b/fs/btrfs/backref.c
@@ -1588,18 +1588,24 @@ int iterate_inodes_from_logical(u64 logical, struct
btrfs_fs_info *fs_info,
struct btrfs_key found_key;
int search_commit_root = path-search_commit_root;
+ if (search_commit_root)
+ down_read(fs_info-commit_root_sem);
ret = extent_from_logical(fs_info, logical, path, found_key, flags);
btrfs_release_path(path);
if (ret 0)
- return ret;
- if (flags BTRFS_EXTENT_FLAG_TREE_BLOCK)
- return -EINVAL;
+ goto out;
+ if (flags BTRFS_EXTENT_FLAG_TREE_BLOCK) {
+ ret = -EINVAL;
+ goto out;
+ }
extent_item_pos = logical - found_key.objectid;
ret = iterate_extent_inodes(fs_info, found_key.objectid,
extent_item_pos, search_commit_root,
iterate, ctx);
-
+out:
+ if (search_commit_root)
+ up_read(fs_info-commit_root_sem);
return ret;
}
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 84d4c05..5d927e6 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -1440,7 +1440,7 @@ struct btrfs_fs_info {
struct mutex ordered_extent_flush_mutex;
struct rw_semaphore extent_commit_sem;
-
+ struct rw_semaphore commit_root_sem;
struct rw_semaphore cleanup_work_sem;
struct rw_semaphore subvol_sem;
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 7619147..ceb2c2d 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -2279,6 +2279,7 @@ int open_ctree(struct super_block *sb,
mutex_init(fs_info-volume_mutex);
init_rwsem(fs_info-extent_commit_sem);
init_rwsem(fs_info-cleanup_work_sem);
+ init_rwsem(fs_info-commit_root_sem);
init_rwsem(fs_info-subvol_sem);
sema_init(fs_info-uuid_tree_rescan_sem, 1);
fs_info-dev_replace.lock_owner = 0;
diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c
index 04c07ed..1995e6b 100644
--- a/fs/btrfs/send.c
+++ b/fs/btrfs/send.c
@@ -1249,13 +1249,17 @@ static int find_extent_clone(struct send_ctx *sctx,
}
logical = disk_byte + btrfs_file_extent_offset(eb, fi);
+ down_read(sctx-send_root-fs_info-commit_root_sem);
ret = extent_from_logical(sctx-send_root-fs_info, disk_byte, tmp_path,
found_key, flags);
btrfs_release_path(tmp_path);
- if (ret 0)
+ if (ret 0) {
+ up_read(sctx-send_root-fs_info-commit_root_sem);
goto out;
+ }
if (flags BTRFS_EXTENT_FLAG_TREE_BLOCK) {
+ up_read(sctx-send_root-fs_info-commit_root_sem);
ret = -EIO;
goto out;
}
@@ -1297,7 +1301,7 @@ static int find_extent_clone(struct send_ctx *sctx,
ret = iterate_extent_inodes(sctx-send_root-fs_info,
found_key.objectid, extent_item_pos, 1,
__iterate_backrefs, backref_ctx);
-
+ up_read(sctx-send_root-fs_info-commit_root_sem);
if (ret 0)
goto out;
diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c
index 34cd831..d888f26 100644
--- a/fs/btrfs/transaction.c
+++ b/fs/btrfs/transaction.c
@@ -1819,8 +1819,10 @@ int btrfs_commit_transaction(struct btrfs_trans_handle
*trans,
*/
mutex_lock(root-fs_info-tree_log_mutex);
+ down_write(root-fs_info-commit_root_sem);
ret = commit_fs_roots(trans, root);
if (ret) {
+ up_write(root-fs_info-commit_root_sem);
mutex_unlock(root-fs_info-tree_log_mutex);
mutex_unlock(root-fs_info-reloc_mutex);
goto cleanup_transaction;
@@ -1842,6 +1844,7 @@ int btrfs_commit_transaction(struct btrfs_trans_handle
*trans,
ret =
[GIT PULL] Btrfs
Hi Linus, Please pull my for-linus: git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus Filipe is fixing compile and boot problems with our crc32c rework, and Josef has disabled snapshot aware defrag for now. As the number of snapshots increases, we're hitting OOM. For the short term we're disabling things until a bigger fix is ready. Filipe David Borba Manana (2) commits (+7/-7): Btrfs: use btrfs_crc32c everywhere instead of libcrc32c (+6/-6) Btrfs: use late_initcall instead of module_init (+1/-1) Josef Bacik (1) commits (+1/-1): Btrfs: disable snapshot aware defrag for now Total: (3) commits (+8/-8) fs/btrfs/check-integrity.c | 4 ++-- fs/btrfs/disk-io.c | 4 ++-- fs/btrfs/inode.c | 2 +- fs/btrfs/send.c| 4 ++-- fs/btrfs/super.c | 2 +- 5 files changed, 8 insertions(+), 8 deletions(-) -- 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: hitting BUG_ON on troublesome FS
to reply to my own thread: i managed to empty the filesystem, but it still segfaults in the same way when i try to balance the last few blocks. a `btrfs bal start -dusage=0 /mountpoint` finishes, but leaves a few blocks allocated. when i skip the usage=0, it segfaults. What can i do to provide useful information? Remco On 03 Feb 2014, at 21:51, Remco Hosman - Yerf-it.com re...@yerf-it.com wrote: FIrst, a bit of history of the filesystem: used to be 6 disks, now 5. partially raid1 / raid10. been migrating back and forth a few times. As some point, a balance would not complete and would end with 164 ENOSPC’ses, while there was plenty of unallocated space on each disk. i scanned for extends larger then 1gig and found a few, so ran a recursive balance of the entire FS. I deceided to empty the filesystem and format it. i pulled most files off it some via btrfs send/receive, some via rsync. but 1 subvol wouldn’t send. i don’t remember the exact error, but it was that a extend could not be found on 1 of the disks. with only a few 100gig of data left, i decided to balance some remaining empty space before doing a `btrfs dev del`, so have another disk to store more data on. but im hitting a snag, i hit a BUG_ON when doing a `btrfs bal start -dusage=2 /mountpoint` : [ 3327.678329] btrfs: found 198 extents [ 3328.117274] btrfs: relocating block group 84473084968960 flags 17 [ 3329.278521] btrfs: found 103 extents [ 3331.907931] btrfs: found 103 extents [ 3332.386172] btrfs: relocating block group 84466642518016 flags 17 [ .536595] btrfs: found 86 extents [ 3335.982967] btrfs: found 86 extents [ 3336.599555] btrfs (4746) used greatest stack depth: 2744 bytes left [ 3379.073464] btrfs: relocating block group 89878368419840 flags 17 [ 3381.608948] btrfs: found 499 extents [ 3383.884696] [ cut here ] [ 3383.884720] kernel BUG at fs/btrfs/relocation.c:3405! [ 3383.884731] invalid opcode: [#1] SMP [ 3383.884742] Modules linked in: [ 3383.884753] CPU: 0 PID: 5663 Comm: btrfs Not tainted 3.13.0 #1 [ 3383.884763] Hardware name: System manufacturer System Product Name/E45M1-I DELUXE, BIOS 0405 08/08/2012 [ 3383.884778] task: 8802360eae80 ti: 88010dcaa000 task.ti: 88010dcaa000 [ 3383.884790] RIP: 0010:[812f0bd5] [812f0bd5] __add_tree_block+0x1c5/0x1e0 [ 3383.884811] RSP: 0018:88010dcaba38 EFLAGS: 00010202 [ 3383.884821] RAX: 0001 RBX: 880039f18000 RCX: [ 3383.884832] RDX: RSI: RDI: [ 3383.884843] RBP: 88010dcaba90 R08: 88010dcab9f4 R09: 88010dcab930 [ 3383.884854] R10: R11: 047f R12: 1000 [ 3383.884865] R13: 88023489c630 R14: R15: 528d112e4000 [ 3383.884876] FS: 7f8e27e74880() GS:88023ec0() knlGS: [ 3383.884888] CS: 0010 DS: ES: CR0: 8005003b [ 3383.884897] CR2: 7f60d89f35a8 CR3: 0001b5ada000 CR4: 07f0 [ 3383.884907] Stack: [ 3383.884941] 88010dcabb28 4000812bde34 00a8528d112e 0010 [ 3383.885012] 1000 1000 0f3a 8802348d6990 [ 3383.885082] 88001cbf5a00 880039f18000 00b8 88010dcabb00 [ 3383.885153] Call Trace: [ 3383.885192] [812f1a54] add_data_references+0x244/0x2e0 [ 3383.885232] [812f2a2b] relocate_block_group+0x56b/0x640 [ 3383.885272] [812f2ca2] btrfs_relocate_block_group+0x1a2/0x2f0 [ 3383.885313] [812cbcca] btrfs_relocate_chunk.isra.27+0x6a/0x740 [ 3383.885355] [81281a31] ? btrfs_set_path_blocking+0x31/0x70 [ 3383.885432] [81286816] ? btrfs_search_slot+0x386/0x960 [ 3383.885473] [812c6f07] ? free_extent_buffer+0x47/0xa0 [ 3383.885513] [812ceedb] btrfs_balance+0x90b/0xea0 [ 3383.885553] [812d5ec2] btrfs_ioctl_balance+0x162/0x520 [ 3383.885592] [812d9aed] btrfs_ioctl+0xcbd/0x25c0 [ 3383.885632] [818c094c] ? __do_page_fault+0x1dc/0x520 [ 3383.885673] [81136868] do_vfs_ioctl+0x2c8/0x490 [ 3383.885712] [81136ab1] SyS_ioctl+0x81/0xa0 [ 3383.885752] [818c4f5b] tracesys+0xdd/0xe2 [ 3383.885787] Code: ff 48 8b 4d a8 48 8d 75 b6 4c 89 ea 48 89 df e8 42 e7 ff ff 4c 89 ef 89 45 a8 e8 c7 0f f9 ff 8b 45 a8 e9 69 ff ff ff 85 c0 74 d6 0f 0b 66 0f 1f 84 00 00 00 00 00 b8 f4 ff ff ff e9 50 ff ff ff [ 3383.886001] RIP [812f0bd5] __add_tree_block+0x1c5/0x1e0 [ 3383.886042] RSP 88010dcaba38 [ 3383.886359] ---[ end trace 075209044ce10da3 ]--- Anything i can do to resolve / debug the issue? Remco-- 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: [GIT PULL] Btrfs
On Mon, Feb 03, 2014 at 01:18:40PM -0500, Chris Mason wrote: On Mon 03 Feb 2014 12:54:05 PM EST, David Sterba wrote: On Thu, Jan 30, 2014 at 04:52:54PM -0500, Chris Mason wrote: Chris Mason (3) commits (+64/-32): Btrfs: setup inode location during btrfs_init_inode_locked (+9/-9) Btrfs: don't use ram_bytes for uncompressed inline items (+52/-22) The patches are CC: stable, but haven't gone through the mailinglist. Are they still going to be picked by stable? We do need both in -stable, I'll help with backports. Very few of the patches you marked for -stable, actually would apply (or build once applied.) Can you please send a set of patches you want applied? thanks, greg k-h -- 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: [GIT PULL] Btrfs
On 02/04/2014 02:50 PM, Greg KH wrote: On Mon, Feb 03, 2014 at 01:18:40PM -0500, Chris Mason wrote: On Mon 03 Feb 2014 12:54:05 PM EST, David Sterba wrote: On Thu, Jan 30, 2014 at 04:52:54PM -0500, Chris Mason wrote: Chris Mason (3) commits (+64/-32): Btrfs: setup inode location during btrfs_init_inode_locked (+9/-9) Btrfs: don't use ram_bytes for uncompressed inline items (+52/-22) The patches are CC: stable, but haven't gone through the mailinglist. Are they still going to be picked by stable? We do need both in -stable, I'll help with backports. Very few of the patches you marked for -stable, actually would apply (or build once applied.) Can you please send a set of patches you want applied? Yes, I'll make a tree for you to pull. Between the acls and the block layer changes, we had a lot of little things that will make it hard to apply them directly, but the backports are pretty easy. -chris -- 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: Booting with syslinux not possible
Alex posted on Tue, 04 Feb 2014 17:19:09 + as excerpted: I have quite an (overly) complicated setup. I had to chuckle at that one. Fits my setup to a T, altho they're different complications than yours. I'll have to remember it the next time I find a fitting context to use it! =:^) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- 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: hitting BUG_ON on troublesome FS
On 02/03/2014 03:51 PM, Remco Hosman - Yerf-it.com wrote: FIrst, a bit of history of the filesystem: used to be 6 disks, now 5. partially raid1 / raid10. been migrating back and forth a few times. As some point, a balance would not complete and would end with 164 ENOSPC’ses, while there was plenty of unallocated space on each disk. i scanned for extends larger then 1gig and found a few, so ran a recursive balance of the entire FS. I deceided to empty the filesystem and format it. i pulled most files off it some via btrfs send/receive, some via rsync. but 1 subvol wouldn’t send. i don’t remember the exact error, but it was that a extend could not be found on 1 of the disks. with only a few 100gig of data left, i decided to balance some remaining empty space before doing a `btrfs dev del`, so have another disk to store more data on. but im hitting a snag, i hit a BUG_ON when doing a `btrfs bal start -dusage=2 /mountpoint` : [ 3327.678329] btrfs: found 198 extents [ 3328.117274] btrfs: relocating block group 84473084968960 flags 17 [ 3329.278521] btrfs: found 103 extents [ 3331.907931] btrfs: found 103 extents [ 3332.386172] btrfs: relocating block group 84466642518016 flags 17 [ .536595] btrfs: found 86 extents [ 3335.982967] btrfs: found 86 extents [ 3336.599555] btrfs (4746) used greatest stack depth: 2744 bytes left [ 3379.073464] btrfs: relocating block group 89878368419840 flags 17 [ 3381.608948] btrfs: found 499 extents [ 3383.884696] [ cut here ] [ 3383.884720] kernel BUG at fs/btrfs/relocation.c:3405! [ 3383.884731] invalid opcode: [#1] SMP [ 3383.884742] Modules linked in: [ 3383.884753] CPU: 0 PID: 5663 Comm: btrfs Not tainted 3.13.0 #1 [ 3383.884763] Hardware name: System manufacturer System Product Name/E45M1-I DELUXE, BIOS 0405 08/08/2012 [ 3383.884778] task: 8802360eae80 ti: 88010dcaa000 task.ti: 88010dcaa000 [ 3383.884790] RIP: 0010:[812f0bd5] [812f0bd5] __add_tree_block+0x1c5/0x1e0 [ 3383.884811] RSP: 0018:88010dcaba38 EFLAGS: 00010202 [ 3383.884821] RAX: 0001 RBX: 880039f18000 RCX: [ 3383.884832] RDX: RSI: RDI: [ 3383.884843] RBP: 88010dcaba90 R08: 88010dcab9f4 R09: 88010dcab930 [ 3383.884854] R10: R11: 047f R12: 1000 [ 3383.884865] R13: 88023489c630 R14: R15: 528d112e4000 [ 3383.884876] FS: 7f8e27e74880() GS:88023ec0() knlGS: [ 3383.884888] CS: 0010 DS: ES: CR0: 8005003b [ 3383.884897] CR2: 7f60d89f35a8 CR3: 0001b5ada000 CR4: 07f0 [ 3383.884907] Stack: [ 3383.884941] 88010dcabb28 4000812bde34 00a8528d112e 0010 [ 3383.885012] 1000 1000 0f3a 8802348d6990 [ 3383.885082] 88001cbf5a00 880039f18000 00b8 88010dcabb00 [ 3383.885153] Call Trace: [ 3383.885192] [812f1a54] add_data_references+0x244/0x2e0 [ 3383.885232] [812f2a2b] relocate_block_group+0x56b/0x640 [ 3383.885272] [812f2ca2] btrfs_relocate_block_group+0x1a2/0x2f0 [ 3383.885313] [812cbcca] btrfs_relocate_chunk.isra.27+0x6a/0x740 [ 3383.885355] [81281a31] ? btrfs_set_path_blocking+0x31/0x70 [ 3383.885432] [81286816] ? btrfs_search_slot+0x386/0x960 [ 3383.885473] [812c6f07] ? free_extent_buffer+0x47/0xa0 [ 3383.885513] [812ceedb] btrfs_balance+0x90b/0xea0 [ 3383.885553] [812d5ec2] btrfs_ioctl_balance+0x162/0x520 [ 3383.885592] [812d9aed] btrfs_ioctl+0xcbd/0x25c0 [ 3383.885632] [818c094c] ? __do_page_fault+0x1dc/0x520 [ 3383.885673] [81136868] do_vfs_ioctl+0x2c8/0x490 [ 3383.885712] [81136ab1] SyS_ioctl+0x81/0xa0 [ 3383.885752] [818c4f5b] tracesys+0xdd/0xe2 [ 3383.885787] Code: ff 48 8b 4d a8 48 8d 75 b6 4c 89 ea 48 89 df e8 42 e7 ff ff 4c 89 ef 89 45 a8 e8 c7 0f f9 ff 8b 45 a8 e9 69 ff ff ff 85 c0 74 d6 0f 0b 66 0f 1f 84 00 00 00 00 00 b8 f4 ff ff ff e9 50 ff ff ff [ 3383.886001] RIP [812f0bd5] __add_tree_block+0x1c5/0x1e0 [ 3383.886042] RSP 88010dcaba38 [ 3383.886359] ---[ end trace 075209044ce10da3 ]--- Anything i can do to resolve / debug the issue? Are you using skinny extents at all? Thanks, Josef -- 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
Are nocow files snapshot-aware
Hi! I'm curious... The whole snapshot thing on btrfs is based on its COW design. But you can make individual files and directory contents nocow by applying the C attribute on it using chattr. This is usually recommended for database files and VM images. So far, so good... But what happens to such files when they are part of a snapshot? Do they become duplicated during the snapshot? Do they become unshared (as a whole) when written to? Or when the the parent snapshot becomes deleted? Or maybe the nocow attribute is just ignored after a snapshot was taken? After all they are nocow and thus would be handled in another way when snapshotted. -- Replies to list only preferred. -- 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: Are nocow files snapshot-aware
On 02/04/2014 03:52 PM, Kai Krakow wrote: Hi! I'm curious... The whole snapshot thing on btrfs is based on its COW design. But you can make individual files and directory contents nocow by applying the C attribute on it using chattr. This is usually recommended for database files and VM images. So far, so good... But what happens to such files when they are part of a snapshot? Do they become duplicated during the snapshot? Do they become unshared (as a whole) when written to? Or when the the parent snapshot becomes deleted? Or maybe the nocow attribute is just ignored after a snapshot was taken? After all they are nocow and thus would be handled in another way when snapshotted. When snapshotted nocow files fallback to normal cow behaviour. Thanks, Josef -- 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: Are nocow files snapshot-aware
On Tue, Feb 04, 2014 at 08:22:05PM -0500, Josef Bacik wrote: On 02/04/2014 03:52 PM, Kai Krakow wrote: Hi! I'm curious... The whole snapshot thing on btrfs is based on its COW design. But you can make individual files and directory contents nocow by applying the C attribute on it using chattr. This is usually recommended for database files and VM images. So far, so good... But what happens to such files when they are part of a snapshot? Do they become duplicated during the snapshot? Do they become unshared (as a whole) when written to? Or when the the parent snapshot becomes deleted? Or maybe the nocow attribute is just ignored after a snapshot was taken? After all they are nocow and thus would be handled in another way when snapshotted. When snapshotted nocow files fallback to normal cow behaviour. This may seem unclear to people not familiar with the actual implementation, and I had to think for a second about that sentence. The file will keep the NOCOW status, but any modified blocks will be newly allocated on the first write (in a COW manner), then the block location will not change anymore (unlike ordinary COW). HTH -- 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: hitting BUG_ON on troublesome FS
How can i tell? Label: data uuid: a8626d67-4684-4b23-99b3-8d5fa8e7fd69 Total devices 5 FS bytes used 820.00KiB devid2 size 1.82TiB used 1.00GiB path /dev/sdb2 devid3 size 1.82TiB used 1.00GiB path /dev/sdf2 devid5 size 2.73TiB used 3.00GiB path /dev/sdd2 devid10 size 2.73TiB used 2.03GiB path /dev/sde2 devid11 size 3.64TiB used 1.03GiB path /dev/sdc1 Data, RAID10: total=3D2.00GiB, used=3D768.00KiB Data, RAID1: total=3D1.00GiB, used=3D12.00KiB System, RAID1: total=3D32.00MiB, used=3D4.00KiB Metadata, RAID1: total=3D1.00GiB, used=3D36.00KiB i made a image with `btrfs-image`, when i do -c 9, the file size is 7k, = so eazy enough to mail if it would be of any use. Remco On 04 Feb 2014, at 22:48, Josef Bacik jba...@fb.com wrote: On 02/03/2014 03:51 PM, Remco Hosman - Yerf-it.com wrote: FIrst, a bit of history of the filesystem: used to be 6 disks, now 5. partially raid1 / raid10. been migrating back and forth a few times. As some point, a balance would not complete and would end with 164 ENOSPC’ses, while there was plenty of unallocated space on each disk. i scanned for extends larger then 1gig and found a few, so ran a recursive balance of the entire FS. I deceided to empty the filesystem and format it. i pulled most files off it some via btrfs send/receive, some via rsync. but 1 subvol wouldn’t send. i don’t remember the exact error, but it was that a extend could not be found on 1 of the disks. with only a few 100gig of data left, i decided to balance some remaining empty space before doing a `btrfs dev del`, so have another disk to store more data on. but im hitting a snag, i hit a BUG_ON when doing a `btrfs bal start -dusage=2 /mountpoint` : [ 3327.678329] btrfs: found 198 extents [ 3328.117274] btrfs: relocating block group 84473084968960 flags 17 [ 3329.278521] btrfs: found 103 extents [ 3331.907931] btrfs: found 103 extents [ 3332.386172] btrfs: relocating block group 84466642518016 flags 17 [ .536595] btrfs: found 86 extents [ 3335.982967] btrfs: found 86 extents [ 3336.599555] btrfs (4746) used greatest stack depth: 2744 bytes left [ 3379.073464] btrfs: relocating block group 89878368419840 flags 17 [ 3381.608948] btrfs: found 499 extents [ 3383.884696] [ cut here ] [ 3383.884720] kernel BUG at fs/btrfs/relocation.c:3405! [ 3383.884731] invalid opcode: [#1] SMP [ 3383.884742] Modules linked in: [ 3383.884753] CPU: 0 PID: 5663 Comm: btrfs Not tainted 3.13.0 #1 [ 3383.884763] Hardware name: System manufacturer System Product Name/E45M1-I DELUXE, BIOS 0405 08/08/2012 [ 3383.884778] task: 8802360eae80 ti: 88010dcaa000 task.ti: 88010dcaa000 [ 3383.884790] RIP: 0010:[812f0bd5] [812f0bd5] __add_tree_block+0x1c5/0x1e0 [ 3383.884811] RSP: 0018:88010dcaba38 EFLAGS: 00010202 [ 3383.884821] RAX: 0001 RBX: 880039f18000 RCX: [ 3383.884832] RDX: RSI: RDI: [ 3383.884843] RBP: 88010dcaba90 R08: 88010dcab9f4 R09: 88010dcab930 [ 3383.884854] R10: R11: 047f R12: 1000 [ 3383.884865] R13: 88023489c630 R14: R15: 528d112e4000 [ 3383.884876] FS: 7f8e27e74880() GS:88023ec0() knlGS: [ 3383.884888] CS: 0010 DS: ES: CR0: 8005003b [ 3383.884897] CR2: 7f60d89f35a8 CR3: 0001b5ada000 CR4: 07f0 [ 3383.884907] Stack: [ 3383.884941] 88010dcabb28 4000812bde34 00a8528d112e 0010 [ 3383.885012] 1000 1000 0f3a 8802348d6990 [ 3383.885082] 88001cbf5a00 880039f18000 00b8 88010dcabb00 [ 3383.885153] Call Trace: [ 3383.885192] [812f1a54] add_data_references+0x244/0x2e0 [ 3383.885232] [812f2a2b] relocate_block_group+0x56b/0x640 [ 3383.885272] [812f2ca2] btrfs_relocate_block_group+0x1a2/0x2f0 [ 3383.885313] [812cbcca] btrfs_relocate_chunk.isra.27+0x6a/0x740 [ 3383.885355] [81281a31] ? btrfs_set_path_blocking+0x31/0x70 [ 3383.885432] [81286816] ? btrfs_search_slot+0x386/0x960 [ 3383.885473] [812c6f07] ? free_extent_buffer+0x47/0xa0 [ 3383.885513] [812ceedb] btrfs_balance+0x90b/0xea0 [ 3383.885553] [812d5ec2] btrfs_ioctl_balance+0x162/0x520 [ 3383.885592] [812d9aed] btrfs_ioctl+0xcbd/0x25c0 [ 3383.885632] [818c094c] ? __do_page_fault+0x1dc/0x520 [ 3383.885673] [81136868] do_vfs_ioctl+0x2c8/0x490 [ 3383.885712] [81136ab1] SyS_ioctl+0x81/0xa0 [ 3383.885752] [818c4f5b] tracesys+0xdd/0xe2 [ 3383.885787] Code: ff 48 8b 4d a8 48 8d 75 b6 4c 89 ea 48 89 df e8 42 e7 ff ff 4c 89 ef 89 45 a8 e8 c7 0f f9 ff 8b 45 a8 e9 69 ff ff ff 85 c0 74 d6 0f 0b 66 0f 1f 84 00
[PATCH] Btrfs: skip submitting barrier for missing device
I got an error on v3.13:
BTRFS error (device sdf1) in write_all_supers:3378: errno=-5 IO failure
(errors while submitting device barriers.)
how to reproduce:
mkfs.btrfs -f -d raid1 /dev/sdf1 /dev/sdf2
wipefs -a /dev/sdf2
mount -o degraded /dev/sdf1 /mnt
btrfs balance start -f -sconvert=single -mconvert=single -dconvert=single
/mnt
The reason of the error is that barrier_all_devices() failed to submit
barrier to the missing device. However it is clear that we cannot do
anything on missing device, and also it is not necessary to care chunks
on the missing device.
This patch stops sending/waiting barrier if device is missing.
Signed-off-by: Hidetoshi Seto seto.hideto...@jp.fujitsu.com
Cc: sta...@vger.kernel.org
---
fs/btrfs/disk-io.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 8072cfa..7eb50f3 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -3238,6 +3238,8 @@ static int barrier_all_devices(struct btrfs_fs_info *info)
/* send down all the barriers */
head = info-fs_devices-devices;
list_for_each_entry_rcu(dev, head, dev_list) {
+ if (dev-missing)
+ continue;
if (!dev-bdev) {
errors_send++;
continue;
@@ -3252,6 +3254,8 @@ static int barrier_all_devices(struct btrfs_fs_info *info)
/* wait for all the barriers */
list_for_each_entry_rcu(dev, head, dev_list) {
+ if (dev-missing)
+ continue;
if (!dev-bdev) {
errors_wait++;
continue;
--
1.7.1
--
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
