Vlákno názorů k článku NFS: vzdálený přístup k souborům v linuxovém operačním systému od klokan - Že by NFS byl "nejlepší" se mi rozhodně...
-
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 ...
-
Adam KaliszStříbrný podporovatelV 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".
