[systemd-devel] timed out waiting for device dev-disk-by\x2duuid

Goffredo Baroncelli kreijack at libero.it
Thu May 15 13:57:13 PDT 2014


On 05/15/2014 08:16 PM, Lennart Poettering wrote:
> On Thu, 15.05.14 19:29, Lennart Poettering (lennart at poettering.net) wrote:
> 
>> On Mon, 12.05.14 20:48, Chris Murphy (lists at colorremedies.com) wrote:
>>
[...]
> 
> So, as it turns out there's no kernel APi available to check whether a
> btrfs raid array is now complete enough for degraded mode to
> succeed. There's only a way to check whether it is fully complete.
> 
> And even if we had an API for this, how would this even work at all? 

In what this should be different than the normal RAID system ? 

In both case there are two timeout: the first one is for waiting the full system, the second one is for the minimal set of disks to a degraded mode. If even the second timeout is passed, then we should consider the filesystem not build-able.

How it is handle for the RAID system ? Knowing that we should consider to apply the same strategies fro btrfs (may be we need some userspace tool to do that)






> mean, just having a catchall switch to boot in degraded mode is really
> dangerous if people have more than one array and we might end up
> mounting an fs in degraded mode that actually is fully available if we
> just waited 50ms longer...
> 
> I mean this is even the problem with just one array: if you have
> redundancy of 3 disks, when do you start mounting the thing when
> degraded mode is requested on the kernel command line? as soon as
> degrdaded mounting is possible (thus fucking up possible all 3 disks
> that happened to show up last), or later?
> 
> I have no idea how this all should work really, it's a giant mess. There
> probably needs to be some btrfs userspace daemon thing that watches
> btrfs arrays and does some magic if they timeout.
> 
> But for now I am pretty sure we should just leave everything in fully
> manual mode, that's the safest thing to do...
> 
> Lennart
> 


-- 
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5


More information about the systemd-devel mailing list