Nejlepší samozřejmě záleží na typu aplikace. Jeden z mnoha problémů s NFS konkrétně na Linuxu je to, že pokud vím, NFS služba nemá API: není možné programově říct "sdílej tenhle adresář", všechno vyžaduje ruční editaci textových konfiguráků. Takže není možné mít v Nautilu, Dolphinu atd. tlačítko "Sdílet pomocí NFS". Windows tohle umí, Linux to umí s WebDav a do jisté míry s SMB, s NFS pokud vím se nedá svítit.
A pseudořešit race conditions pomocí lock souborů protože pořádně zamykání souborů Linux stále doopravdy nemá, a řešit bezpečnost aby tam nemohl každý napsat jakoukoli blbost, a řešit situaci, kdy to někdo edituje ručně a pak se v tom parser nevyzná, a... a... a...
Neboli jak z něčeho co by mělo být z programátorského hlediska triviální udělat záležitost na stovky LoC, která možná bude více méně fungovat ale někdy ne...
V moderním OS by prostě mělo jít udělat něco ve stylu:
share_folder(PROTO_NFS | PROTO_SMB, MODE_RO, "/home/foo/bar");
Přičemž share_folder by měl být ten přímý způsob, jak ovládat sdílení souborů, ne rutina, která implementuje parser a...
13. 4. 2022, 09:03 editováno autorem komentáře
1. nfsservctl byl syscall
2. nfsservctl už není
https://man7.org/linux/man-pages/man2/nfsservctl.2.html
Trochu mimo tema: Ja jsem hodne rad za to, ze linux nema zamykani souboru. To je moje nocni mura z Windows, kdy jsem nemohl neco udelat se souborem, protoze ho mel zamknuty nejaky nefunkcni proces. Typicky officy. Vetsinou to koncilo restartem, protoze jsem nevedel jak zjistit ktery proces to je, nebo proste Windowsy nedokazaly ty zamrzle programy doopravdy ukoncit.
Kdyz chci soubor smazat, tak chci aby to OS udelal i kdyz nejaky jiny program ho pouziva. Pokud si tim neco pokazim, je to holt moje chyba.
Ale to je problém v implementaci. Správně by bylo, že pokud je proces zamrzlý, tak se automaticky uvolní zámky na soubory, které drží. Samozřejmě musí být možné takový proces taky spolehlivě zabít. V mazání souborů by zamykání nemělo bránit (soubor se jenom odstraní z adresáře, doopravdy ke smazání dojde teprve když už na něj není žádný fd/handle).
Kdyz chci soubor smazat, tak chci aby to OS udelal i kdyz nejaky jiny program ho pouziva.
Nevím jestli ještě pořád, ale NFS zrovna tohle řešíval svérázně - soubor zůstal, ale přejmenoval se na .nfs000XXX dokud onen "jiný program" žil. A v některých případech (pád systému, možná jen sítě?...) se pak ten soubor nesmazal nikdy.
Ad: "Kdyz chci soubor smazat, tak chci aby to OS udelal i kdyz nejaky jiny program ho pouziva."
V Linuxu to funguje takhle (https://man7.org/linux/man-pages/man2/unlink.2.html): "If the name was the last link to a file but any processes still have the file open, the file will remain in existence until the last file descriptor referring to it is closed."
Linuxový unlink vyhovuje POSIX.1-2008, takže tohle chování lze očekávat na víceméně všech Unixech.
Ad: "soubor zůstal, ale přejmenoval se na .nfs000XXX dokud onen "jiný program" žil."
Základní idea při návrhu NFS byla, že se se soubory na NFS bude pracovat jako se soubory lokálními. Výše popsané chování se očekává (viz popis ulink). Lze diskutovat, zda to jméno má být jiné atd., ale rozhodně to není chybné chování.
RFC 5661 (NFSv4.1) uvádí:
Open files can be preserved if removed and the hard link count ("hard link" is defined in an Open Group [6] standard) goes to zero, thus obviating the need for clients to rename deleted files to partially hidden names -- colloquially called "silly rename"(see the new OPEN4_RESULT_PRESERVE_UNLINKED reply flag in Section 18.16).
OPEN4_RESULT_PRESERVE_UNLINKED indicates that the server will preserve the open file if the client (or any other client) removes the file as long as it is open. Furthermore, the server promises to preserve the file through the grace period after server restart, thereby giving the client the opportunity to reclaim its open.
The use of the OPEN4_RESULT_PRESERVE_UNLINKED result flag allows a client to avoid the common implementation practice of renaming an open file to ".nfs<unique value>" after it removes the file. After the server returns OPEN4_RESULT_PRESERVE_UNLINKED, if a client sends a REMOVE operation that would reduce the file's link count to zero, the server SHOULD report a value of zero for the numlinks attribute on the file.
Ve Windows může admin poměrně snadno zjistit, který proces má soubor otevřený. Pak je možné sestřelit buď ten handle, nebo ten proces, který ho drží. S handles umí pracovat například utilita handle.exe z kolekce Sysinternals, nebo GUI aplikace Process Explorer.
https://docs.microsoft.com/en-us/sysinternals/downloads/handle
https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer
Lael Ophir: Ano, zjistit to jde, a slo. Jenze v dobach W95 az XP bylo celkem tezke tyhle informace najit, obzvlast pro bezneho uzivatele. Protoze mikrosoft z jakehosi duvodu zadne takove informace moc poradne se systemem nedodaval, a pokud, tak bylo tezke je pro bezneho uzivatele najit. Zato problemy se zamknutym souborem meli i bezni uzivatele, nejen adminove kteri prosli skolenim.
Lael Ophir
Ve Windows může admin poměrně snadno zjistit, který proces má soubor otevřený
a v Linuxu snadneji, nastroj lsof je uz predintalovan, u otevrenych ale smazanych zobrazi (delete), a lze pripadne i smazane ale drzene obnovit vykopirovanim z /proc/cislo_procesu/fd/X ...
V době perzistentních datových struktur apod. by podpora atomických operací i bez uživatelsky pociťovaných zámků mohla být relativně přímočará. Hodně věcí v IT se za posledních 20 let posunulo a to i v oblasti datových struktur. Není důvod, aby správa a provoz komplikovaných systémů bylo takové peklo, jaké to je.
Elementární nepochopení problematiky potom vede k tomu, že se tvoří systémy jako Kubernetes, aby se problémy, které se měly vyřešit na nízkých úrovních řešily globálně - tam, kde to většina lidí a ani firem typicky nepotřebuje a pokud ano, lepší základ by výrazně ulehčil práci.
NFS v4 priniesla podporu kerbera - viď napríklad https://wiki.debian.org/NFS/Kerberos (na šifrovanie kompletného trafficu je nutné zapnúť krb5p).
Ah máte pravdu. Opravdu by to chtělo nějakou osvětu ohledně nfs4.x (a nejen pro mě), na internetu se dají najít různé hacky jak obejít chybějící šifrování na nfs4 přes stunnel a tak.
Co se týká té češtiny (a jiných jazyků), windows bohužel dlouhou dobu nepodporovaly utf8 u nfs, takže se to muselo všelijak hackovat. Jaká je situace dnes nevím, myslím, že to už jde nastavit nějak přes regustry nevo gpo.
Tak nfs 4.2 uz je docela slusny. Na druhou stranu implementace nfs - zejmena 4.x je stale tercem posmechu. V linuxu tragicky. Chcete-li slusnejsi nfs nainstalujte si solaris. A to rikam jako byvaly prisluhovac firmy ktera ho vymyslela a junior otrok netapp supportu.
13. 4. 2022, 14:36 editováno autorem komentáře
Pridam priklad z praxe. Voleni open() na NFSv4 over TCP je blokujici.
Tzn. vsechny procesy/vlakna pracujici s NFS musi cekat nekolik ms dokud NFS server nevrati id handle otevreneho souboru.
Pokud pracujete s vetsim mnozstvim soboru na NFS tak se latence site projevi a procesy se navzajem blokuji v kernelu na pristupu k TCP socketu k NFS serveru.
Problem resi tenhle patch:
https://patchwork.kernel.org/project/linux-nfs/patch/1422077968-116473-6-git-send-email-trond.myklebust@primarydata.com/
Projevuje se to na RHEL7, na RHEL8 uz je to vyresene (pouziva se open_parallel() na urovni NFS 4.1 protokolu). Problem je v tom, ze RHEL7 i RHEL8 se oba tvari jako ze oba implementuji NFS 4.1, ale ve skutecnosti se kazdy chova trochu jinak.
Problém je v tom, že specifikace NFSv4 používá hodně slovo "může". Třeba to paralelní otevírání je v RFC 5661 popsáno takto:
"Unlike the case of NFSv4.0, in which OPEN operations for the same open-owner are inherently serialized because of the owner-based seqid, multiple OPENs for the same open-owner may be done in parallel."
Záleží na programátorovi, jestli tu vlastnost implementuje. Tohle je i důvod, proč je těžké napsat o NFS článek, který jde do hloubky. Člověk musí mít přehled o tom, jak je ten protokol implementován. A to mívají jen lidé, kteří s tím kódem aktivně pracují. Pár článků o implementaci NFSv4 bylo publikováno (https://www.kernel.org/doc/ols/2001/nfsv4_ols.pdf), teď už jsou ty články zastaralé.
Podobný problém je tam s ACL: "The NFSv4.1 ACL model is quite rich. Some server platforms may provide access-control functionality that goes beyond the UNIX-style mode attribute, but that is not as rich as the NFS ACL model."
Na tvorbě toho RFC se podílel i Microsoft, který má vlastní serverovou implementaci NFSv4.1 (https://docs.microsoft.com/en-us/windows-server/storage/nfs/nfs-overview). To RFC muselo vyhovět všem, a proto obsahuje tolik slov "může".
NFS over UDP je deprecated... a na rychlejch linkach to muze i rozbijet data.
Podivame se na protokol NFS, ale clanek je velmi strohy a jen ukazuje, jak nastavit server a client side...
Chybi mi zde moznosti NFS pro definovani sharu, protoze ty jsou napr. pro vykon NFS naprosto zasadni, zvlast pokud server podporuje vice verzi NFS (v2, v3, v4), maji zasadni vliv i na rychlost (kdyz napr. udela clovek lokalne backup velke DB, rekneme 2 TB a tento dump pak chce sdilet do zalozniho DC pro off-site recovery apod.), v neposledni rade pokud je NFS share poskytovan napric ruznymi OS (napr. AIX, Red Hat, Ubuntu, apod.)...
Docela zklamani ten clanek... :/
Ano, autor se na NFS podíval, bohužel pouze z rychlíku, a tak ani netuší co všechno o NFS netuší. Také jsem doufal, že si konečně utřídím své chaotické informace a představy o správném nastavení NFS, případně se podělím o zkušenosti které mne překvapily a nedovedu si je vysvětlit a dozvím se "wo co go". No nic ...
Jenže ten článek bohužel žádný "vhled" nenabízí, je to manuál copy/paste, kde se nic moc nevysvětluje, takže to člověk zrovna nepochopí, jen tupě něco odkliká. Takových manuálů je na internetu miliarda a jsou mor a zhouba, protože vedou k tomu, že si lidé myslí, že tohle stačí a provozují potom naprosto proprasené servery různě samo domo. Komu to nakonec pomůže?
je to sice ok, ze autor a redakce dostali nyni ten 'feedback', jak my vypadat ten 'spravny' clanek, ale presto se ptam, proc uz tady nebyl uverejnen takovy clanek od tech, kteri to vedi lepsi?
To je ode me samozrejme recnicka otazka, neb si myslim, ze NFS problematika je silne komplikovane tema a i kdyz jsem se za poslednich 30 let s NFS musel mnohokrat zabyvat, tak bych si na takovy clanek netroufl.
NFS se jako protokol dost pohnulo dopredu. Akorat malokdo tusi jake jsou rozdily mezi 4.0, 4.1, 4.2 a jak je na tom kdo s implementaci. A tooly k tomu moc nejsou.
Jako ze ruzna Linuxova jadra se muzou chovat ruzne a informace se tezko dohledavaji.
PS: v clanku chybi zminka o rpcinfo, bez vypisu z tohodle programu se neda poradne nastavit FW, a napr. zamykani souboru by nefungovalo.
Chjo. Tak dlouho mne bude svrbet klavesnice az neco napisu. U vetsiny rozumnych implementaci se da zmenit rozsah portu(v2-v3) a nebo nastavit specificky porty(v4).
V linuxu je NFS tragedie, pouze zaklad stacici na nejake bezne popotahovani souboru. Ani ACLka to slusne neumi.
Na hiperf stejne nasadite pNFS.
Doplním, že NFS je detailně popsán zde:
- Network File System (NFS) Version 4 Minor Version 1 Protocol, https://datatracker.ietf.org/doc/html/rfc5661
- Network File System (NFS) Version 4 Minor Version 2 Protocol, https://datatracker.ietf.org/doc/html/rfc7862
Současné linuxové distribuce obsahují NFS 4.2, ne? OpenSUSE Leap 15.3 to má uvedené v dokumentaci.
Teď vidím, že je to složitější. Leap 15.3 obsahuje i NFS-Ganesha file server, který podporuje nejvýš NFS 4.1.
V Unix Hater Handbooku věnovali NFS celou kapitolu, doufal jsem že si budu moct po přečtení článku odškrtnout které vlastnosti jsou za těch třicet let jinak :), ale ten detail tam nebyl, a vlastně ani nevidím jestli navrhovaná konfigurace serveru nabízí jen verzi 4 nebo i starší. Tak snad se poučím někdy jindy.
Co sshfs? me tak nejak priapda (zvlaste spolu s mount bind) zcela nejuniverzalnejsi.
V rpi 4x usb disk. Decka a zena se pripojuji jako user co tma muze jen cist. Ja se tam pripojuju jako user co ma rw. A secure NAS je na svete :D Cele se to konfigurovalo asi 10 minut, bezi to uz nekolik let.. . Kazdy ten disk ma v supliku navic duplikat... I
U toho jsem skončil taky, nakonec pro nějaké to domácí NASování není potřeba víc. V některých DE ani ten mount-sshfs nepotřebujete, protože např. Gio to nějak dostane do filesystemu přes FUSE, takže i ne-GNOME aplikace můžou číst/psát/přehrávat soubory rovnou ze sítě.
Nejlepší je že se nic nenastavuje, nic neinstaluje. Stačí mít správně nastaveny vlastníky adresářů a přístupová práva a je to.