Re: unsolvable technical issues?
On 2018-07-03 03:35, Duncan wrote: Austin S. Hemmelgarn posted on Mon, 02 Jul 2018 07:49:05 -0400 as excerpted: Notably, most Intel systems I've seen have the SATA controllers in the chipset enumerate after the USB controllers, and the whole chipset enumerates after add-in cards (so they almost always have this issue), while most AMD systems I've seen demonstrate the exact opposite behavior, they enumerate the SATA controller from the chipset before the USB controllers, and then enumerate the chipset before all the add-in cards (so they almost never have this issue). Thanks. That's a difference I wasn't aware of, and would (because I tend to favor amd) explain why I've never seen a change in enumeration order unless I've done something like unplug my sata cables for maintenance and forget which ones I had plugged in where -- random USB stuff left plugged in doesn't seem to matter, even choosing different boot media from the bios doesn't seem to matter by the time the kernel runs (I'm less sure about grub). Additionally though, if you in some way make sure SATA drivers are loaded before USB ones, you will also never see this issue because of USB devices (same goes for GRUB). A lot of laptops that use connections other than USB for the keyboard and mouse behave like this if you use a properly stripped down initramfs because you won't have USB drivers in the initramfs (and therefore the SATA drivers always load first). -- 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: unsolvable technical issues?
Austin S. Hemmelgarn posted on Mon, 02 Jul 2018 07:49:05 -0400 as excerpted: > Notably, most Intel systems I've seen have the SATA controllers in the > chipset enumerate after the USB controllers, and the whole chipset > enumerates after add-in cards (so they almost always have this issue), > while most AMD systems I've seen demonstrate the exact opposite > behavior, > they enumerate the SATA controller from the chipset before the USB > controllers, and then enumerate the chipset before all the add-in cards > (so they almost never have this issue). Thanks. That's a difference I wasn't aware of, and would (because I tend to favor amd) explain why I've never seen a change in enumeration order unless I've done something like unplug my sata cables for maintenance and forget which ones I had plugged in where -- random USB stuff left plugged in doesn't seem to matter, even choosing different boot media from the bios doesn't seem to matter by the time the kernel runs (I'm less sure about grub). -- 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: unsolvable technical issues?
On 2018-06-30 01:32, Andrei Borzenkov wrote: 30.06.2018 06:22, Duncan пишет: Austin S. Hemmelgarn posted on Mon, 25 Jun 2018 07:26:41 -0400 as excerpted: On 2018-06-24 16:22, Goffredo Baroncelli wrote: On 06/23/2018 07:11 AM, Duncan wrote: waxhead posted on Fri, 22 Jun 2018 01:13:31 +0200 as excerpted: According to this: https://stratis-storage.github.io/StratisSoftwareDesign.pdf Page 4 , section 1.2 It claims that BTRFS still have significant technical issues that may never be resolved. I can speculate a bit. 1) When I see btrfs "technical issue that may never be resolved", the #1 first thing I think of, that AFAIK there are _definitely_ no plans to resolve, because it's very deeply woven into the btrfs core by now, is... [1)] Filesystem UUID Identification. Btrfs takes the UU bit of Universally Unique quite literally, assuming they really *are* unique, at least on that system[.] Because btrfs uses this supposedly unique ID to ID devices that belong to the filesystem, it can get *very* mixed up, with results possibly including dataloss, if it sees devices that don't actually belong to a filesystem with the same UUID as a mounted filesystem. As partial workaround you can disable udev btrfs rules and then do a "btrfs dev scan" manually only for the device which you need. You don't even need `btrfs dev scan` if you just specify the exact set of devices in the mount options. The `device=` mount option tells the kernel to check that device during the mount process. Not that lvm does any better in this regard[1], but has btrfs ever solved the bug where only one device= in the kernel commandline's rootflags= would take effect, effectively forcing initr* on people (like me) who would otherwise not need them and prefer to do without them, if they're using a multi-device btrfs as root? This requires in-kernel device scanning; I doubt we will ever see it. Not to mention the fact that as kernel people will tell you, device enumeration isn't guaranteed to be in the same order every boot, so device=/dev/* can't be relied upon and shouldn't be used -- but of course device=LABEL= and device=UUID= and similar won't work without userspace, basically udev (if they work at all, IDK if they actually do). Tho in practice from what I've seen, device enumeration order tends to be dependable /enough/ for at least those without enterprise-level numbers of devices to enumerate. Just boot with USB stick/eSATA drive plugged in, there are good chances it changes device order. It really depends on your particular hardware. If your USB controllers are at lower PCI addresses than your primary disk controllers, then yes, this will cause an issue. Same for whatever SATA controller your eSATA port is on (or stupid systems where the eSATA port is port 0 on the main SATA controller). Notably, most Intel systems I've seen have the SATA controllers in the chipset enumerate after the USB controllers, and the whole chipset enumerates after add-in cards (so they almost always have this issue), while most AMD systems I've seen demonstrate the exact opposite behavior, they enumerate the SATA controller from the chipset before the USB controllers, and then enumerate the chipset before all the add-in cards (so they almost never have this issue). That said, one of the constraints for them remaining consistent is that you don't change hardware. True, it /does/ change from time to time with a new kernel, but anybody sane keeps a tested-dependable old kernel around to boot to until they know the new one works as expected, and that sort of change is seldom enough that users can boot to the old kernel and adjust their settings for the new one as necessary when it does happen. So as "don't do it that way because it's not reliable" as it might indeed be in theory, in practice, just using an ordered /dev/* in kernel commandlines does tend to "just work"... provided one is ready for the occasion when that device parameter might need a bit of adjustment, of course. ... --- [1] LVM is userspace code on top of the kernelspace devicemapper, and therefore requires an initr* if root is on lvm, regardless. So btrfs actually does a bit better here, only requiring it for multi-device btrfs. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: unsolvable technical issues?
On 2018-06-29 23:22, Duncan wrote: Austin S. Hemmelgarn posted on Mon, 25 Jun 2018 07:26:41 -0400 as excerpted: On 2018-06-24 16:22, Goffredo Baroncelli wrote: On 06/23/2018 07:11 AM, Duncan wrote: waxhead posted on Fri, 22 Jun 2018 01:13:31 +0200 as excerpted: According to this: https://stratis-storage.github.io/StratisSoftwareDesign.pdf Page 4 , section 1.2 It claims that BTRFS still have significant technical issues that may never be resolved. I can speculate a bit. 1) When I see btrfs "technical issue that may never be resolved", the #1 first thing I think of, that AFAIK there are _definitely_ no plans to resolve, because it's very deeply woven into the btrfs core by now, is... [1)] Filesystem UUID Identification. Btrfs takes the UU bit of Universally Unique quite literally, assuming they really *are* unique, at least on that system[.] Because btrfs uses this supposedly unique ID to ID devices that belong to the filesystem, it can get *very* mixed up, with results possibly including dataloss, if it sees devices that don't actually belong to a filesystem with the same UUID as a mounted filesystem. As partial workaround you can disable udev btrfs rules and then do a "btrfs dev scan" manually only for the device which you need. You don't even need `btrfs dev scan` if you just specify the exact set of devices in the mount options. The `device=` mount option tells the kernel to check that device during the mount process. Not that lvm does any better in this regard[1], but has btrfs ever solved the bug where only one device= in the kernel commandline's rootflags= would take effect, effectively forcing initr* on people (like me) who would otherwise not need them and prefer to do without them, if they're using a multi-device btrfs as root? I haven't tested this recently myself, so I don't know. Not to mention the fact that as kernel people will tell you, device enumeration isn't guaranteed to be in the same order every boot, so device=/dev/* can't be relied upon and shouldn't be used -- but of course device=LABEL= and device=UUID= and similar won't work without userspace, basically udev (if they work at all, IDK if they actually do). They aren't guaranteed to be stable, but they functionally are provided you don't modify hardware in any way and your disks can't be enumerated asynchronously without some form of ordered identification (IOW, you're using just one SATA or SCSI controller for all your disks). That said, the required component for the LABEL= and UUID= syntax is not udev, it's blkid. blkid can use udev to avoid having to read everything, but it's not mandatory. Tho in practice from what I've seen, device enumeration order tends to be dependable /enough/ for at least those without enterprise-level numbers of devices to enumerate. True, it /does/ change from time to time with a new kernel, but anybody sane keeps a tested-dependable old kernel around to boot to until they know the new one works as expected, and that sort of change is seldom enough that users can boot to the old kernel and adjust their settings for the new one as necessary when it does happen. So as "don't do it that way because it's not reliable" as it might indeed be in theory, in practice, just using an ordered /dev/* in kernel commandlines does tend to "just work"... provided one is ready for the occasion when that device parameter might need a bit of adjustment, of course. Also, while LVM does have 'issues' with cloned PV's, it fails safe (by refusing to work on VG's that have duplicate PV's), while BTRFS fails very unsafely (by randomly corrupting data). And IMO that "failing unsafe" is both serious and common enough that it easily justifies adding the point to a list of this sort, thus my putting it #1. Agreed. My point wasn't that BTRFS is doing things correctly, just that LVM is not a saint in this respect either (it's just more saintly than we are). 2) Subvolume and (more technically) reflink-aware defrag. It was there for a couple kernel versions some time ago, but "impossibly" slow, so it was disabled until such time as btrfs could be made to scale rather better in this regard. I still contend that the biggest issue WRT reflink-aware defrag was that it was not optional. The only way to get the old defrag behavior was to boot a kernel that didn't have reflink-aware defrag support. IOW, _everyone_ had to deal with the performance issues, not just the people who wanted to use reflink-aware defrag. Absolutely. Which of course suggests making it optional, with a suitable warning as to the speed implications with lots of snapshots/reflinks, when it does get enabled again (and as David mentions elsewhere, there's apparently some work going into the idea once again, which potentially moves it from the 3-5 year range, at best, back to a 1/2-2-year range, time will tell). 3) N-way-mirroring. [...] This is not an issue, but a not implemented feature If you're looking at
Re: unsolvable technical issues?
30.06.2018 06:22, Duncan пишет: > Austin S. Hemmelgarn posted on Mon, 25 Jun 2018 07:26:41 -0400 as > excerpted: > >> On 2018-06-24 16:22, Goffredo Baroncelli wrote: >>> On 06/23/2018 07:11 AM, Duncan wrote: waxhead posted on Fri, 22 Jun 2018 01:13:31 +0200 as excerpted: > According to this: > > https://stratis-storage.github.io/StratisSoftwareDesign.pdf Page 4 , > section 1.2 > > It claims that BTRFS still have significant technical issues that may > never be resolved. I can speculate a bit. 1) When I see btrfs "technical issue that may never be resolved", the #1 first thing I think of, that AFAIK there are _definitely_ no plans to resolve, because it's very deeply woven into the btrfs core by now, is... [1)] Filesystem UUID Identification. Btrfs takes the UU bit of Universally Unique quite literally, assuming they really *are* unique, at least on that system[.] Because btrfs uses this supposedly unique ID to ID devices that belong to the filesystem, it can get *very* mixed up, with results possibly including dataloss, if it sees devices that don't actually belong to a filesystem with the same UUID as a mounted filesystem. >>> >>> As partial workaround you can disable udev btrfs rules and then do a >>> "btrfs dev scan" manually only for the device which you need. > >> You don't even need `btrfs dev scan` if you just specify the exact set >> of devices in the mount options. The `device=` mount option tells the >> kernel to check that device during the mount process. > > Not that lvm does any better in this regard[1], but has btrfs ever solved > the bug where only one device= in the kernel commandline's rootflags= > would take effect, effectively forcing initr* on people (like me) who > would otherwise not need them and prefer to do without them, if they're > using a multi-device btrfs as root? > This requires in-kernel device scanning; I doubt we will ever see it. > Not to mention the fact that as kernel people will tell you, device > enumeration isn't guaranteed to be in the same order every boot, so > device=/dev/* can't be relied upon and shouldn't be used -- but of course > device=LABEL= and device=UUID= and similar won't work without userspace, > basically udev (if they work at all, IDK if they actually do). > > Tho in practice from what I've seen, device enumeration order tends to be > dependable /enough/ for at least those without enterprise-level numbers > of devices to enumerate. Just boot with USB stick/eSATA drive plugged in, there are good chances it changes device order. > True, it /does/ change from time to time with a > new kernel, but anybody sane keeps a tested-dependable old kernel around > to boot to until they know the new one works as expected, and that sort > of change is seldom enough that users can boot to the old kernel and > adjust their settings for the new one as necessary when it does happen. > So as "don't do it that way because it's not reliable" as it might indeed > be in theory, in practice, just using an ordered /dev/* in kernel > commandlines does tend to "just work"... provided one is ready for the > occasion when that device parameter might need a bit of adjustment, of > course. > ... > > --- > [1] LVM is userspace code on top of the kernelspace devicemapper, and > therefore requires an initr* if root is on lvm, regardless. So btrfs > actually does a bit better here, only requiring it for multi-device btrfs. > -- 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: unsolvable technical issues?
Hugo Mills posted on Mon, 25 Jun 2018 16:54:36 + as excerpted: > On Mon, Jun 25, 2018 at 06:43:38PM +0200, waxhead wrote: > [snip] >> I hope I am not asking for too much (but I know I probably am), but I >> suggest that having a small snippet of information on the status page >> showing a little bit about what is either currently the development >> focus , or what people are known for working at would be very valuable >> for users and it may of course work both ways, such as exciting people >> or calming them down. ;) >> >> For example something simple like a "development focus" list... >> 2018-Q4: (planned) Renaming the grotesque "RAID" terminology >> 2018-Q3: (planned) Magical feature X >> 2018-Q2: N-Way mirroring >> 2018-Q1: Feature work "RAID"5/6 >> >> I think it would be good for people living their lives outside as it >> would perhaps spark some attention from developers and perhaps even >> media as well. > > I started doing this a couple of years ago, but it turned out to be > impossible to keep even vaguely accurate or up to date, without going > round and bugging the developers individually on a per-release basis. I > don't think it's going to happen. In addition, anything like quarter, kernel cycle, etc, has been repeatedly demonstrated to be entirely broken beyond "current", because roadmapped tasks have rather consistently taken longer, sometimes /many/ /times/ longer (by a factor of 20+ in the case of raid56), than first predicted. But in theory it might be double, with just a roughly ordered list, no dates beyond "current focus", and with suitably big disclaimers about other things (generally bugs in otherwise more stable features, but occasionally a quick sub-feature that is seen to be easier to introduce at the current state than it might be later, etc) possibly getting priority and temporarily displacing roadmapped items. In fact, this last one is the big reason why raid56 has taken so long to even somewhat stabilize -- the devs kept finding bugs in already semi- stable features that took priority... for kernel cycle after kernel cycle. The quotas/qgroups feature, already introduced and intended to be at least semi-stable was one such culprit, requiring repeated rewrite and kernel cycles worth of bug squashing. A few critical under the right circumstances compression bugs, where compression was supposed to be an already reasonably stable feature, were another, tho these took far less developer bandwidth than quotas. Getting a reasonably usable fsck was a bunch of little patches. AFAIK that one wasn't actually an original focus and was intended to be back-burnered for some time, but once btrfs hit mainline, users started demanding it, so the priority was bumped. And of course having it has been good for finding and ultimately fixing other bugs as well, so it wasn't a bad thing, but the hard fact is the repairing fsck has taken, all told, I'd guess about the same number of developer cycles as quotas, and those developer cycles had to come from stuff that had been roadmapped for earlier. As a bit of an optimist I'd be inclined to argue that OK, we've gotten btrfs in far better shape general stability-wise now, and going forward, the focus can be back on the stuff that was roadmapped for earlier that this stuff displaced, so one might hope things will move faster again now, but really, who knows? That's arguably what the devs thought when they mainlined btrfs, too, and yet it took all this much longer to mature and stabilize since then. Still, it /has/ to happen at /some/ point, right? And I know for a fact that btrfs is far more stable now than it was... because things like ungraceful shutdowns that used to at minimum trigger (raid1 mode) scrub fixes on remount and scrub, now... don't -- btrfs is now stable enough that the atomic COW is doing its job and things "just work", where before, they required scrub repair at best, and occasional blow away and restore from backups. So I can at least /hope/ that the worst of the plague of bugs is behind us, and people can work on what they intended to do most (say 80%) of the time now, spending say a day's worth a week (20%) on bugs, instead of the reverse, 80% (4 days a week) on bugs and if they're lucky, a day a week on what they were supposed to be focused on, which is what we were seeing for awhile. Plus the tools to do the debugging, etc, are far more mature now, another reason bugs should hopefully take less time now. -- 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: unsolvable technical issues?
Austin S. Hemmelgarn posted on Mon, 25 Jun 2018 07:26:41 -0400 as excerpted: > On 2018-06-24 16:22, Goffredo Baroncelli wrote: >> On 06/23/2018 07:11 AM, Duncan wrote: >>> waxhead posted on Fri, 22 Jun 2018 01:13:31 +0200 as excerpted: >>> According to this: https://stratis-storage.github.io/StratisSoftwareDesign.pdf Page 4 , section 1.2 It claims that BTRFS still have significant technical issues that may never be resolved. >>> >>> I can speculate a bit. >>> >>> 1) When I see btrfs "technical issue that may never be resolved", the >>> #1 first thing I think of, that AFAIK there are _definitely_ no plans >>> to resolve, because it's very deeply woven into the btrfs core by now, >>> is... >>> >>> [1)] Filesystem UUID Identification. Btrfs takes the UU bit of >>> Universally Unique quite literally, assuming they really *are* >>> unique, at least on that system[.] Because >>> btrfs uses this supposedly unique ID to ID devices that belong to the >>> filesystem, it can get *very* mixed up, with results possibly >>> including dataloss, if it sees devices that don't actually belong to a >>> filesystem with the same UUID as a mounted filesystem. >> >> As partial workaround you can disable udev btrfs rules and then do a >> "btrfs dev scan" manually only for the device which you need. > You don't even need `btrfs dev scan` if you just specify the exact set > of devices in the mount options. The `device=` mount option tells the > kernel to check that device during the mount process. Not that lvm does any better in this regard[1], but has btrfs ever solved the bug where only one device= in the kernel commandline's rootflags= would take effect, effectively forcing initr* on people (like me) who would otherwise not need them and prefer to do without them, if they're using a multi-device btrfs as root? Not to mention the fact that as kernel people will tell you, device enumeration isn't guaranteed to be in the same order every boot, so device=/dev/* can't be relied upon and shouldn't be used -- but of course device=LABEL= and device=UUID= and similar won't work without userspace, basically udev (if they work at all, IDK if they actually do). Tho in practice from what I've seen, device enumeration order tends to be dependable /enough/ for at least those without enterprise-level numbers of devices to enumerate. True, it /does/ change from time to time with a new kernel, but anybody sane keeps a tested-dependable old kernel around to boot to until they know the new one works as expected, and that sort of change is seldom enough that users can boot to the old kernel and adjust their settings for the new one as necessary when it does happen. So as "don't do it that way because it's not reliable" as it might indeed be in theory, in practice, just using an ordered /dev/* in kernel commandlines does tend to "just work"... provided one is ready for the occasion when that device parameter might need a bit of adjustment, of course. > Also, while LVM does have 'issues' with cloned PV's, it fails safe (by > refusing to work on VG's that have duplicate PV's), while BTRFS fails > very unsafely (by randomly corrupting data). And IMO that "failing unsafe" is both serious and common enough that it easily justifies adding the point to a list of this sort, thus my putting it #1. >>> 2) Subvolume and (more technically) reflink-aware defrag. >>> >>> It was there for a couple kernel versions some time ago, but >>> "impossibly" slow, so it was disabled until such time as btrfs could >>> be made to scale rather better in this regard. > I still contend that the biggest issue WRT reflink-aware defrag was that > it was not optional. The only way to get the old defrag behavior was to > boot a kernel that didn't have reflink-aware defrag support. IOW, > _everyone_ had to deal with the performance issues, not just the people > who wanted to use reflink-aware defrag. Absolutely. Which of course suggests making it optional, with a suitable warning as to the speed implications with lots of snapshots/reflinks, when it does get enabled again (and as David mentions elsewhere, there's apparently some work going into the idea once again, which potentially moves it from the 3-5 year range, at best, back to a 1/2-2-year range, time will tell). >>> 3) N-way-mirroring. >>> >> [...] >> This is not an issue, but a not implemented feature > If you're looking at feature parity with competitors, it's an issue. Exactly my point. Thanks. =:^) >>> 4) (Until relatively recently, and still in terms of scaling) Quotas. >>> >>> Until relatively recently, quotas could arguably be added to the list. >>> They were rewritten multiple times, and until recently, appeared to be >>> effectively eternally broken. >> >> Even tough what you are reporting is correct, I have to point out that >> the quota in BTRFS is more complex than the equivalent one of the other >> FS. Which, arguably, is exactly
Re: unsolvable technical issues?
On Wed, Jun 27, 2018 at 08:50:11PM +0200, waxhead wrote: > Chris Murphy wrote: > > On Thu, Jun 21, 2018 at 5:13 PM, waxhead wrote: > > > According to this: > > > > > > https://stratis-storage.github.io/StratisSoftwareDesign.pdf > > > Page 4 , section 1.2 > > > > > > It claims that BTRFS still have significant technical issues that may > > > never > > > be resolved. > > > Could someone shed some light on exactly what these technical issues might > > > be?! What are BTRFS biggest technical problems? > > > > > > I think it's appropriate to file an issue and ask what they're > > referring to. It very well might be use case specific to Red Hat. > > https://github.com/stratis-storage/stratis-storage.github.io/issues > https://github.com/stratis-storage/stratis-storage.github.io/issues/1 > > Apparently the author have toned down the wording a bit, this confirm that > the claim was without basis and probably based on "popular myth". > The document the PDF links to is not yet updated. It's a company whose profits rely on users choosing it over anything that competes. Adding propaganda to a public document is a natural thing for them to do. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ There's an easy way to tell toy operating systems from real ones. ⣾⠁⢰⠒⠀⣿⡁ Just look at how their shipped fonts display U+1F52B, this makes ⢿⡄⠘⠷⠚⠋⠀ the intended audience obvious. It's also interesting to see OSes ⠈⠳⣄ go back and forth wrt their intended target. -- 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: unsolvable technical issues?
Chris Murphy wrote: On Thu, Jun 21, 2018 at 5:13 PM, waxhead wrote: According to this: https://stratis-storage.github.io/StratisSoftwareDesign.pdf Page 4 , section 1.2 It claims that BTRFS still have significant technical issues that may never be resolved. Could someone shed some light on exactly what these technical issues might be?! What are BTRFS biggest technical problems? I think it's appropriate to file an issue and ask what they're referring to. It very well might be use case specific to Red Hat. https://github.com/stratis-storage/stratis-storage.github.io/issues I also think it's appropriate to crosslink: include URL for the start of this thread in the issue, and the issue URL to this thread. https://github.com/stratis-storage/stratis-storage.github.io/issues/1 Apparently the author have toned down the wording a bit, this confirm that the claim was without basis and probably based on "popular myth". The document the PDF links to is not yet updated. -- 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: unsolvable technical issues?
On Mon, Jun 25, 2018 at 06:43:38PM +0200, waxhead wrote: [snip] > I hope I am not asking for too much (but I know I probably am), but > I suggest that having a small snippet of information on the status > page showing a little bit about what is either currently the > development focus , or what people are known for working at would be > very valuable for users and it may of course work both ways, such as > exciting people or calming them down. ;) > > For example something simple like a "development focus" list... > 2018-Q4: (planned) Renaming the grotesque "RAID" terminology > 2018-Q3: (planned) Magical feature X > 2018-Q2: N-Way mirroring > 2018-Q1: Feature work "RAID"5/6 > > I think it would be good for people living their lives outside as it > would perhaps spark some attention from developers and perhaps even > media as well. I started doing this a couple of years ago, but it turned out to be impossible to keep even vaguely accurate or up to date, without going round and bugging the developers individually on a per-release basis. I don't think it's going to happen. Hugo. -- Hugo Mills | emacs: Emacs Makes A Computer Slow. hugo@... carfax.org.uk | http://carfax.org.uk/ | PGP: E2AB1DE4 | signature.asc Description: Digital signature
Re: unsolvable technical issues?
David Sterba wrote: On Fri, Jun 22, 2018 at 01:13:31AM +0200, waxhead wrote: According to this: https://stratis-storage.github.io/StratisSoftwareDesign.pdf Page 4 , section 1.2 It claims that BTRFS still have significant technical issues that may never be resolved. Could someone shed some light on exactly what these technical issues might be?! What are BTRFS biggest technical problems? The subject you write is 'unsolvable', which I read as 'impossible to solve', eg. on the design level. I'm not aware of such issues. Alright , so I interpret this as there is no showstopper regarding implementation of existing and planned features... If this is about issues that are difficult either to implement or getting right, there are a few known ones. Alright again, and I interpret this as there might be some code that is not flexible enough and changing that might affect working / stable parts of the code so therefore other solutions are looked at which is not that uncommon for software. Apart from not listing the known issues I think I got my questions answered :) and now it is perhaps finally appropriate to file a request at the Stratis bugtracker to ask what specifically they are referring to. If you forget about the "RAID"5/6 like features then the only annoyances that I have with BTRFS so far is... 1. Lack of per subvolume "RAID" levels 2. Lack of not using the deviceid to re-discover and re-add dropped devices And that's about it really... This could quickly turn into 'my faviourite bug/feature' list that can be very long. The most asked for are raid56, and performance of qgroups. Qu Wenruo improved some of the core problems and Jeff is working on the performance problem. So there are people working on that. On the raid56 front, there were some recent updates that fixed some bugs, but the fix for write hole is still missing so we can't raise the status yet. I have some some good news but nobody should get too excited until the code lands. I have prototype for the N-copy raid (where N is 3 or 4). This will provide the underlying infrastructure for the raid5/6 logging mechanism, the rest can be taken from Liu Bo's patchset sent some time ago. In the end the N-copy can be used for data and metadata too, independently and flexibly switched via the balance filters. This will cost one incompatibility bit. I hope I am not asking for too much (but I know I probably am), but I suggest that having a small snippet of information on the status page showing a little bit about what is either currently the development focus , or what people are known for working at would be very valuable for users and it may of course work both ways, such as exciting people or calming them down. ;) For example something simple like a "development focus" list... 2018-Q4: (planned) Renaming the grotesque "RAID" terminology 2018-Q3: (planned) Magical feature X 2018-Q2: N-Way mirroring 2018-Q1: Feature work "RAID"5/6 I think it would be good for people living their lives outside as it would perhaps spark some attention from developers and perhaps even media as well. -- 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: unsolvable technical issues?
On Sat, Jun 23, 2018 at 05:11:52AM +, Duncan wrote: > > According to this: > > > > https://stratis-storage.github.io/StratisSoftwareDesign.pdf Page 4 , > > section 1.2 > > > > It claims that BTRFS still have significant technical issues that may > > never be resolved. > > Could someone shed some light on exactly what these technical issues > > might be?! What are BTRFS biggest technical problems? > > > > If you forget about the "RAID"5/6 like features then the only annoyances > > that I have with BTRFS so far is... > > > > 1. Lack of per subvolume "RAID" levels > > 2. Lack of not using the deviceid to re-discover and re-add dropped > > devices > > > > And that's about it really... > > ... And those both have solutions on the roadmap, with RFC patches > already posted for #2 (tho I'm not sure they use devid) altho > realistically they're likely to take years to appear and be tested to > stability. Meanwhile... > > While as the others have said you really need to go to the author to get > what was referred to, and I agree, I can speculate a bit. While this > *is* speculation, admittedly somewhat uninformed as I don't claim to be a > dev, and I'd actually be interested in what others think so don't be > afraid to tell me I haven't a clue, as long as you say why... based on > several years reading the list now... > > 1) When I see btrfs "technical issue that may never be resolved", the #1 > first thing I think of, that AFAIK there are _definitely_ no plans to > resolve, because it's very deeply woven into the btrfs core by now, is... > > Filesystem UUID Identification. > Btrfs takes the UU bit of Universally > Unique quite literally, assuming they really *are* unique, at least on > that system, and uses them to identify the possibly multiple devices that > may be components of the filesystem, a problem most filesystems don't > have to deal with since they're single-device-only. Because btrfs uses > this supposedly unique ID to ID devices that belong to the filesystem, it > can get *very* mixed up, with results possibly including dataloss, if it > sees devices that don't actually belong to a filesystem with the same UUID > as a mounted filesystem. > > But technologies such as LVM allow cloning devices and these additional > devices naturally have the same filesystem metadata, including filesystem > UUID, as the original. Making the problem worse is udev with its plug-n- > play style detection, which will normally trigger a btrfs device scan, > thus making btrfs aware of new devices containing (a component of) a > btrfs, as soon as udev detects the device. The automatic scanning is partially making it hard and would require either extending the scanning mechanim to distinguish automatic and manual scan, and using that information in kernel. Right now, a cloned device will not be added to the filesystem UUID set if the fs is mounted, but otherwise it's up to the administrator. The misisng bit is possibly a way to tell the kernel module to 'forget' a device (forget and never auto-scan). > 2) Subvolume and (more technically) reflink-aware defrag. There was a discussion in the mailinglist recently, some additions to the interface were requested. The code to avoid the OOM exists but the original author is not apparently interested and noone else has that high enough in the todo list. > 3) N-way-mirroring. I have a prototype code for that, 3-copy and 4-copy type of profile. Doning a fully dynamic N-way would become a messs once thre are mixed N-way chunks for different N. Adding N=5 would not be too hard, but I'm not sure if this makes sense. The raid5 write-hole log will build on top of that, but the code has not been written yet, other than the separate device logging sent by Liu Bo. > 4) (Until relatively recently, and still in terms of scaling) Quotas. That's ongoing WIP, as qgroups touch the core parts. -- 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: unsolvable technical issues?
On Fri, Jun 22, 2018 at 01:13:31AM +0200, waxhead wrote: > According to this: > > https://stratis-storage.github.io/StratisSoftwareDesign.pdf > Page 4 , section 1.2 > > It claims that BTRFS still have significant technical issues that may > never be resolved. > Could someone shed some light on exactly what these technical issues > might be?! What are BTRFS biggest technical problems? The subject you write is 'unsolvable', which I read as 'impossible to solve', eg. on the design level. I'm not aware of such issues. If this is about issues that are difficult either to implement or getting right, there are a few known ones. > If you forget about the "RAID"5/6 like features then the only annoyances > that I have with BTRFS so far is... > > 1. Lack of per subvolume "RAID" levels > 2. Lack of not using the deviceid to re-discover and re-add dropped devices > > And that's about it really... This could quickly turn into 'my faviourite bug/feature' list that can be very long. The most asked for are raid56, and performance of qgroups. Qu Wenruo improved some of the core problems and Jeff is working on the performance problem. So there are people working on that. On the raid56 front, there were some recent updates that fixed some bugs, but the fix for write hole is still missing so we can't raise the status yet. I have some some good news but nobody should get too excited until the code lands. I have prototype for the N-copy raid (where N is 3 or 4). This will provide the underlying infrastructure for the raid5/6 logging mechanism, the rest can be taken from Liu Bo's patchset sent some time ago. In the end the N-copy can be used for data and metadata too, independently and flexibly switched via the balance filters. This will cost one incompatibility bit. -- 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: unsolvable technical issues?
On 2018-06-24 16:22, Goffredo Baroncelli wrote: On 06/23/2018 07:11 AM, Duncan wrote: waxhead posted on Fri, 22 Jun 2018 01:13:31 +0200 as excerpted: According to this: https://stratis-storage.github.io/StratisSoftwareDesign.pdf Page 4 , section 1.2 It claims that BTRFS still have significant technical issues that may never be resolved. Could someone shed some light on exactly what these technical issues might be?! What are BTRFS biggest technical problems? If you forget about the "RAID"5/6 like features then the only annoyances that I have with BTRFS so far is... 1. Lack of per subvolume "RAID" levels 2. Lack of not using the deviceid to re-discover and re-add dropped devices And that's about it really... ... And those both have solutions on the roadmap, with RFC patches already posted for #2 (tho I'm not sure they use devid) altho realistically they're likely to take years to appear and be tested to stability. Meanwhile... While as the others have said you really need to go to the author to get what was referred to, and I agree, I can speculate a bit. While this *is* speculation, admittedly somewhat uninformed as I don't claim to be a dev, and I'd actually be interested in what others think so don't be afraid to tell me I haven't a clue, as long as you say why... based on several years reading the list now... 1) When I see btrfs "technical issue that may never be resolved", the #1 first thing I think of, that AFAIK there are _definitely_ no plans to resolve, because it's very deeply woven into the btrfs core by now, is... Filesystem UUID Identification. Btrfs takes the UU bit of Universally Unique quite literally, assuming they really *are* unique, at least on that system, and uses them to identify the possibly multiple devices that may be components of the filesystem, a problem most filesystems don't have to deal with since they're single-device-only. Because btrfs uses this supposedly unique ID to ID devices that belong to the filesystem, it can get *very* mixed up, with results possibly including dataloss, if it sees devices that don't actually belong to a filesystem with the same UUID as a mounted filesystem. As partial workaround you can disable udev btrfs rules and then do a "btrfs dev scan" manually only for the device which you need. The you can mount the filesystem. Unfortunately you cannot mount two filesystem with the same UUID. However I have to point out that also LVM/dm might have problems if you clone a PV You don't even need `btrfs dev scan` if you just specify the exact set of devices in the mount options. The `device=` mount option tells the kernel to check that device during the mount process. Also, while LVM does have 'issues' with cloned PV's, it fails safe (by refusing to work on VG's that have duplicate PV's), while BTRFS fails very unsafely (by randomly corrupting data). [...] der say 3-5 (or 5-7, or whatever) years. These could arguably include: 2) Subvolume and (more technically) reflink-aware defrag. It was there for a couple kernel versions some time ago, but "impossibly" slow, so it was disabled until such time as btrfs could be made to scale rather better in this regard. Did you try something like that with XFS+DM snapshot ? No you can't, because defrag in XFS cannot traverse snapshot (and I have to suppose that defrag cannot be effective on a dm-snapshot at all).. What I am trying to point out is that even tough btrfs is not the fastest filesystem (and for some workload is VERY slow), when you compare it when few snapshots were presents LVM/dm is a lot slower. IMHO most of the complaint which affect BTRFS, are due to the fact that with BTRFS an user can quite easily exploit a lot of features and their combinations. When a the slowness issue appears when some advance features combinations are used (i.e. multiple disks profile and (a lot of ) snapshots), this is reported as a BTRFS failure. But in fact even LVM/dm is very slow when the snapshot is used. I still contend that the biggest issue WRT reflink-aware defrag was that it was not optional. The only way to get the old defrag behavior was to boot a kernel that didn't have reflink-aware defrag support. IOW, _everyone_ had to deal with the performance issues, not just the people who wanted to use reflink-aware defrag. There's no hint yet as to when that might actually be, if it will _ever_ be, so this can arguably be validly added to the "may never be resolved" list. 3) N-way-mirroring. [...] This is not an issue, but a not implemented feature If you're looking at feature parity with competitors, it's an issue. 4) (Until relatively recently, and still in terms of scaling) Quotas. Until relatively recently, quotas could arguably be added to the list. They were rewritten multiple times, and until recently, appeared to be effectively eternally broken. Even tough what you are reporting is correct, I have to point out that the quota in BTRFS is more
Re: unsolvable technical issues?
On 06/23/2018 07:11 AM, Duncan wrote: > waxhead posted on Fri, 22 Jun 2018 01:13:31 +0200 as excerpted: > >> According to this: >> >> https://stratis-storage.github.io/StratisSoftwareDesign.pdf Page 4 , >> section 1.2 >> >> It claims that BTRFS still have significant technical issues that may >> never be resolved. >> Could someone shed some light on exactly what these technical issues >> might be?! What are BTRFS biggest technical problems? >> >> If you forget about the "RAID"5/6 like features then the only annoyances >> that I have with BTRFS so far is... >> >> 1. Lack of per subvolume "RAID" levels >> 2. Lack of not using the deviceid to re-discover and re-add dropped >> devices >> >> And that's about it really... > > ... And those both have solutions on the roadmap, with RFC patches > already posted for #2 (tho I'm not sure they use devid) altho > realistically they're likely to take years to appear and be tested to > stability. Meanwhile... > > While as the others have said you really need to go to the author to get > what was referred to, and I agree, I can speculate a bit. While this > *is* speculation, admittedly somewhat uninformed as I don't claim to be a > dev, and I'd actually be interested in what others think so don't be > afraid to tell me I haven't a clue, as long as you say why... based on > several years reading the list now... > > 1) When I see btrfs "technical issue that may never be resolved", the #1 > first thing I think of, that AFAIK there are _definitely_ no plans to > resolve, because it's very deeply woven into the btrfs core by now, is... > > Filesystem UUID Identification. Btrfs takes the UU bit of Universally > Unique quite literally, assuming they really *are* unique, at least on > that system, and uses them to identify the possibly multiple devices that > may be components of the filesystem, a problem most filesystems don't > have to deal with since they're single-device-only. Because btrfs uses > this supposedly unique ID to ID devices that belong to the filesystem, it > can get *very* mixed up, with results possibly including dataloss, if it > sees devices that don't actually belong to a filesystem with the same UUID > as a mounted filesystem. As partial workaround you can disable udev btrfs rules and then do a "btrfs dev scan" manually only for the device which you need. The you can mount the filesystem. Unfortunately you cannot mount two filesystem with the same UUID. However I have to point out that also LVM/dm might have problems if you clone a PV [...] der say 3-5 (or 5-7, or whatever) > years. These could arguably include: > > 2) Subvolume and (more technically) reflink-aware defrag. > > It was there for a couple kernel versions some time ago, but "impossibly" > slow, so it was disabled until such time as btrfs could be made to scale > rather better in this regard. Did you try something like that with XFS+DM snapshot ? No you can't, because defrag in XFS cannot traverse snapshot (and I have to suppose that defrag cannot be effective on a dm-snapshot at all).. What I am trying to point out is that even tough btrfs is not the fastest filesystem (and for some workload is VERY slow), when you compare it when few snapshots were presents LVM/dm is a lot slower. IMHO most of the complaint which affect BTRFS, are due to the fact that with BTRFS an user can quite easily exploit a lot of features and their combinations. When a the slowness issue appears when some advance features combinations are used (i.e. multiple disks profile and (a lot of ) snapshots), this is reported as a BTRFS failure. But in fact even LVM/dm is very slow when the snapshot is used. > > There's no hint yet as to when that might actually be, if it will _ever_ > be, so this can arguably be validly added to the "may never be resolved" > list. > > 3) N-way-mirroring. > [...] This is not an issue, but a not implemented feature > > 4) (Until relatively recently, and still in terms of scaling) Quotas. > > Until relatively recently, quotas could arguably be added to the list. > They were rewritten multiple times, and until recently, appeared to be > effectively eternally broken. Even tough what you are reporting is correct, I have to point out that the quota in BTRFS is more complex than the equivalent one of the other FS. In fact it handles (good or bad) quota of gorup of subvolumes. How this concept could be translated in terms of "stratis" [...] > > As for stratis, supposedly they're deliberately taking existing proven in > multi-layer-form technology and simply exposing it in unified form. They > claim this dramatically lessens the required new code and shortens time- > to-stability to something reasonable, in contrast to the about a decade > btrfs has taken already, without yet reaching a full feature set and full > stability. IMO they may well have a point, tho AFAIK they're still new > and immature themselves and (I believe)
Re: unsolvable technical issues?
waxhead wrote: > Jukka Larja wrote: >> waxhead wrote 24.6.2018 klo 1.01: >>> Nikolay Borisov wrote: On 22.06.2018 02:13, waxhead wrote: > According to this: > > https://stratis-storage.github.io/StratisSoftwareDesign.pdf > Page 4 , section 1.2 > > It claims that BTRFS still have significant technical issues that may > never be resolved. > Could someone shed some light on exactly what these technical issues > might be?! What are BTRFS biggest technical problems? That's a question that needs to be directed at the author of the statement. >>> I think not, and here's why: I am asking the BTRFS developers a >>> general question , with some basis as to why I became curious. The >>> question is simply what (if any) are the biggest technical issues in >>> BTRFS because one must expect that if anyone is going to give me a >>> credible answer it must be the people that hack on BTRFS and >>> understand what they are working on and not the stratis guys. It would >>> surprise me if they knew better than the BTRFS devs. >> >> I think the problem with that question is that it is too general. >> Duncan's post already highlights several things that could be a >> significant problem for some user while being non-issue for most. >> Without more specific problem description, best you can hope for is >> speculation on things that Btrfs currently does badly. >> >> -Jukka Larja > > Well, I still don't agree (apparently I am starting to become > difficult). There is a "roadmap" on the BTRFS wiki that describes > features implemented and feature planned for example. Naturally people > are working on improvements to existing features and prep-work for new > features. If some of this work is not moving ahead due to design issues > it sounds likely that someone would know about it by now. This one doesn't seem to be moving ahead, while it seems like a very promising one: Hot data tracking and moving to faster devices (or provided on the generic VFS layer) It would be really fantastic to just add a ssd to a pool of hdd's and have fsync sensitive stuff run normally (dpkg on raid10 with 50 snapshots currently can take hours to do a few minute job) > > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: unsolvable technical issues?
Jukka Larja wrote: waxhead wrote 24.6.2018 klo 1.01: Nikolay Borisov wrote: On 22.06.2018 02:13, waxhead wrote: According to this: https://stratis-storage.github.io/StratisSoftwareDesign.pdf Page 4 , section 1.2 It claims that BTRFS still have significant technical issues that may never be resolved. Could someone shed some light on exactly what these technical issues might be?! What are BTRFS biggest technical problems? That's a question that needs to be directed at the author of the statement. I think not, and here's why: I am asking the BTRFS developers a general question , with some basis as to why I became curious. The question is simply what (if any) are the biggest technical issues in BTRFS because one must expect that if anyone is going to give me a credible answer it must be the people that hack on BTRFS and understand what they are working on and not the stratis guys. It would surprise me if they knew better than the BTRFS devs. I think the problem with that question is that it is too general. Duncan's post already highlights several things that could be a significant problem for some user while being non-issue for most. Without more specific problem description, best you can hope for is speculation on things that Btrfs currently does badly. -Jukka Larja Well, I still don't agree (apparently I am starting to become difficult). There is a "roadmap" on the BTRFS wiki that describes features implemented and feature planned for example. Naturally people are working on improvements to existing features and prep-work for new features. If some of this work is not moving ahead due to design issues it sounds likely that someone would know about it by 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: unsolvable technical issues?
waxhead wrote 24.6.2018 klo 1.01: Nikolay Borisov wrote: On 22.06.2018 02:13, waxhead wrote: According to this: https://stratis-storage.github.io/StratisSoftwareDesign.pdf Page 4 , section 1.2 It claims that BTRFS still have significant technical issues that may never be resolved. Could someone shed some light on exactly what these technical issues might be?! What are BTRFS biggest technical problems? That's a question that needs to be directed at the author of the statement. I think not, and here's why: I am asking the BTRFS developers a general question , with some basis as to why I became curious. The question is simply what (if any) are the biggest technical issues in BTRFS because one must expect that if anyone is going to give me a credible answer it must be the people that hack on BTRFS and understand what they are working on and not the stratis guys. It would surprise me if they knew better than the BTRFS devs. I think the problem with that question is that it is too general. Duncan's post already highlights several things that could be a significant problem for some user while being non-issue for most. Without more specific problem description, best you can hope for is speculation on things that Btrfs currently does badly. -Jukka Larja -- 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: unsolvable technical issues?
Nikolay Borisov wrote: On 22.06.2018 02:13, waxhead wrote: According to this: https://stratis-storage.github.io/StratisSoftwareDesign.pdf Page 4 , section 1.2 It claims that BTRFS still have significant technical issues that may never be resolved. Could someone shed some light on exactly what these technical issues might be?! What are BTRFS biggest technical problems? That's a question that needs to be directed at the author of the statement. I think not, and here's why: I am asking the BTRFS developers a general question , with some basis as to why I became curious. The question is simply what (if any) are the biggest technical issues in BTRFS because one must expect that if anyone is going to give me a credible answer it must be the people that hack on BTRFS and understand what they are working on and not the stratis guys. It would surprise me if they knew better than the BTRFS devs. And yes absolutely, I do understand why one would want to direct that to the author of the statement as this claim is as far as I can tell completely without basis at all, and we all know that extraordinary claims require extraordinary evidence right? I do however feel that I should educate myself a bit on BTRFS to have some sort of basis to work on before confronting the stratis guys and risk ending up as the middle man in a potential email flame war. So again , does BTRFS have any *known* major technical obstacles which the devs are having a hard time solving? (Duncan already gave the best answer so far). PS! I have a tendency to sound a bit aggressive / harsh. I assure you all that it is not my intent. I am simply trying to get some knowledge of a filesystem (that interest me a lot before) trying to validate a "third party" claim. -- 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: unsolvable technical issues?
waxhead posted on Fri, 22 Jun 2018 01:13:31 +0200 as excerpted: > According to this: > > https://stratis-storage.github.io/StratisSoftwareDesign.pdf Page 4 , > section 1.2 > > It claims that BTRFS still have significant technical issues that may > never be resolved. > Could someone shed some light on exactly what these technical issues > might be?! What are BTRFS biggest technical problems? > > If you forget about the "RAID"5/6 like features then the only annoyances > that I have with BTRFS so far is... > > 1. Lack of per subvolume "RAID" levels > 2. Lack of not using the deviceid to re-discover and re-add dropped > devices > > And that's about it really... ... And those both have solutions on the roadmap, with RFC patches already posted for #2 (tho I'm not sure they use devid) altho realistically they're likely to take years to appear and be tested to stability. Meanwhile... While as the others have said you really need to go to the author to get what was referred to, and I agree, I can speculate a bit. While this *is* speculation, admittedly somewhat uninformed as I don't claim to be a dev, and I'd actually be interested in what others think so don't be afraid to tell me I haven't a clue, as long as you say why... based on several years reading the list now... 1) When I see btrfs "technical issue that may never be resolved", the #1 first thing I think of, that AFAIK there are _definitely_ no plans to resolve, because it's very deeply woven into the btrfs core by now, is... Filesystem UUID Identification. Btrfs takes the UU bit of Universally Unique quite literally, assuming they really *are* unique, at least on that system, and uses them to identify the possibly multiple devices that may be components of the filesystem, a problem most filesystems don't have to deal with since they're single-device-only. Because btrfs uses this supposedly unique ID to ID devices that belong to the filesystem, it can get *very* mixed up, with results possibly including dataloss, if it sees devices that don't actually belong to a filesystem with the same UUID as a mounted filesystem. But technologies such as LVM allow cloning devices and these additional devices naturally have the same filesystem metadata, including filesystem UUID, as the original. Making the problem worse is udev with its plug-n- play style detection, which will normally trigger a btrfs device scan, thus making btrfs aware of new devices containing (a component of) a btrfs, as soon as udev detects the device. So people, including users of redhat/fedora which standardizes on lvm and systemd/udev, have to be _very_ careful when cloning devices, etc, with existing mounted btrfs, not to allow btrfs to see the new clones, lest it get mixed up and write data to the wrong device due to it having the same UUID as the mounted filesystem, possibly resulting in data loss. But btrfs made the choice to use UUID as if it were really unique, just as it says it is on the label, many years ago, when btrfs was much younger, and that choice is now embedded so deeply it's not practical to consider changing it to something else (tho there is a utility to allow a suitably careful user to change it on a cloned device, should it be necessary). For someone standardized on a solution such as lvm, that could be considered an unsolvable technical issue indeed, and indeed, I don't believe anyone here will argue that it's going to change. Tho I'd definitely argue the bug is in apps that deliberately make UUIDs non-UUID any longer, no longer unique, not in btrfs, which simply takes the claim on the label at face value. While that's the only truly "unsolvable" one I know of, depending on one's strictness in defining "unsolvable" and the scope of the time frame under consideration, it's quite conceivable (indeed, having read a bit about them before, it seems to be the case, certainly the PR case) that stratis, et. al., have lost patience at the slow pace of btrfs development, and consider various other still missing features as now "practically insolvable as in won't be solved to production ready", at least in a "reasonable" time frame of under say 3-5 (or 5-7, or whatever) years. These could arguably include: 2) Subvolume and (more technically) reflink-aware defrag. It was there for a couple kernel versions some time ago, but "impossibly" slow, so it was disabled until such time as btrfs could be made to scale rather better in this regard. There's no hint yet as to when that might actually be, if it will _ever_ be, so this can arguably be validly added to the "may never be resolved" list. 3) N-way-mirroring. This one was on the roadmap for "right after raid56 support, since it'll use some of that code", since at least 3.5, when raid56 was supposed to be introduced in 3.6. I know because this is the one I've been most looking forward to personally, tho my original reason, aging but still usable devices that
Re: unsolvable technical issues?
On 22.06.2018 02:13, waxhead wrote: > According to this: > > https://stratis-storage.github.io/StratisSoftwareDesign.pdf > Page 4 , section 1.2 > > It claims that BTRFS still have significant technical issues that may > never be resolved. > Could someone shed some light on exactly what these technical issues > might be?! What are BTRFS biggest technical problems? That's a question that needs to be directed at the author of the statement. > > If you forget about the "RAID"5/6 like features then the only annoyances > that I have with BTRFS so far is... > > 1. Lack of per subvolume "RAID" levels > 2. Lack of not using the deviceid to re-discover and re-add dropped devices > > And that's about it really... > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: unsolvable technical issues?
On Thu, Jun 21, 2018 at 5:13 PM, waxhead wrote: > According to this: > > https://stratis-storage.github.io/StratisSoftwareDesign.pdf > Page 4 , section 1.2 > > It claims that BTRFS still have significant technical issues that may never > be resolved. > Could someone shed some light on exactly what these technical issues might > be?! What are BTRFS biggest technical problems? I think it's appropriate to file an issue and ask what they're referring to. It very well might be use case specific to Red Hat. https://github.com/stratis-storage/stratis-storage.github.io/issues I also think it's appropriate to crosslink: include URL for the start of this thread in the issue, and the issue URL to this thread. -- Chris Murphy -- 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
