PLD systemd i mdadm

Tomasz Pala gotar at polanet.pl
Wed Sep 27 23:05:01 CEST 2017


On Wed, Sep 27, 2017 at 21:33:28 +0200, Jacek Konieczny wrote:

>> BTW nasz mdadm 4.0 nie ma spakowanych ani unitów z upstreamu:
>> 
>> https://git.kernel.org/pub/scm/utils/mdadm/mdadm.git/tree/systemd
>> 
>> ani reguł udeva, żeby składały macierze: udev-md-*.rules
>> https://git.kernel.org/pub/scm/utils/mdadm/mdadm.git/tree/
> 
> A odpowiednie unity nie przychodzą z systemd/udev?

Nie, zgodnie z filozofią systemd, są właśnie w upstreamowych paczkach.
Bo ich autorzy najlepiej wiedzą, jak używać swoich narzędzi.

Gdyby istniała metoda złożenia MD/DM bez tychże narzędzi, to do udeva by
została zaakceptowana (patrz btrfs, można złożyć bez btrfs device scan,
tj. bez btrfs-tools), ale o ile mi wiadomo, to albo kernel samodzielnie,
albo właśnie mdadm jest wymagany.

>> Nie używam mdadma na żadnym współczesnym systemie (z systemd), więc nie
>> mam za bardzo jak tego sprawdzić, ale raczej nie jest dziwne, że nie
>> działa.
> 
> SOA#1

Chodziło mi o to, że - jak przejżeć commitlogi tych unitów oraz reguł z
mdadma, obsługują tam sporo dziwnych corner-case'ów, włączając w to np.
kaskadowe MD, multipath itp. Tymczasem bez reguł udeva nie ma u nas nic,
co ustawi SYSTEMD_READY; systemd nie próbuje nawet montowania urządzeń,
które wg udeva nie są gotowe (w przeciwieństwie do rc.scripts czy choćby
mount -a). Więc jeżeli działa, to czy aby nie masz tego zamontowanego
lub przynajmniej złożonego właśnie z initrd gdzieś? I to tego naszego geninitrd, a
nie dracuta (który w systemach z systemd sam zaciąga systemd). Tak, że systemd
przychodzi na gotowe?

> Znaczy się prawie dobrze??? ale to raczej przez LUKS niż mdadm.

Jeżeli masz maszynę odpowiednią do testów, to namiary na unity podałem:)
Sam nie chcę tego w ciemno zmieniać, bo mdadma na systemd jak już
wspomniałem nie mam, z kolei LUKS-y mam, ale bez żadnego RAID-a, zresztą
składane z initrd.

-- 
Tomasz Pala <gotar at pld-linux.org>


More information about the pld-devel-pl mailing list