Nevím, nějaké benchmarky jsem nikdy nedělal. Často mi přišlo, že na Linuxu je procházení síťových adresářů a svazků sdílených pomocí SMB pomalejší, než ve Windows, až jsem pak zjistil, že Nautilus, resp. GVFS, na to nepoužívá jaderný ovladač CIFS ale jakýsi vlastní bastl, nejspíš založený na FUSE nebo tak.
Hlavní je ale myslím to, že sdílení souborů po síti je samozřejmě důležitá vlastnost, ale všichni všude na to používají SMB/CIFS. NFS je dneska více méně historická záležitost, která se postupně odsouvá do stejné kategorie, jako ještě obskurnější RFS. Proto Linux potřebuje především dokonalou implementaci SMB a jestli ta stávající má nějaké problémy, tak je třeba je řešit.
To urcite, NFS je historicka zalezitost, a proto to jede s RoCE, dava to vyrazne vetsi vykon i vyssi uroven zabezpeceni (v42). Ja zase vsude, kde nebyl SAN nebo clusterovy svazek, a kde slo o penize anebo prave vykon videl jen sdileni bez SMB/CIFS. Nebyly to pochopitelne frikulinske SOHO instalace, cimz se asi lisime... a prirovnavat obskurnost NFS a RFS, to chce opravdu velmi mizive znalosti v teto oblasti.
O nic jste neprisel, Linux svou "vyjimecnost" nezalatal ani s novymi verzemi. Treba jejich moderni instalace na RHELu ma stale problemky s (unikatni) cookie pri mountu, kdy se klientum obcas nepripoji svazek. Ale na to, ze je to Linuxovy bastl to jeste jde...resit potize se SMB a integraci do K5/AD by mi prislo daleko pracnejsi. Pro zacatecniky je myslim v2 i v3 stale super a hlavne bez potizi, treba na doma rozhodne staci.
To vždycky byl takový začarovaný kruh. NFS se na Linuxu nikdy nestalo příliš oblíbené, tudíž se Linux nikdy nezmohl na skutečně kvalitní implementaci, tudíž to málokdo používal, tudíž nikdo neměl motivaci na tom pracovat a tak dokola. Nicméně jsem toho názoru, že v dnešní době je SMB a CIFS určitě perspektivnější standard, než NFS.
Jiste, a prave pro jeho neoblibenost, maly vykon a bezpecnostni nedostatky ho pouzivaji mnohe velke Linuxove clustery na sdilena data a klidne tim do internetu exportuji datove svazky svym vedcum a inzenyrum. Zatimco SMB (ma to skutecne nejaky standard?) je natolik perspektivni, ze se ani jeho nejpokrokovejsi implementace firmou Microsoft zasadne nekryje zadnymi VPN/firewally, protoze vykon, kvalita a pokrokovost SMB odrazi nejeden malware.
U SMB/CIFS je akorat dobre, ze je, coz prinasi nektere moznosti pro heterogenni instalace. Jeho prevaha nad NFS je nanejvys tak pocitova a to u tech, pro ktere je zejmena NFS pouhym blackboxem, o kterem nic krome zkratky nevi.
16. 9. 2019, 10:16 editováno autorem komentáře
Ctete moc README bez prakticke zkusenosti a pak jen bruslite z oblasti do oblasti podle potreby. Sdileni dat uvnitr clusteru pres distribuovany storage je zcela jina oblast, nez kde by se tam pouzival SMB versus NFS. Proc? Protoze treba glusterfs ma v praxi problem s mensimi daty, ktera se meni, takze je dobry hlavne na vetsi write-once data. Sdileni provoznich svazku se dela typicky na NFS, a export z clusteru ven, a to dokonce vcetne dat, zase pres NFS.
@klokan [...] SMB sice koncepčně složitější, než NFS, a řekněme stejně problematické (jenom jinak), ale má tu výhodu, že je rozšířenější a kompatibilní s Windows.
kdyz uz se tvaris ze tomu rozumis, alespon si dopln znalosti nez napises nesmysl ;-)
Windows 10 Pro maji nativniho NFS klienta, staci pouze v "Zapnout nebo vypnout funkce systému Windows" zaskrtnout "Sluzby pro system souboru NFS", nasledne pak:
# pripojis NFS sdileni
mount \\nfsserver\tvoje\sdileni n:
# odpojis NFS sdileni
umount n:
Windows 10 Server maji i nativni NFS server...
predchozi (nektere) Windows (od WinNT) meli moznost podpory NFS pres Microsofti balik:
https://en.wikipedia.org/wiki/Windows_Services_for_UNIX
To je ale podpora pro opravdu první připojení /, ne? Pokud mám initramdisk, tak můžu Sambu mountnout z něj a chrootnout se do něj (stejně jako to funguje pro libovolný jiný FS). Napadá vás use-case kdy člověk potřebuje aby tohle uměl přímo kernel a nemůže mít initramdisk?
obecne z initramfs sambu pripojit samozrejme davno lze, je potreba pouze:
- pridat smb jadernej modul
- pridat do initrd skriptu detekci parametru smbroot
- pridat do initrd skriptu mountuni smb kdyz najde smbroot parametr
nasledne uz by (*1) initrd pokracoval jak je zvyklej...
*1) problem kterej ale je, je pri pouziti takto pripojeneho smb sdileni jako korenovy adresar systemu,
tedy predpokladam ze pripravovane patche do jadra budou resit prave to, aby se opravneni/vlastnici atd co bezne koren pozaduje cetli/ukladali treba do /smb_rootfs_linux ...
jinak pred casem sem z nejakeho duvodu potreboval diskless pxe boot GNU/Linuxu ale z smb sdileni a jak popisuju vejs sem si initrd upravil, akorat ze neslo o regulerni rootfs, ale o live, tzn, z samba sdileni se primontoval jeste filesystem.squashfs(readonly), pridala se prekryvna vrstva aufs(readwrite) a to se teprve pozuilo jako rootfs...
Ono je to dokonce tak, že i initramfs může být přímo součástí jádra, tedy součástí souboru vmlinuz.
Takže všude kde můžu nabootovat jádro (z disku, po síti přes pxe, atd) můžu i namountovat sambu přes userspace skrz initramfs. Takže to bude fungovat i tam kde by třeba nefungovalo nahrávání externího initramfs z extra dalšího souboru. Nechápu teda vůbec smysl téhle iniciativy.
Pokud to správně chápu, tak kernel (vmlinux) je ELF binárka, a ta může mít sekce.
Initramfs v jádru je uložený v sekci .init.ramfs. Pokud je možné tuhle sekci editovat, tak to půjde. Otázka je čím a jak.
Navíc je rozdíl mezi vmlinux a vmlinuz, skript z následujícího URL umí vypakovat ELF binárku (vmlinux) ze souboru vmlinuz:
https://raw.githubusercontent.com/torvalds/linux/master/scripts/extract-vmlinux
Jak tu ELF sekci ale editovat, to nevím (možná HT editor?) a jak to zapakovat zpátky do vmlinuz to už jsem taky nehledal.
Koukněte na http://www.tldp.org/HOWTO/Bootdisk-HOWTO/x703.html
Je to postup kdysi dávno používaný pro boot diskety. A řekl bych, že bude pořád funkční..
Pro embedded zařízení (nějaký menší ARM s u-boot) se initramdisk obvykle nepoužívá, protože není důvod, kernel se kompiluje na míru pro dané zařízení. S přípravou initrd je další práce, a distribuce jako yocto nebo ptxdist na to nejsou úplně zařízené. Nic co by nešlo řešit, ale možnost nabootovat totožný image jako produkční s rootfs na síti se hodí. Třeba pro testování nebo automatickou instalaci.
Máme třeba produkt, kde je recovery reinstall možný přes TFTP, a pak je nejsnazší nabootovat do standardního standardní image na NFS. Díky této novince lze stejný postup použít i v případě, kdy mám po ruce jen CIFS - a Windows uživatelů je většina. Šlo by to řešit malým rootfs image co by se stahoval taky přes TFTP, ale to je zas nějaká práce a údržba navíc.