Re: unsolvable technical issues?

["Austin S. Hemmelgarn" <ahferroin7@gmail.com>]

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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>