Re: Poll: time to switch skinny-metadata on by default?
Zygo Blaxell posted on Mon, 27 Oct 2014 00:39:25 -0400 as excerpted: One thing that may be significant is _when_ those 3 hanging filesystems are hanging: when using rsync to update local files. These machines are using the traditional rsync copy-then-rename method rather than --inplace updates. There's no problem copying data into an empty directory with rsync, but as soon as I start updating existing data, some process (not necessarily rsync) using with the filesystem gets stuck within 36 hours, and stays stuck for days. If I don't run rsync on the skinny filesystems, they'll run for a week or more without incident--and if I then start running rsync again, they hang later the same day. Limited counterpoint here: My packages partition is btrfs with skinny-metadata (skinny extents in dmsg), and the main gentoo tree on it gets regularly rsynced against gentoo servers. In fact, my sync script does that *AND* a git-pull on three overlays, in parallel with the rsync so all three git-pulls and the rsync are happening at once. No problems with that here. =:^) However, I suspect other factors in my setup avoid whatever's triggering it for Zygo. * The filesystem is btrfs raid1 mode data/metadata. * Only 24 GiB in size (show says 19.78 GiB used, df says 15.84 of 18 GiB data used, 969 MiB of 1.75 GiB metadata used). * Relatively fast SSD, ssd auto-detected and added as a mount option. * I set the skinny-metadata option (and extref and no-holes) at mkfs.btrfs time, while Zygo converted and presumably has both fat and skinny metadata. FWIW I've been spared all the rsync-triggered issues people have reported over time. I'm guessing I don't hit the same race conditions because with the small filesystem my overhead is lower, and with the ssd I simply don't have the same bottlenecks. So I'd not expect to hit this problem here either and that I'm not hitting it doesn't prove much, except that with reasonably fast ssds and smaller filesystems, whatever race conditions people seem to so commonly trigger with rsync elsewhere, simply don't seem to happen here. So as I said, limited counterpoint, but offered FWIW. -- 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: Poll: time to switch skinny-metadata on by default?
Marc Joliet posted on Mon, 27 Oct 2014 02:24:15 +0100 as excerpted: Am Sat, 25 Oct 2014 14:35:33 -0600 schrieb Chris Murphy li...@colorremedies.com: On Oct 25, 2014, at 2:33 PM, Chris Murphy li...@colorremedies.com wrote: On Oct 25, 2014, at 6:24 AM, Marc Joliet mar...@gmx.de wrote: First of all: does grub2 support booting from a btrfs file system with skinny-metadata, or is it irrelevant? Seems plausible if older kernels don't understand skinny-metadata, that GRUB2 won't either. So I just tested it with grub2-2.02-0.8.fc21 and it works. I'm surprised, actually. I don't understand the nature of the incompatibility with older kernels. Can they not mount a Btrfs volume even as ro? If so then I'd expect GRUB to have a problem, so I'm going to guess that maybe a 3.9 or older kernel could ro mount a Btrfs volume with skinny extents and the incompatibility is writing. That sounds plausible, though I hope for a definitive answer. (FWIW, I originally asked because I couldn't find any commits to grub2 related to skinny metadata; the updates to the btrfs driver were fairly sparse.) FWIW I have three /boot partitions, one one each of my main drives. All three are gpt with a reserved BIOS partition that grub2 installs its monolithic grub2core into, but have dedicated /boot partitions as well, for the grub2 config and additional grub2 modules, kernels, etc. The third one is reiserfs on spinning rust, but the other two are btrfs on ssd. Last time I updated I thought I switched them to skinny-metadata, but just checking dmesg while mounting them now, the second one (first backup) is skinny-metadata, but my working /boot is still fat-metadata. I did test the backup (with the skinny-metadata) after I did the mkfs and restore and it booted to grub2 and from grub2 to my main system just fine, so grub2 with skinny-metadata *CAN* work. But because it's my backup, I don't update it with new kernels as frequently as I do my working /boot, nor do I boot from it that often. So while I can be sure grub2 /can/ work with skinny-metadata, I do not yet know at this point if it does so /reliably/. And of course, to the extent that grub2 works differently on MBR and/or on GPT when it doesn't have a reserved BIOS partition to put the monolithic grub2core in, I haven't tested that. Tho in theory that should install in slack-space if available and the filesystem shouldn't affect that at all. But I know reiserfs used to screw up grub1 very occasionally (maybe .5-1% of new kernel installations; it did it I think twice in about 7 years, and I run git kernels so update them reasonably frequently) on my old MBR setup without much slack-space to spare, and I'd have to reinstall grub1. So that's a qualified skinny-metadata shouldn't affect grub2, as I've booted using grub2 on a btrfs with skinny-metadata /boot. But I've simply not tested it enough to know whether it's reliable over time as the filesystem updates and changes, or not. -- 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: Poll: time to switch skinny-metadata on by default?
Am Sat, 25 Oct 2014 14:35:33 -0600 schrieb Chris Murphy li...@colorremedies.com: On Oct 25, 2014, at 2:33 PM, Chris Murphy li...@colorremedies.com wrote: On Oct 25, 2014, at 6:24 AM, Marc Joliet mar...@gmx.de wrote: First of all: does grub2 support booting from a btrfs file system with skinny-metadata, or is it irrelevant? Seems plausible if older kernels don't understand skinny-metadata, that GRUB2 won't either. So I just tested it with grub2-2.02-0.8.fc21 and it works. I'm surprised, actually. I don't understand the nature of the incompatibility with older kernels. Can they not mount a Btrfs volume even as ro? If so then I'd expect GRUB to have a problem, so I'm going to guess that maybe a 3.9 or older kernel could ro mount a Btrfs volume with skinny extents and the incompatibility is writing. That sounds plausible, though I hope for a definitive answer. (FWIW, I originally asked because I couldn't find any commits to grub2 related to skinny metadata; the updates to the btrfs driver were fairly sparse.) -- Marc Joliet -- People who think they know everything really annoy those of us who know we don't - Bjarne Stroustrup signature.asc Description: PGP signature
Re: Poll: time to switch skinny-metadata on by default?
Am Sat, 25 Oct 2014 21:58:08 +0200 schrieb Marc Joliet mar...@gmx.de: Am Sat, 25 Oct 2014 14:24:58 +0200 schrieb Marc Joliet mar...@gmx.de: I can still access files on MARCEC_BACKUP just fine, and the snapshots are still there (btrfs subvolume list succeeds). Just an update: that was true for a while, but at one point listing directories and accessing the file system in general stopped working (all processes that touched the FS hung/zombified). This necessitated a hard reboot, since reboot and halt (so... shutdown, really) didn't do anything other than spit out the usual the system is rebooting message. Interestingly enough, the file system was (apparently) fine after that (just as Petr Janecek wrote), other than an invalid space cache file: [ 65.477006] BTRFS info (device sdg2): The free space cache file (2466854731776) is invalid. skip it That is, running my backup routine worked just as before, and I can access files on the FS just fine. Oh, and apparently the rebalance continued successfully?! [ 342.540865] BTRFS info (device sdg2): continuing balance [ 342.51] BTRFS info (device sdg2): relocating block group 2502355320832 flags 34 [ 342.821608] BTRFS info (device sdg2): found 4 extents [ 343.056915] BTRFS info (device sdg2): relocating block group 2501818449920 flags 36 [ 437.932405] BTRFS info (device sdg2): found 25086 extents [ 438.727197] BTRFS info (device sdg2): relocating block group 2501281579008 flags 36 [ 557.319354] BTRFS info (device sdg2): found 83875 extents # btrfs balance status /media/MARCEC_BACKUP No balance found on '/media/MARCEC_BACKUP' No SEGFAULT anywhere. All I can say right now is huh. Although I'll try starting a balance -m again tomorrow, because the continued balance only took about 3-4 minutes (maybe it . Maybe it exploded, I don't know (sorry, clearly I didn't delete the entirety of that incomplete train of thought). Anyway, I did run a full balance -m again, and this time it finished successfully. Make of that what you will, but it appears that the bug is non-deterministic (makes me wonder if Petr Janecek or anybody else who hit the bug ever got a balance to finish). HTH -- Marc Joliet -- People who think they know everything really annoy those of us who know we don't - Bjarne Stroustrup signature.asc Description: PGP signature
Re: Poll: time to switch skinny-metadata on by default?
On Mon, Oct 20, 2014 at 06:34:03PM +0200, David Sterba wrote: On Thu, Oct 16, 2014 at 01:33:37PM +0200, David Sterba wrote: I'd like to make it default with the 3.17 release of btrfs-progs. Please let me know if you have objections. For the record, 3.17 will not change the defaults. The timing of the poll was very bad to get enough feedback before the release. Let's keep it open for now. I don't have hard data, but I do have disturbing soft data: 12 btrfs filesystems with various mixed workloads 4 of those w/skinny metadata (converted with btrfstune -x) 3 of those have processes or the entire filesystem hanging every few days, triggering watchdog reboots I'm still trying to find the smoking gun, but it looks like there's a problem that only shows up when skinny metadata is enabled (or possibly one that only shows up when both skinny and non-skinny are mixed?). One thing that may be significant is _when_ those 3 hanging filesystems are hanging: when using rsync to update local files. These machines are using the traditional rsync copy-then-rename method rather than --inplace updates. There's no problem copying data into an empty directory with rsync, but as soon as I start updating existing data, some process (not necessarily rsync) using with the filesystem gets stuck within 36 hours, and stays stuck for days. If I don't run rsync on the skinny filesystems, they'll run for a week or more without incident--and if I then start running rsync again, they hang later the same day. When I get kernel stacks they show ~50 processes stuck all over the btrfs metadata manipulation code. If someone wants to wade through these I can collect them easily enough. The 4th skinny-metadata machine--the one that doesn't hang often--is the only one that isn't using rsync to receive files from elsewhere. It's also the busiest filesystem (in iops/sec) with the largest variety in its workload, so all things being equal it should be encountering more random btrfs problems than the other three. Some of my machines have multiple filesystems, some with skinny and some without. I've tried moving the rsync destination tree to the non-skinny filesystems on those machines, and in those cases I was able to complete several rsync updates without incident. That seems to rule out any system-level problem. The 8 filesystems without skinny don't have the hang problem. They have had a variety of other issues, but not hangs alone. Currently 3.17 + stable-queue patches fixes all the problems I've encountered so far with the non-skinny filesystems, so the skinny filesystems are now earning most of my attention. With this small sample size and data collection rate I admit I could just have a spurious correlation. The data also supports conclusions such as Western Digital hard drives cause hangs or filesystems created in August 2014 cause hangs. I'd encourage anyone with the intrastructure set up to do a larger-scale test to see if this is--or is not--reproducible. signature.asc Description: Digital signature
Re: Poll: time to switch skinny-metadata on by default?
Am Mon, 20 Oct 2014 18:34:03 +0200 schrieb David Sterba dste...@suse.cz: On Thu, Oct 16, 2014 at 01:33:37PM +0200, David Sterba wrote: I'd like to make it default with the 3.17 release of btrfs-progs. Please let me know if you have objections. For the record, 3.17 will not change the defaults. The timing of the poll was very bad to get enough feedback before the release. Let's keep it open for now. Two points: First of all: does grub2 support booting from a btrfs file system with skinny-metadata, or is it irrelevant? And secondly, I've gotten a BUG after trying to convert my external backup partition to skinny-metadata (the same one from the bug report mentioned previously in this thread, I believe). Below is a more detailed account. First of all, my setup (as of *now*, not before the BUG): # btrfs filesystem show Label: none uuid: 0267d8b3-a074-460a-832d-5d5fd36bae64 Total devices 1 FS bytes used 41.42GiB devid1 size 107.79GiB used 53.06GiB path /dev/sdf1 Label: 'MARCEC_STORAGE' uuid: 472c9290-3ff2-4096-9c47-0612d3a52cef Total devices 4 FS bytes used 514.54GiB devid1 size 298.09GiB used 259.03GiB path /dev/sda devid2 size 298.09GiB used 259.03GiB path /dev/sdb devid3 size 298.09GiB used 259.03GiB path /dev/sdc devid4 size 298.09GiB used 259.03GiB path /dev/sdd Label: 'MARCEC_BACKUP' uuid: f97b3cda-15e8-418b-bb9b-235391ef2a38 Total devices 1 FS bytes used 169.31GiB devid1 size 976.56GiB used 175.06GiB path /dev/sdg2 Btrfs v3.17 # btrfs filesystem df / Data, single: total=48.00GiB, used=39.94GiB System, DUP: total=32.00MiB, used=12.00KiB Metadata, DUP: total=2.50GiB, used=1.48GiB GlobalReserve, single: total=508.00MiB, used=0.00B # btrfs filesystem df /home Data, RAID10: total=516.00GiB, used=513.38GiB System, RAID10: total=64.00MiB, used=96.00KiB Metadata, RAID10: total=2.00GiB, used=1.16GiB GlobalReserve, single: total=400.00MiB, used=0.00B # btrfs filesystem df /media/MARCEC_BACKUP Data, single: total=167.00GiB, used=166.53GiB System, DUP: total=32.00MiB, used=28.00KiB Metadata, DUP: total=4.00GiB, used=2.79GiB GlobalReserve, single: total=512.00MiB, used=1.33MiB # uname -a Linux marcec 3.16.6-gentoo #1 SMP PREEMPT Fri Oct 24 01:06:49 CEST 2014 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ AuthenticAMD GNU/Linux # btrfs --version Btrfs v3.17 Now, what I was trying to do - motivated by this thread - was convert /home and /media/MARCEC_BACKUP to skinny-metadata, using btrfstune -x. That in itself worked fine, and the MARCEC_BACKUP has since seen filesystem activity (running rsync, creating and deleting snapshots). *Then* I started a btrfs balance -m on /home (which completed without errors) and then on /media/MARCEC_BACKUP, which is when the BUG happened (dmesg output see below). The result in user-space was that btrfs balance SEGFAULTed. btrfs balance status showed the balance still running, so I tried to cancel it, which ended up hanging (the btrfs program has yet to return back to the shell). For some reason I tried running sync (as root), which has also hung in the same way. I can still access files on MARCEC_BACKUP just fine, and the snapshots are still there (btrfs subvolume list succeeds). Is there anything else I can do, or any other information you might need? dmesg output (starting with the start of the balance) [ 4651.448883] BTRFS info (device sdb): relocating block group 1492765376512 flags 66 [ 4652.259501] BTRFS info (device sdb): found 2 extents [ 4652.987753] BTRFS info (device sdb): relocating block group 1491691634688 flags 68 [ 4688.655390] BTRFS info (device sdb): found 13744 extents [ 4689.382109] BTRFS info (device sdb): relocating block group 1485249183744 flags 68 [ 4753.879520] BTRFS info (device sdb): found 62519 extents [ 4791.123268] BTRFS info (device sdg2): relocating block group 2499670966272 flags 36 [ 4830.811665] BTRFS info (device sdg2): found 1793 extents [ 4831.240909] BTRFS info (device sdg2): relocating block group 2499134095360 flags 36 [ 5407.582370] BTRFS info (device sdg2): found 51182 extents [ 5407.959115] BTRFS info (device sdg2): relocating block group 2498597224448 flags 36 [ 5724.487824] BTRFS info (device sdg2): found 51435 extents [ 5725.006401] BTRFS info (device sdg2): relocating block group 2473867608064 flags 34 [ 5725.817513] BTRFS info (device sdg2): found 7 extents [ 5726.328413] BTRFS info (device sdg2): relocating block group 2469002215424 flags 36 [ 5844.148295] [ cut here ] [ 5844.148307] WARNING: CPU: 1 PID: 7270 at fs/btrfs/extent-tree.c:876 btrfs_lookup_extent_info+0x48c/0x4c0() [ 5844.148308] Modules linked in: uas usb_storage joydev hid_logitech_dj bridge stp llc ipt_REJECT xt_tcpudp iptable_filter iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4
Re: Poll: time to switch skinny-metadata on by default?
Am Sat, 25 Oct 2014 14:24:58 +0200 schrieb Marc Joliet mar...@gmx.de: I can still access files on MARCEC_BACKUP just fine, and the snapshots are still there (btrfs subvolume list succeeds). Just an update: that was true for a while, but at one point listing directories and accessing the file system in general stopped working (all processes that touched the FS hung/zombified). This necessitated a hard reboot, since reboot and halt (so... shutdown, really) didn't do anything other than spit out the usual the system is rebooting message. Interestingly enough, the file system was (apparently) fine after that (just as Petr Janecek wrote), other than an invalid space cache file: [ 65.477006] BTRFS info (device sdg2): The free space cache file (2466854731776) is invalid. skip it That is, running my backup routine worked just as before, and I can access files on the FS just fine. Oh, and apparently the rebalance continued successfully?! [ 342.540865] BTRFS info (device sdg2): continuing balance [ 342.51] BTRFS info (device sdg2): relocating block group 2502355320832 flags 34 [ 342.821608] BTRFS info (device sdg2): found 4 extents [ 343.056915] BTRFS info (device sdg2): relocating block group 2501818449920 flags 36 [ 437.932405] BTRFS info (device sdg2): found 25086 extents [ 438.727197] BTRFS info (device sdg2): relocating block group 2501281579008 flags 36 [ 557.319354] BTRFS info (device sdg2): found 83875 extents # btrfs balance status /media/MARCEC_BACKUP No balance found on '/media/MARCEC_BACKUP' No SEGFAULT anywhere. All I can say right now is huh. Although I'll try starting a balance -m again tomorrow, because the continued balance only took about 3-4 minutes (maybe it . HTH -- Marc Joliet -- People who think they know everything really annoy those of us who know we don't - Bjarne Stroustrup signature.asc Description: PGP signature
Re: Poll: time to switch skinny-metadata on by default?
On Thu, Oct 23, 2014 at 02:41:47AM +, Duncan wrote: Dave posted on Wed, 22 Oct 2014 08:49:46 -0400 as excerpted: On Tue, Oct 21, 2014 at 10:08 PM, Duncan 1i5t5.dun...@cox.net wrote: As for the mounted filesystem question, since all it does is flip a switch so that new metadata writes use the skinny-metadata code path, it shouldn't be a problem. Nope. Just tried it here: # btrfs --version Btrfs v3.16.1-42-g140eccb # btrfstune -x /dev/dm-0 /dev/dm-0 is mounted Thanks. So btrfstune refuses to set the skinny-metadata flag at all on mounted devices. Nicely reduces risk, /and/ answers the question. =:^) btrfstune requires an unmounted device. The on-line change to features is done via the sysfs interface, eg /sys/fs/btrfs/UUID/features, then echo 1 featurename. Right now only the extended refs (aka hardlink limit) can be turned on. -- 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: Poll: time to switch skinny-metadata on by default?
On 22 October 2014 04:08, Duncan 1i5t5.dun...@cox.net wrote: Since the kernel has code for both fat metadata and skinny-metadata, they can exist side-by-side and the kernel will use whichever code is appropriate. I understand that the fat extent code will probably never be removed for compatibility reasons, but do wonder why it's still the default. Caution? Petr Janecek's balancing problem [1] and similar bugs aside: is there a functional reason to prefer fat over skinny metadata for future file systems? Regards, T G-R [1] http://www.spinics.net/lists/linux-btrfs/msg38443.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: Poll: time to switch skinny-metadata on by default?
Tobias Geerinckx-Rice posted on Thu, 23 Oct 2014 16:47:19 +0200 as excerpted: On 22 October 2014 04:08, Duncan 1i5t5.dun...@cox.net wrote: Since the kernel has code for both fat metadata and skinny-metadata, they can exist side-by-side and the kernel will use whichever code is appropriate. I understand that the fat extent code will probably never be removed for compatibility reasons, but do wonder why it's still the default. Caution? Caution, backward kernel compatibility, and simply timing. The skinny code is newer, and there were several skinny-metadata related bugs in the first couple kernel cycles it was available, so not making it the immediate default was certainly wise. Tho the new code has been reasonably stable for awhile, now. But that's exactly why this discussion, is it time to make the new code the default yet, or not, because it hasn't been done yet. Additionally, some people want to keep the flexibility to mount with old kernels. Consider a distro installation and rescue image (ISO or USB), for instance. Those can be used for rescue purposes for not only the life of that distro release, but for sometime afterward. If the only rescue image you can find is a two year old image and it won't mount your btrfs because the on-device format has changed since then and your filesystem is the newer format, you're going to be one frustrated btrfs user! Petr Janecek's balancing problem [1] and similar bugs aside: is there a functional reason to prefer fat over skinny metadata for future file systems? Other than keeping backward compatibility to work with old rescue images and the like, as discussed above, not that I'm aware of. IOW, I know of no corner-case where fat metadata is now more efficient or more stable. -- 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: Poll: time to switch skinny-metadata on by default?
On Tue, Oct 21, 2014 at 10:08 PM, Duncan 1i5t5.dun...@cox.net wrote: As for the mounted filesystem question, since all it does is flip a switch so that new metadata writes use the skinny-metadata code path, it shouldn't be a problem. Nope. Just tried it here: # btrfs --version Btrfs v3.16.1-42-g140eccb # btrfstune -x /dev/dm-0 /dev/dm-0 is mounted -- -=[dave]=- Entropy isn't what it used to be. -- 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: Poll: time to switch skinny-metadata on by default?
Dave posted on Wed, 22 Oct 2014 08:49:46 -0400 as excerpted: On Tue, Oct 21, 2014 at 10:08 PM, Duncan 1i5t5.dun...@cox.net wrote: As for the mounted filesystem question, since all it does is flip a switch so that new metadata writes use the skinny-metadata code path, it shouldn't be a problem. Nope. Just tried it here: # btrfs --version Btrfs v3.16.1-42-g140eccb # btrfstune -x /dev/dm-0 /dev/dm-0 is mounted Thanks. So btrfstune refuses to set the skinny-metadata flag at all on mounted devices. Nicely reduces risk, /and/ answers the question. =:^) -- 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: Poll: time to switch skinny-metadata on by default?
David Sterba posted on Mon, 20 Oct 2014 18:34:03 +0200 as excerpted: On Thu, Oct 16, 2014 at 01:33:37PM +0200, David Sterba wrote: I'd like to make it default with the 3.17 release of btrfs-progs. Please let me know if you have objections. For the record, 3.17 will not change the defaults. The timing of the poll was very bad to get enough feedback before the release. Let's keep it open for now. FWIW my own results agree with yours, I've had no problem with skinny- metadata here, and it has been my default now for a couple backup-and-new- mkfs.btrfs generations, now. As you know there were some problems with it in the first kernel cycle or two after it was introduced as an option, and I waited awhile until they died down before trying it here, but as I said, no problems since I switched it on, and I've been running it awhile now. So defaulting to skinny-metadata looks good from here. =:^) -- 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: Poll: time to switch skinny-metadata on by default?
On 2014-10-21 05:29, Duncan wrote: David Sterba posted on Mon, 20 Oct 2014 18:34:03 +0200 as excerpted: On Thu, Oct 16, 2014 at 01:33:37PM +0200, David Sterba wrote: I'd like to make it default with the 3.17 release of btrfs-progs. Please let me know if you have objections. For the record, 3.17 will not change the defaults. The timing of the poll was very bad to get enough feedback before the release. Let's keep it open for now. FWIW my own results agree with yours, I've had no problem with skinny- metadata here, and it has been my default now for a couple backup-and-new- mkfs.btrfs generations, now. As you know there were some problems with it in the first kernel cycle or two after it was introduced as an option, and I waited awhile until they died down before trying it here, but as I said, no problems since I switched it on, and I've been running it awhile now. So defaulting to skinny-metadata looks good from here. =:^) Same here, I've been using it on all my systems since I switched from 3.15 to 3.16, and have had no issues whatsoever. smime.p7s Description: S/MIME Cryptographic Signature
Re: Poll: time to switch skinny-metadata on by default?
On 21/10/2014 2:02 μμ, Austin S Hemmelgarn wrote: On 2014-10-21 05:29, Duncan wrote: David Sterba posted on Mon, 20 Oct 2014 18:34:03 +0200 as excerpted: On Thu, Oct 16, 2014 at 01:33:37PM +0200, David Sterba wrote: I'd like to make it default with the 3.17 release of btrfs-progs. Please let me know if you have objections. For the record, 3.17 will not change the defaults. The timing of the poll was very bad to get enough feedback before the release. Let's keep it open for now. FWIW my own results agree with yours, I've had no problem with skinny- metadata here, and it has been my default now for a couple backup-and-new- mkfs.btrfs generations, now. As you know there were some problems with it in the first kernel cycle or two after it was introduced as an option, and I waited awhile until they died down before trying it here, but as I said, no problems since I switched it on, and I've been running it awhile now. So defaulting to skinny-metadata looks good from here. =:^) Same here, I've been using it on all my systems since I switched from 3.15 to 3.16, and have had no issues whatsoever. I am using skinny-metadata for years, and only once had an issue with it. It was with scrub and was fixed by Liu Bo[1], so i think skinny-metadata is mature enough be a default. [1] https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg34493.html -- Konstantinos Skarlatos -- 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: Poll: time to switch skinny-metadata on by default?
On Tue, Oct 21, 2014 at 5:29 AM, Duncan 1i5t5.dun...@cox.net wrote: David Sterba posted on Mon, 20 Oct 2014 18:34:03 +0200 as excerpted: On Thu, Oct 16, 2014 at 01:33:37PM +0200, David Sterba wrote: I'd like to make it default with the 3.17 release of btrfs-progs. Please let me know if you have objections. For the record, 3.17 will not change the defaults. The timing of the poll was very bad to get enough feedback before the release. Let's keep it open for now. FWIW my own results agree with yours, I've had no problem with skinny- metadata here, and it has been my default now for a couple backup-and-new- mkfs.btrfs generations, now. How does one enable it for an existing filesystem? Is it safe to just run btrfstune -x? Can this be done on a mounted filesystem? Are there any risks with converting? -- Rich -- 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: Poll: time to switch skinny-metadata on by default?
Rich Freeman posted on Tue, 21 Oct 2014 12:40:01 -0400 as excerpted: On Tue, Oct 21, 2014 at 5:29 AM, Duncan 1i5t5.dun...@cox.net wrote: David Sterba posted on Mon, 20 Oct 2014 18:34:03 +0200 as excerpted: On Thu, Oct 16, 2014 at 01:33:37PM +0200, David Sterba wrote: I'd like to make it default with the 3.17 release of btrfs-progs. Please let me know if you have objections. For the record, 3.17 will not change the defaults. The timing of the poll was very bad to get enough feedback before the release. Let's keep it open for now. FWIW my own results agree with yours, I've had no problem with skinny- metadata here, and it has been my default now for a couple backup-and-new- mkfs.btrfs generations, now. How does one enable it for an existing filesystem? Is it safe to just run btrfstune -x? Can this be done on a mounted filesystem? Are there any risks with converting? AFAIK, enabling skinny-metadata with btrfstune simply enables it for future metadata commits. It doesn't change existing metadata. However, with skinny-metadata enabled, doing a balance start -m will rewrite existing metadata, thus converting it to skinny if it wasn't skinny before. Since the kernel has code for both fat metadata and skinny-metadata, they can exist side-by-side and the kernel will use whichever code is appropriate. And since (afaik) a balance effects conversion of existing metadata by simply rewriting it using the same metadata writing paths it'd normally use only now on the skinny-metadata side, there should be no additional risk to that, either. The narrow-case additional risk there is would be due to the fact that the code paths are different, and while both paths have been well exercised by now with no bugs related to those specific code paths in awhile, in theory anyway, it's narrowly possible that an individual installation's use-case and data happened to work just fine on the available metadata, but will trigger some exotic and as yet unseen bug when you switch to skinny-metadata and thus exercise the other code- path. I'd call the risk of that nonzero but extremely unlikely. IOW, if you're familiar with Douglas Adams' Hitchhiker's Guide series, it's almost the kind of probability that you'd need an improbability drive to hit. =:^) If not, compare it to winning the lottery or getting struck by lightening, yes, people do sometimes do it, but it's not something you should plan your life around, particularly if you aren't in the habit of playing golf and sticking a club in the air, in the middle of a lightning storm! =:^) And if you're adverse to that sort of odds, why are you playing with still not entirely stable btrfs at this point, anyway? As for the mounted filesystem question, since all it does is flip a switch so that new metadata writes use the skinny-metadata code path, it shouldn't be a problem. However, I'd probably do it on an unmounted filesystem here, simply because there's no reason to tempt fate... unless your goal is to see what happens, of course. =:^) Matter of fact, personally, since I tend to periodically backup, do a fresh mkfs.btrfs with the new features I want enabled, and restore, I've never actually used btrfstune for this myself, either. But that's more a matter of that being the most convenient time to switch it over since I'm already doing the fresh mkfs anyway, than because I'm being overly cautious. Still, for those with a similar btrfs rotation system already in place, why tempt fate, unless of course your whole /object/ is a deliberate test and tempt of fate? BTW... @ Dave Sterba: I'm running no-holes too, and haven't had problems with it either, tho it's obviously a bit newer and doesn't yet have the degree of testing that skinny-metadata has. Any idea when that'll go default? It's probably best to stagger them, which probably means default no-holes for the 3.19 userspace release since default skinny-metadata is presumably going to be 3.18 now; does that sound about right? -- 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: Poll: time to switch skinny-metadata on by default?
On Thu, Oct 16, 2014 at 01:33:37PM +0200, David Sterba wrote: I'd like to make it default with the 3.17 release of btrfs-progs. Please let me know if you have objections. For the record, 3.17 will not change the defaults. The timing of the poll was very bad to get enough feedback before the release. Let's keep it open for now. -- 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: Poll: time to switch skinny-metadata on by default?
Hello, so far I haven't succeeded running btrfs balance on a large skinny-metadata fs -- segfault, kernel bug, reproducible. No such problems on ^skinny-metadata fs (same disks, same data). Tried both several times on 3.17. More info in comments 10,14 in https://bugzilla.kernel.org/show_bug.cgi?id=64961 I can't reproduce this, how big is your home directory, and are you still seeing corruptions after just rsyncing to a clean fs? Thanks, as I wrote in comment 10, it has improved since year ago when I reported it: I see no corruption at all, neither after rsync, nor after balance crash: btrfs check doesn't find anything wrong, files look ok. The only problem is that after adding a disk the balance segfaults on a kernel bug and the fs gets stuck. When I run balance again after reboot, it makes only a very small progress and crashes again the same way. There are some 2.5TB of data in 7.5M files on that fs. And couple dozen ro snapshots -- I'm testing 3.17 + revert of 9c3b306e1c9e right now, but it takes more than day to copy the data and recreate all the snapshots. But a test with ^skinny-metadata showed no problems, so I don't thing I got bitten by that bug. I have btrfs-image of one of previous runs after crashed balance. It's 15GB. I can place it somewhere with fast link, are you interested? Thanks, Petr -- 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: Poll: time to switch skinny-metadata on by default?
On 10/18/2014 07:21 AM, Petr Janecek wrote: Hello, so far I haven't succeeded running btrfs balance on a large skinny-metadata fs -- segfault, kernel bug, reproducible. No such problems on ^skinny-metadata fs (same disks, same data). Tried both several times on 3.17. More info in comments 10,14 in https://bugzilla.kernel.org/show_bug.cgi?id=64961 I can't reproduce this, how big is your home directory, and are you still seeing corruptions after just rsyncing to a clean fs? Thanks, as I wrote in comment 10, it has improved since year ago when I reported it: I see no corruption at all, neither after rsync, nor after balance crash: btrfs check doesn't find anything wrong, files look ok. The only problem is that after adding a disk the balance segfaults on a kernel bug and the fs gets stuck. When I run balance again after reboot, it makes only a very small progress and crashes again the same way. There are some 2.5TB of data in 7.5M files on that fs. And couple dozen ro snapshots -- I'm testing 3.17 + revert of 9c3b306e1c9e right now, but it takes more than day to copy the data and recreate all the snapshots. But a test with ^skinny-metadata showed no problems, so I don't thing I got bitten by that bug. I have btrfs-image of one of previous runs after crashed balance. It's 15GB. I can place it somewhere with fast link, are you interested? Yup, send me the link and I'll pull it down. 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: Poll: time to switch skinny-metadata on by default?
Hello Josef, With Skinny metadta and i running your btrfs-next repo for-suse branch (which has extent ref patch), i hit following problem: [ 250.679705] BTRFS info (device sdb): relocating block group 35597058048 flags 36 [ 250.728815] BTRFS info (device sdb): relocating block group 35462840320 flags 36 [ 253.562133] Dropping a ref for a root that doesn't have a ref on the block [ 253.562475] Dumping block entry [34793177088 8192], num_refs 3, metadata 0 [ 253.562795] Ref root 0, parent 35532013568, owner 23988, offset 0, num_refs 18446744073709551615 [ 253.563126] Ref root 0, parent 35560964096, owner 23988, offset 0, num_refs 1 [ 253.563505] Ref root 0, parent 35654615040, owner 23988, offset 0, num_refs 1 [ 253.563837] Ref root 0, parent 35678650368, owner 23988, offset 0, num_refs 1 [ 253.564162] Root entry 5, num_refs 1 [ 253.564520] Root entry 18446744073709551608, num_refs 18446744073709551615 [ 253.564860] Ref action 4, root 5, ref_root 5, parent 0, owner 23988, offset 0, num_refs 1 [ 253.565205][a049d2f1] process_leaf.isra.6+0x281/0x3e0 [btrfs] [ 253.565225][a049de83] build_ref_tree_for_root+0x433/0x460 [btrfs] [ 253.565234][a049e1af] btrfs_build_ref_tree+0x18f/0x1c0 [btrfs] [ 253.565241][a0419ce8] open_ctree+0x18b8/0x21a0 [btrfs] [ 253.565247][a03ecb0e] btrfs_mount+0x62e/0x8b0 [btrfs] [ 253.565251][812324e9] mount_fs+0x39/0x1b0 [ 253.565255][8125285b] vfs_kern_mount+0x6b/0x150 [ 253.565257][8125565b] do_mount+0x27b/0xc30 [ 253.565259][81256356] SyS_mount+0x96/0xf0 [ 253.565260][81795429] system_call_fastpath+0x16/0x1b [ 253.565263][] 0x [ 253.565272] Ref action 1, root 18446744073709551608, ref_root 0, parent 35654615040, owner 23988, offset 0, num_refs 1 [ 253.565681][a049d564] btrfs_ref_tree_mod+0x114/0x570 [btrfs] [ 253.565692][a03f946b] btrfs_inc_extent_ref+0x6b/0x120 [btrfs] [ 253.565697][a03fb77c] __btrfs_mod_ref+0x16c/0x2b0 [btrfs] [ 253.565702][a0401504] btrfs_inc_ref+0x14/0x20 [btrfs] [ 253.565707][a03f05ff] update_ref_for_cow+0x15f/0x380 [btrfs] [ 253.565711][a03f0a3d] __btrfs_cow_block+0x21d/0x540 [btrfs] [ 253.565716][a03f0f0c] btrfs_cow_block+0x12c/0x290 [btrfs] [ 253.565721][a046f59c] do_relocation+0x49c/0x570 [btrfs] [ 253.565728][a04723ce] relocate_tree_blocks+0x60e/0x660 [btrfs] [ 253.565735][a0473ce7] relocate_block_group+0x407/0x690 [btrfs] [ 253.565741][a0474148] btrfs_relocate_block_group+0x1d8/0x2f0 [btrfs] [ 253.565746][a04455a7] btrfs_relocate_chunk.isra.30+0x77/0x800 [btrfs] [ 253.565753][a0448a8b] __btrfs_balance+0x4eb/0x8d0 [btrfs] [ 253.565760][a044928a] btrfs_balance+0x41a/0x720 [btrfs] [ 253.565766][a045112a] btrfs_ioctl_balance+0x16a/0x530 [btrfs] [ 253.565772][a0456df8] btrfs_ioctl+0x588/0x2cb0 [btrfs] [ 253.565779] Ref action 1, root 18446744073709551608, ref_root 0, parent 35560964096, owner 23988, offset 0, num_refs 1 [ 253.566143][a049d564] btrfs_ref_tree_mod+0x114/0x570 [btrfs] [ 253.566152][a03f946b] btrfs_inc_extent_ref+0x6b/0x120 [btrfs] [ 253.566180][a03fb77c] __btrfs_mod_ref+0x16c/0x2b0 [btrfs] [ 253.566186][a0401504] btrfs_inc_ref+0x14/0x20 [btrfs] [ 253.566191][a03f071b] update_ref_for_cow+0x27b/0x380 [btrfs] [ 253.566195][a03f0a3d] __btrfs_cow_block+0x21d/0x540 [btrfs] [ 253.566199][a03f0f0c] btrfs_cow_block+0x12c/0x290 [btrfs] [ 253.566203][a046f59c] do_relocation+0x49c/0x570 [btrfs] [ 253.566210][a04723ce] relocate_tree_blocks+0x60e/0x660 [btrfs] [ 253.566216][a0473ce7] relocate_block_group+0x407/0x690 [btrfs] [ 253.566222][a0474148] btrfs_relocate_block_group+0x1d8/0x2f0 [btrfs] [ 253.566227][a04455a7] btrfs_relocate_chunk.isra.30+0x77/0x800 [btrfs] [ 253.566233][a0448a8b] __btrfs_balance+0x4eb/0x8d0 [btrfs] [ 253.566240][a044928a] btrfs_balance+0x41a/0x720 [btrfs] [ 253.566245][a045112a] btrfs_ioctl_balance+0x16a/0x530 [btrfs] [ 253.566252][a0456df8] btrfs_ioctl+0x588/0x2cb0 [btrfs] [ 253.566258] Ref action 2, root 18446744073709551608, ref_root 5, parent 0, owner 23988, offset 0, num_refs 18446744073709551615 [ 253.566641][a049d710] btrfs_ref_tree_mod+0x2c0/0x570 [btrfs] [ 253.566651][a040404a] btrfs_free_extent+0x7a/0x180 [btrfs] [ 253.566657][a03fb77c] __btrfs_mod_ref+0x16c/0x2b0 [btrfs] [ 253.52][a0401521] btrfs_dec_ref+0x11/0x20 [btrfs] [
Re: Poll: time to switch skinny-metadata on by default?
Thanks I'll run this on Monday. Josef Wang Shilong wangshilong1...@gmail.com wrote: Hello Josef, With Skinny metadta and i running your btrfs-next repo for-suse branch (which has extent ref patch), i hit following problem: [ 250.679705] BTRFS info (device sdb): relocating block group 35597058048 flags 36 [ 250.728815] BTRFS info (device sdb): relocating block group 35462840320 flags 36 [ 253.562133] Dropping a ref for a root that doesn't have a ref on the block [ 253.562475] Dumping block entry [34793177088 8192], num_refs 3, metadata 0 [ 253.562795] Ref root 0, parent 35532013568, owner 23988, offset 0, num_refs 18446744073709551615 [ 253.563126] Ref root 0, parent 35560964096, owner 23988, offset 0, num_refs 1 [ 253.563505] Ref root 0, parent 35654615040, owner 23988, offset 0, num_refs 1 [ 253.563837] Ref root 0, parent 35678650368, owner 23988, offset 0, num_refs 1 [ 253.564162] Root entry 5, num_refs 1 [ 253.564520] Root entry 18446744073709551608, num_refs 18446744073709551615 [ 253.564860] Ref action 4, root 5, ref_root 5, parent 0, owner 23988, offset 0, num_refs 1 [ 253.565205][a049d2f1] process_leaf.isra.6+0x281/0x3e0 [btrfs] [ 253.565225][a049de83] build_ref_tree_for_root+0x433/0x460 [btrfs] [ 253.565234][a049e1af] btrfs_build_ref_tree+0x18f/0x1c0 [btrfs] [ 253.565241][a0419ce8] open_ctree+0x18b8/0x21a0 [btrfs] [ 253.565247][a03ecb0e] btrfs_mount+0x62e/0x8b0 [btrfs] [ 253.565251][812324e9] mount_fs+0x39/0x1b0 [ 253.565255][8125285b] vfs_kern_mount+0x6b/0x150 [ 253.565257][8125565b] do_mount+0x27b/0xc30 [ 253.565259][81256356] SyS_mount+0x96/0xf0 [ 253.565260][81795429] system_call_fastpath+0x16/0x1b [ 253.565263][] 0x [ 253.565272] Ref action 1, root 18446744073709551608, ref_root 0, parent 35654615040, owner 23988, offset 0, num_refs 1 [ 253.565681][a049d564] btrfs_ref_tree_mod+0x114/0x570 [btrfs] [ 253.565692][a03f946b] btrfs_inc_extent_ref+0x6b/0x120 [btrfs] [ 253.565697][a03fb77c] __btrfs_mod_ref+0x16c/0x2b0 [btrfs] [ 253.565702][a0401504] btrfs_inc_ref+0x14/0x20 [btrfs] [ 253.565707][a03f05ff] update_ref_for_cow+0x15f/0x380 [btrfs] [ 253.565711][a03f0a3d] __btrfs_cow_block+0x21d/0x540 [btrfs] [ 253.565716][a03f0f0c] btrfs_cow_block+0x12c/0x290 [btrfs] [ 253.565721][a046f59c] do_relocation+0x49c/0x570 [btrfs] [ 253.565728][a04723ce] relocate_tree_blocks+0x60e/0x660 [btrfs] [ 253.565735][a0473ce7] relocate_block_group+0x407/0x690 [btrfs] [ 253.565741][a0474148] btrfs_relocate_block_group+0x1d8/0x2f0 [btrfs] [ 253.565746][a04455a7] btrfs_relocate_chunk.isra.30+0x77/0x800 [btrfs] [ 253.565753][a0448a8b] __btrfs_balance+0x4eb/0x8d0 [btrfs] [ 253.565760][a044928a] btrfs_balance+0x41a/0x720 [btrfs] [ 253.565766][a045112a] btrfs_ioctl_balance+0x16a/0x530 [btrfs] [ 253.565772][a0456df8] btrfs_ioctl+0x588/0x2cb0 [btrfs] [ 253.565779] Ref action 1, root 18446744073709551608, ref_root 0, parent 35560964096, owner 23988, offset 0, num_refs 1 [ 253.566143][a049d564] btrfs_ref_tree_mod+0x114/0x570 [btrfs] [ 253.566152][a03f946b] btrfs_inc_extent_ref+0x6b/0x120 [btrfs] [ 253.566180][a03fb77c] __btrfs_mod_ref+0x16c/0x2b0 [btrfs] [ 253.566186][a0401504] btrfs_inc_ref+0x14/0x20 [btrfs] [ 253.566191][a03f071b] update_ref_for_cow+0x27b/0x380 [btrfs] [ 253.566195][a03f0a3d] __btrfs_cow_block+0x21d/0x540 [btrfs] [ 253.566199][a03f0f0c] btrfs_cow_block+0x12c/0x290 [btrfs] [ 253.566203][a046f59c] do_relocation+0x49c/0x570 [btrfs] [ 253.566210][a04723ce] relocate_tree_blocks+0x60e/0x660 [btrfs] [ 253.566216][a0473ce7] relocate_block_group+0x407/0x690 [btrfs] [ 253.566222][a0474148] btrfs_relocate_block_group+0x1d8/0x2f0 [btrfs] [ 253.566227][a04455a7] btrfs_relocate_chunk.isra.30+0x77/0x800 [btrfs] [ 253.566233][a0448a8b] __btrfs_balance+0x4eb/0x8d0 [btrfs] [ 253.566240][a044928a] btrfs_balance+0x41a/0x720 [btrfs] [ 253.566245][a045112a] btrfs_ioctl_balance+0x16a/0x530 [btrfs] [ 253.566252][a0456df8] btrfs_ioctl+0x588/0x2cb0 [btrfs] [ 253.566258] Ref action 2, root 18446744073709551608, ref_root 5, parent 0, owner 23988, offset 0, num_refs 18446744073709551615 [ 253.566641][a049d710] btrfs_ref_tree_mod+0x2c0/0x570 [btrfs] [ 253.566651][a040404a] btrfs_free_extent+0x7a/0x180 [btrfs] [ 253.566657][a03fb77c] __btrfs_mod_ref+0x16c/0x2b0 [btrfs] [ 253.52][a0401521] btrfs_dec_ref+0x11/0x20 [btrfs] [ 253.58][a03f07a8]
Re: Poll: time to switch skinny-metadata on by default?
Sure, that is cool, let me know if i could give any help! I have an idle VM that could run btrfs tests there.^_^ Thanks I'll run this on Monday. Josef Wang Shilong wangshilong1...@gmail.com wrote: Hello Josef, With Skinny metadta and i running your btrfs-next repo for-suse branch (which has extent ref patch), i hit following problem: [ 250.679705] BTRFS info (device sdb): relocating block group 35597058048 flags 36 [ 250.728815] BTRFS info (device sdb): relocating block group 35462840320 flags 36 [ 253.562133] Dropping a ref for a root that doesn't have a ref on the block [ 253.562475] Dumping block entry [34793177088 8192], num_refs 3, metadata 0 [ 253.562795] Ref root 0, parent 35532013568, owner 23988, offset 0, num_refs 18446744073709551615 [ 253.563126] Ref root 0, parent 35560964096, owner 23988, offset 0, num_refs 1 [ 253.563505] Ref root 0, parent 35654615040, owner 23988, offset 0, num_refs 1 [ 253.563837] Ref root 0, parent 35678650368, owner 23988, offset 0, num_refs 1 [ 253.564162] Root entry 5, num_refs 1 [ 253.564520] Root entry 18446744073709551608, num_refs 18446744073709551615 [ 253.564860] Ref action 4, root 5, ref_root 5, parent 0, owner 23988, offset 0, num_refs 1 [ 253.565205][a049d2f1] process_leaf.isra.6+0x281/0x3e0 [btrfs] [ 253.565225][a049de83] build_ref_tree_for_root+0x433/0x460 [btrfs] [ 253.565234][a049e1af] btrfs_build_ref_tree+0x18f/0x1c0 [btrfs] [ 253.565241][a0419ce8] open_ctree+0x18b8/0x21a0 [btrfs] [ 253.565247][a03ecb0e] btrfs_mount+0x62e/0x8b0 [btrfs] [ 253.565251][812324e9] mount_fs+0x39/0x1b0 [ 253.565255][8125285b] vfs_kern_mount+0x6b/0x150 [ 253.565257][8125565b] do_mount+0x27b/0xc30 [ 253.565259][81256356] SyS_mount+0x96/0xf0 [ 253.565260][81795429] system_call_fastpath+0x16/0x1b [ 253.565263][] 0x [ 253.565272] Ref action 1, root 18446744073709551608, ref_root 0, parent 35654615040, owner 23988, offset 0, num_refs 1 [ 253.565681][a049d564] btrfs_ref_tree_mod+0x114/0x570 [btrfs] [ 253.565692][a03f946b] btrfs_inc_extent_ref+0x6b/0x120 [btrfs] [ 253.565697][a03fb77c] __btrfs_mod_ref+0x16c/0x2b0 [btrfs] [ 253.565702][a0401504] btrfs_inc_ref+0x14/0x20 [btrfs] [ 253.565707][a03f05ff] update_ref_for_cow+0x15f/0x380 [btrfs] [ 253.565711][a03f0a3d] __btrfs_cow_block+0x21d/0x540 [btrfs] [ 253.565716][a03f0f0c] btrfs_cow_block+0x12c/0x290 [btrfs] [ 253.565721][a046f59c] do_relocation+0x49c/0x570 [btrfs] [ 253.565728][a04723ce] relocate_tree_blocks+0x60e/0x660 [btrfs] [ 253.565735][a0473ce7] relocate_block_group+0x407/0x690 [btrfs] [ 253.565741][a0474148] btrfs_relocate_block_group+0x1d8/0x2f0 [btrfs] [ 253.565746][a04455a7] btrfs_relocate_chunk.isra.30+0x77/0x800 [btrfs] [ 253.565753][a0448a8b] __btrfs_balance+0x4eb/0x8d0 [btrfs] [ 253.565760][a044928a] btrfs_balance+0x41a/0x720 [btrfs] [ 253.565766][a045112a] btrfs_ioctl_balance+0x16a/0x530 [btrfs] [ 253.565772][a0456df8] btrfs_ioctl+0x588/0x2cb0 [btrfs] [ 253.565779] Ref action 1, root 18446744073709551608, ref_root 0, parent 35560964096, owner 23988, offset 0, num_refs 1 [ 253.566143][a049d564] btrfs_ref_tree_mod+0x114/0x570 [btrfs] [ 253.566152][a03f946b] btrfs_inc_extent_ref+0x6b/0x120 [btrfs] [ 253.566180][a03fb77c] __btrfs_mod_ref+0x16c/0x2b0 [btrfs] [ 253.566186][a0401504] btrfs_inc_ref+0x14/0x20 [btrfs] [ 253.566191][a03f071b] update_ref_for_cow+0x27b/0x380 [btrfs] [ 253.566195][a03f0a3d] __btrfs_cow_block+0x21d/0x540 [btrfs] [ 253.566199][a03f0f0c] btrfs_cow_block+0x12c/0x290 [btrfs] [ 253.566203][a046f59c] do_relocation+0x49c/0x570 [btrfs] [ 253.566210][a04723ce] relocate_tree_blocks+0x60e/0x660 [btrfs] [ 253.566216][a0473ce7] relocate_block_group+0x407/0x690 [btrfs] [ 253.566222][a0474148] btrfs_relocate_block_group+0x1d8/0x2f0 [btrfs] [ 253.566227][a04455a7] btrfs_relocate_chunk.isra.30+0x77/0x800 [btrfs] [ 253.566233][a0448a8b] __btrfs_balance+0x4eb/0x8d0 [btrfs] [ 253.566240][a044928a] btrfs_balance+0x41a/0x720 [btrfs] [ 253.566245][a045112a] btrfs_ioctl_balance+0x16a/0x530 [btrfs] [ 253.566252][a0456df8] btrfs_ioctl+0x588/0x2cb0 [btrfs] [ 253.566258] Ref action 2, root 18446744073709551608, ref_root 5, parent 0, owner 23988, offset 0, num_refs 18446744073709551615 [ 253.566641][a049d710] btrfs_ref_tree_mod+0x2c0/0x570 [btrfs] [ 253.566651][a040404a]
Re: Poll: time to switch skinny-metadata on by default?
Hello, the core of skinny-metadata feature has been merged in 3.10 (Jun 2013) and has been reportedly used by many people. No major bugs were reported lately unless I missed them. so far I haven't succeeded running btrfs balance on a large skinny-metadata fs -- segfault, kernel bug, reproducible. No such problems on ^skinny-metadata fs (same disks, same data). Tried both several times on 3.17. More info in comments 10,14 in https://bugzilla.kernel.org/show_bug.cgi?id=64961 Regards, Petr -- 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: Poll: time to switch skinny-metadata on by default?
On 10/17/2014 08:30 AM, Petr Janecek wrote: Hello, the core of skinny-metadata feature has been merged in 3.10 (Jun 2013) and has been reportedly used by many people. No major bugs were reported lately unless I missed them. so far I haven't succeeded running btrfs balance on a large skinny-metadata fs -- segfault, kernel bug, reproducible. No such problems on ^skinny-metadata fs (same disks, same data). Tried both several times on 3.17. More info in comments 10,14 in https://urldefense.proofpoint.com/v1/url?u=https://bugzilla.kernel.org/show_bug.cgi?id%3D64961k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0Ar=cKCbChRKsMpTX8ybrSkonQ%3D%3D%0Am=3qxE39iiu%2BoZB%2F05dE7hnGHZojWhjjijrtjNYki0NFg%3D%0As=b262347a1ad2505ebdcb21dcc9f0944a14c174a1dcf447746ce196faddd99092 I can't reproduce this, how big is your home directory, and are you still seeing corruptions after just rsyncing to a clean fs? 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
Poll: time to switch skinny-metadata on by default?
Hi, the core of skinny-metadata feature has been merged in 3.10 (Jun 2013) and has been reportedly used by many people. No major bugs were reported lately unless I missed them. The obvious benefit is reduced metadata consumption at the cost of lost backward compatibility for pre-3.10 kernels. I believe this is acceptable to do the change now. The feature can be turned off at mkfs time by '-O ^skinny-metadata' if needed. I'd like to make it default with the 3.17 release of btrfs-progs. Please let me know if you have objections. -- 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