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 <[email protected]> _______________________________________________ pld-devel-pl mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
