Robusztus hálózati fájlrendszert keresek

Halihó!

Írtam már korábban, hogy van egy NAS-om, és szenvedek vele. Ez egy dLink eszköz, van benne egy darab 6T WD Red, és NFS-en keresztül mountolom a fájlrendszert fel Linux alól. Az asszony is használja Mac OS alól időnként (nem tudom, hogy Mac NFS-t vagy Sambát használ-e). A gond az, hogy néha valami (valószínűleg írás) történik, és ilyenkor lelassul _valami_, ami hatására a Linux eszméletlenül lelassul.

Próbáltam mindenfélét, a NAS nem mutat semmi hibát, NAS-on kívül a hdd hiba nélkül működik, lementettem róla mindent majd visszamásoltam (mert valaki töredezettségre gyanakodott). Nem javult meg.

Nincs több ötletem, a dLink NAS helyett építek magamnak valami alacsony fogyasztású hardverből egy saját NAS-t. Viszont az NFS helyett szeretnék valami robosztusabb fájlrendszert. Ha tudtok ilyen rendszert, ajánljatok, légyszi!

Kb ezeket szeretném:

  • lehessen felmountolni Linux, Mac, Windows alól (nem baj, ha Linux számára van valami és Win (és Mac) számára valami más).
  • támogassa a Linux fájlrendszerek alatt megszokott dolgokat. Jogosultságok, soft és hardlink, megkülönböztetett kis- és nagybetű, stb.
  • ha fel van mountolva Linux alatt és a NAS eltűnik, lehessen umountolni különösebb nehézség nélkül (ez NFS alatt nem szokott működni).
  • ha fel van mountolva Linux alatt, a NAS eltűnik (hálózati hiba, áramszünet), aztán egy idő után újra megjelenik, menjen minden tovább (ez NFS alatt jellemzően működik)
  • ha fel van mountolva Linux alatt, és a NAS nem válaszol, vagy nagyon lassan válaszol, akkor vagy legyen valami timeout, ami után mondja azt, hogy automatikusan read-only remount lett, vagy umount lett, vagy ilyesmi, vagy ha nem automatikusan mondja ezt, hanem csak próbálkozik, akkor engedje nekem azt, hogy azt mondjam, hogy akkor most umount, és zárjon le mindent. (ez NFS alatt katasztrofális)
  • Nem árt, ha van valami authentikáció mountoláskor, hogy ne tudja akárki felmountolni az itthoni hálózatról, de nem esek kétségbe, ha nincs.
  • Nem kell feltétlenül megoldani, hogy Windows-ból felmásolt fájlok és Linuxból felmásolt fájlok azonos owner/group id-val legyenek létrehozva. De ha van erre valami megoldás, az jó.
  • root felhasználóval lehessen a távoli fájlrendszeren ownert és groupot változtatni
  • Nem árt, ha különböző felhasználóval és jelszóval különböző exportokhoz fér hozzá a mount
  • Ha jelszót használunk, az közlekedjék titkosítva a hálózaton
  • Nem árt, ha a hálózati forgalom titkosított bár alapvetően megbízom a hálózatra kapcsolódó gépekben, és nem szeretnék emiatt mondjuk lassabb hálózati sebességet, nagyobb gépigényt, extrán dolgozó processzort, magasabb fogyasztást, NAS-ban pörgő ventilátort. Esetleg valami hw támogatott titkosítást vagy valami egyszerű és kis gépigényű scramble-t el tudok képzelni. Nem az a lényeg, hogy a CIA ne tudja visszafejteni

Hozzászólások

Na keverd a filerendszer es a halozati megosztas modjat. Esetedben az utobbi erdekes.

Sajnos nem igazan van minden szempontbol tokeletes megosztas, de talan a Samba/CIFS van hozza a legkozelebb.

Na keverd a filerendszer es a halozati megosztas modjat

Igaz, csak mivel ugye az NFS fájlrendszernek hívja magát, maradtam ennél. De igen, valami fájlrendszer van/lesz a harddiszken, és egy hálózati megosztási módot keresek (ami a végén fájlrendszerként látszik a kliensen).

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

meglattam a topic cimet, na mondom valami izgalmas, hatha hozza tudok szolni... erre otthoni NAS szintrol van szo :(

https://wiki.startlap.hu/hogyan-irjuk-helyesen-robusztus-vagy-robosztus/

Persze, de attól függ, hogy miről van szó. Mert ha a robusztusságra gondolunk, akkor az helyesen robusztusnak kell írni.  Ezzel szemben a robosztus helyes írása: robosztus.

Lógok a szeren (K. Frigyes)

Lógok az ereszen (Sz. József)

Ha lemondasz a titkosításról, akkor Samba/CIFS, különben SSHFS.

Előbbit támogatja a Windows (naná), utóbbihoz 3rd cucc kell, de van belőle ingyenes.

( •̀ᴗ•́)╭∩╮

"speciel a blockchain igenis hogy jó megoldás, ezért nagy erőkkel keressük hozzá a problémát"

"A picsat, az internet a porno es a macskas kepek tarolorandszere! : HJ"

Meg a multiuserségről is le kell mondani (aka system-level mount).

Nem tudom, hogy ez most hol tart: https://wiki.samba.org/index.php/LinuxCIFS_Multisession_Mount

De az alul levő protokoll nem támogatja azt, amit az NFS igen, hogy a kliens gép mondja meg a fájl szervernek, hogy az adott műveletet melyik felhasználó nevében kell végrehajtani. Tehát vagy felhasználónként mountolsz, vagy nem használsz több felhasználót a fájl szerveren...

nincsenek csodák a diszk az diszk főleg a SATA meg NL SAS eszközöktől nem kell a megváltást várni

ha nincs raid1 vagy raid 10 + ssd cache akkor sajna ez lassú de itt csak a cache méretéig lesz gyors az írás

SATA diszk csak backup vagy kecske pornó mást nem bíznék rá
 

javaslom sas diszkes megoldást lehet használtan kapni őket 5-6 darab raid6-ba és az adatok se vesznek el és elég gyors is lesz

igen van igazság amit írsz de sok diszkkel is lehet nagy iops-t csinálni és megfelelő átvitelt

diszk és diszk között óriási különbségek vannak nem csak abban hogy milyen gyorsan pörög

pld egy 3par diszkes storage nem sokkal gyengébb mint egy olcsó lenovo ssd stroage és Nimble all flash-e megalázza a lenovo ssd storage-t

tehát nem csak a tárolók sebességén, hanem az azt kiszolgáló környezet megoldásain is múlink a user experience

 

itt egy házi megoldásról beszélünk nem lehet sok x10 milliót költeni

gondolom neked is egy Nimble HF60-as kandikál ki a zoknik közül csak úgy hobby-ból

 

én ha javasolhatok egy centos + raid6 (6 db sas 300/600Gb disk) + vdo + lvm + CIFS/NFS kombót nem túl combos hardveren itt a probléma a hűtés és a zaj lehet amit valahogy meg kell oldani

vagy

nem otthon tárolni srv-t csak akkor meg isp sebessége a probléma bár én sem otthon tárolom az adatokat és csak egy 500/25-ös kapcsolatom van de nekem nem gáz a sebesség

Már bocs, de homeuser/penztarca szerint is beszélgetnétek? :) Mert a fenti eset ez :)

Nem az hogy kinek nagyobb a pöcse/SSDje/stb... :/ És leírjátok a HDD-s storage-okat a francba, hogy há de már 2020 van.. és ? a HDD storage megszünt ? Megszünt az IBMnél is NagyZ ? nem árulnak már ilyesmit, nem supportálnak már ilyesmit ? Mer sz.r lassú geci .....

Vah... Ez egy homeNAS baszki.. ne kavarjatok már ennyire 

Na de ez pont egy backup, amiről szó van. Lópornó ugyan még nincs rajta, de vannak rajzfilmek a gyerekeknek, meg filmsorozatok a felnőtteknek, meg FLAC-ban a legtöbb CD-mről a zene, meg régi gépekről mentések meg ilyesmik.

Egyáltalán nincs szükség arra, hogy gyors legyen.

És egyébként a szűk keresztmetszet nem a hdd, hanem az, hogy a NAS-nak csak 100 megabites az ethernet csatlakozója, míg a routernek és a laptopnak meg gigabites, és így ha mondjuk másolok a NAS-ról, akkor a hálózat által korlátozottan, kb. 90 megabittel jön az adat.

Köpjetek le, ha nem tudjátok megállni, de nekem elég a 90 megabit. Főleg úgy, hogy a legnagyobb tipikus igénybevétel az az, amikor valami mesét kell lejátszani, és a 90 megabitnek is csak a töredékét használjuk.

Dolgozáshoz a laptopban van ssd, és igen, ez tényleg egy jó csere volt.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Na de ez pont egy backup, amiről szó van

 

Ezesetben ezt fejtsd ki jobban:

"hogy néha valami (valószínűleg írás) történik, és ilyenkor lelassul _valami_, ami hatására a Linux eszméletlenül lelassul."

 

A Linux, ami rajta van a NAS-on, vagy egy Linux-os kliens ami használja (felmountolja?) a NAS-t?

és pontosan miben nyilvánul meg hogy lassú?

- akad a filmnézés róla?

- a kliensek számára lelassul a file olvasás? vagy az írás ?

- vagy konzolon (SSH-n) belépve 'lassú' maga a NAS?

- és csak időleges ez a lassulás? ha igen mennyi időre lassul be?

- a lassulás tünet közben mekkora LAN forgalmat lehet mérni a NAS interface-en?

A kliensnek használt Linux, amire fel van mountolva NFS-en át a fájlrendszer, erősen belassul ilyenkor.

A Mac nem tudja felmountolni a filmeket tartalmazó megosztást, timeout lesz.

A Linux, amin már fel van mountolva, bármit próbál, írni, olvasni, az lassú.

ssh-n nem tudok belépni, nem fogadja el a jelszót. webes GUI-n belépve nem lassú, és az ott megjelenő grafikon szerint a processzor és a memória nincs koppra kihasználva.

Időleges? Hát... végülis igen. Ha minden befejezi a futást, ami épp fut, akkor utána megint jó sebességgel mennek  a dolgok egy ideig.

Pl. valamikor hétfő körül lassult be. Futott egy torrent, ami csak seedelt, nem írt semmit. Elindult egy mlocate, ami megint csak olvas, nem ír. Korábban voltak írások. Amikor ránéztem, kb. ezek futottak. A torrent kliens le volt lassulva annyira, hogy nem rajzolta újra a GUI-t. Az mlocate-nek küldtem egy SIGTERM-et, az kilépett. A torrent is idővel, már nem emlékszem, hogyan, talán az is kill-lel. Indítottam egy sync-et, az futott kb. másfél napig. Próbáltam umountolni, ez pár perc várakozás után mindig azzal jött vissza, hogy busy. Próbáltam egy fuser /mnt/nas-t, hogy lássam, mi miatt busy, de ez is órákon át futott, és végül nem adott semmi eredményt. Közben minden más lassú volt. Böngésző, libreoffice, ls, stb. Memóriát erősen használta, úgy tűnt, jobban, mint szokásos.

Aztán ma reggelre végzett a sync, végzett a fuser, nem volt már több processz D-ben. Umount még mindig nem ment. Kilépve a KDE-ből, konzolról ment az umount.

Újra mountoltam, most épp minden jónak tűnik és nem lassú.

LAN forgalom közelíti a 0-t. A normális esetben max. 90 megabithez képest elenyésző.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Ezek alapján az NFS miatt lassul be az egész, az csinál ilyen tüneteket.

Hogy a kliens okozza vagy maga a NAS csinál valamit rosszul azt nem tudom, de NFS nyűgökön kb csak a reboot segít, így én csak ott használom ahol nincs jobb lehetőség.

Én egyébként a Linuxos klienseken is SAMBA/CIFS-en mountolom a NAS-ról a megosztásokat, ez univerzális, és majdnem teljesen OS független. Eddig minden kliens (android, Linux, Mac, Win7 Win10) boldog volt ezzel.

és így a NAS-on nem is kell NFS-csak egy samba share....

 

tudom ez nem megoldás, csak workaround. - De ennél jobbat otthoni környezetben tudok.

egyébként a szűk keresztmetszet nem a hdd, hanem az, hogy a NAS-nak csak 100 megabites az ethernet csatlakozója

vs

Köpjetek le, ha nem tudjátok megállni, de nekem elég a 90 megabit. Főleg úgy, hogy a legnagyobb tipikus igénybevétel az az, amikor valami mesét kell lejátszani, és a 90 megabitnek is csak a töredékét használjuk

Most akkor tulajdonkeppen mivel is van baj? :D

Kozben irtal szoval a sommas velemenyem:

Vegyel egy normalis NAS-t es raid-ben SMB megosztast hasznalj. Nalam a NAS egy microserver es SMB-n eri el az iMac    a windows, android, ios es az Apple TV.

???

Már bocsánat, de szerintem azért a HDD még mindig olcsóbb az SSD-nél Ft/TB-ban mérve. Nem rendszerlemezről beszélünk, ahova én sem tennék mást.

Az igények pedig mindig nőnek, én most akarom a 2x4 TB-ot lecserélni 2x8 - 2x10 köré.

Videóval végtelen mennyiségű helyet meg lehet tölteni, és semmi nem indokolja, hogy SSD-n legyen. Ebben az esetben a HDD a több száz DVD-t meg VHS kazettát váltja ki. Full lineáris elérés, nem a HDD lesz a bottleneck, hanem a hálózat, de igazából az sem, mert videó nézéshez nem kell nagy sávszélesség, mozgatni meg hova?

Otthoni felhasználásról beszélünk természetesen. 10 gigás otthoni háló pedig még mindig nem mondható épp elterjedtnek.

Nyilván máshogy használjuk, de én VM-et nem NAS-ról futtatok.

Ha pedig IO limitbe ütközök build közben, akkor nekem arra nem az SSD a megoldás, hanem a RAM :)

De mint mondtam, nekem (és szerintem sokan másoknak) a NAS elsősorban sok-sok videó, zene, stb. tárolására való, arra pedig tökéletes a HDD. És továbbra is tartom, hogy a gigabit általában előbb kifúj, mint a HDD.

Félreérted. Nem az a gond, hogy maga a hdd lassú, és nem bírom kivárni, amíg több terát rámásolok.

Az a gond, hogy néha (rendszeresen, de nem tudom direkt reprodukálni, ha akarom) az NFS írása és olvasása úgy lelassul, hogy bármi, ami az NFS-hez piszkálna, IO-wait állapotban ácsorog. Pl. volt egy symlink a home könyvtáramban, ami a /mnt/nas/akármi fájlra mutatott. Ha egy ls parancsot adtam ki a home könyvtáramban (és nem cache-ből jött az eredmény), akkor várnom kellett hosszú percekig, hogy valami válasz jöjjön.

Vagy miután nem volt semmi processz, ami írt volna az NFS-re, kiadtam egy sync parancsot, ami kb. 30 órán keresztül futott.

3-4 D állapotú processzt mutat a top, a load valahol 15 és 30 között, és a gép annyira lassan reagál bármire, hogy pl. a browserben youtube video lejátszása akadozik.

Ha a D állapotú processzek nagysokára befejezik amit akartak, a load visszamegy 1 alá, és minden rendes sebességgel működik onnantól.

Na. Azt szeretném, hogy a mountpoint alatt látható legyen a NAS tartalma, de nem akarom, hogy D-ben álljanak processzek és megfogják a gépet. Azt szeretném, ha egy ls pl. azt kapná, hogy timeout van, vagy az adott symlink-et nem sikerült beolvasni, a stat() hibával tért vissza. Az, hogy egy sync mondjuk sokáig fut, mert éppen az NFS-re írást próbálja befejezni és ez lassú, az rendben van. Bár mondjuk nem hiszem, hogy emiatt a loadnak fel kellene mennie olyan magasra, és nem hiszem, hogy emiatt pl. a videónak is akadnia kellene.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

"van benne egy darab 6T WD Red"

Ez itt a kulcs mondat :)

 

Tehatá 1 db, régi pörgős tányéros diszk.... ami ugye egyszerre pontosan 1 helyről képes olvasni, minden olvasásnál előtte pozicionál, odateker, kiolvas... töredezettség (vagy csak nem szekvenciális olvasás) esetén ráadásul egyetlen fájl felolvasása esetén is sokszor végrehajtja a fent hevenyészetten vázolt műveleteket...

Amint több mint egy olvasási kérés érkezik felé, VÁRNI kell egymásra.

Ezt a problémát semmilyen FS, és/vagy semmilyen hálózati megosztá nem tudja orvosolni.

 

Neked SSD-re van szükséged  - vagy több diskből épített, olvasásra optimalizált RAID-ra. De legalább egy használható méretű (RAM/SSD) cache

Most komolyan azt gondolod, hogy a hdd lassabb, mint az sdd, ezért normális az, hogy egy ls parancs egy symlinket követve egy darab fájlról az információkat mondjuk 10 perc alatt kapja meg?

Miközben ugyanaz az ls parancs máskor ugyanazt a műveletet, ugyanarról a hdd-ről olvasva egy másodperc töredéke alatt el tudja végezni?

Ez nekem hihetetlennek tűnik. Korábban évtizedeken át használtam hdd-ket, azelőtt meg floppykat, és semmi sem volt ennyire lassú.

De fene tudja. Valóban nem néztem még meg az iostat-ot, majd legközelebb megnézem.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

"A gond az, hogy néha valami (valószínűleg írás) történik, és ilyenkor lelassul _valami_, ami hatására a Linux eszméletlenül lelassul."

- pontosan MI lassul le? A hálózati átvitel, a fájlszerver, vagy a kliens?

- rendben van-e a fájlszerveren az /etc/exports, /etc/samba/smb.conf?

- a klienseken rendben van-e a felcsatolás?

- Hálózati eszközök router/switch/kliens interface-ek rendben vannak-e, iperf mit mond?

Ha csak néha van lassulás, akkor mi terhel le mit, melyik gépről melyik gépre megy a forgalom....

Szóval... szerintem nem a megosztás típusa a ludas (SMB/NFS)...

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

- pontosan MI lassul le? A hálózati átvitel, a fájlszerver, vagy a kliens?

Nem tudom. A NAS-ra belépve azt látom, hogy se a processzor, se a memória nincs fullon. A hálózaton minimális forgalom van. A linuxos kliensen a NAS-t használni próbáló processzek IO-ra várnak. A Linux system load-ja magas, és bármi, ami a felmountolt NFS fájlrendszerhez bármi módon hozzányúlna, hosszú percekig vagy órákig "fut". Azok a processzek, amik szerintem nem piszkálnak az NFS-en mountolt fájlokhoz, azok szinte jól futnak, de meg-megakadnak (gondolom a magas load miatt a scheduler időnként nem ad nekik processzoridőt egy kis ideig).

- rendben van-e a fájlszerveren az /etc/exports, /etc/samba/smb.conf?

A NAS egy GUI-t ad, amin elég kevés dolgot lehet állítani. Ez, ránézésre, rendben van. Fájlrendszer szinten nem férek hozzá a NAS-hoz (elméletileg ssh-val be lehetne lépni, gyakorlatilag nem fogadja el azt a jelszót, aminek működnie kellene).

- a klienseken rendben van-e a felcsatolás?

Nem tűnt fel, hogy gond lenne. Mondjuk nem tudom, mire gondolsz pontosan.

- Hálózati eszközök router/switch/kliens interface-ek rendben vannak-e, iperf mit mond?

Nem tűnt fel gond. Más dolgok az elvárt módon működnek. iperf-et nem próbáltam még. Majd ha legközelebb jelentkezik a probléma, megnézem.

Ha csak néha van lassulás, akkor mi terhel le mit, melyik gépről melyik gépre megy a forgalom....

Megfigyelés alapján az szokta triggerelni, ha írok a NAS-ra. Nem minden írás. Nagy mennyiségű írás jellemzően triggereli (egy idő után, szóval lehet, hogy megy percekig vagy órákig jól, aztán hirtelen belassul), de simán lehet kis mennyiségű írásnál is, pl. torrenten jön le valami nem túl gyorsan, időnként ír néhány blokkot, és egyszercsak minden lassú lesz. Linuxos laptopról és Raspbian-t futtató Raspberry-ről ugyanúgy triggerelődött. Más klienst nem szoktam használni, mással nem teszteltem.

Szóval... szerintem nem a megosztás típusa a ludas (SMB/NFS)...

Nem gondolom, hogy az NFS az _oka_ a lassulásnak. Szerintem valahogy a NAS csinál valamit rosszul. Viszont az NFS nem tudja ezt úgy lekezelni a kliens oldalon, hogy a gép NFS-től független dolgai lassulásmentesen működjenek tovább.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Én ránéznék wiresharkkal, hogy mi történik, de nem véletlenül egy hulladék SMR HDD, és az okozza a problémát?

Kapcsolat bomlás esetén az sshfs szokott nekem ilyet produkálni, de azt megértem. LAN-on a hálózati fájlrendszer nem csinálhatna ilyet.

Lehet tényleg terhelt. Mondjuk az egyik gépen fut a kereső indexelése vagy vírus kergető, és nem noatime-mal van mountolva a fájlrendszer, azaz minden állomány hozzáférési időpontja frissül, az NFS lock menedzsmentje meg dolgozik közben

Mióta van sshfs, nem bajlódom nfs-sel. Lassúnak éppen lassú, de otthoni használatra elég. Sőt interneten át is használom. Úgyhogy bármelyik Linux helyből  NAS. Nem is értem, minek ez a külön műfaj.

Lógok a szeren (K. Frigyes)

Lógok az ereszen (Sz. József)

Egy Thecus N7700-as NAS-sal jártam így.
Ha egy Linuxos gépen a NAS NFS megosztását csatoltam fel és nagyobb fájlt másoltam rá, akkor egy másik gépen NFS-en nem lehetett elérni ugyanezt a NAS-t amíg ment a másolás.
Samba/CIFS-el ugyanez már jól működött.

NAS és NAS között is van sok eltérés, nekem Synologyval még ilyen nemű gondom nem volt. 8 darab 6 teras wd pro szépen szolgál több éve huszonpár felhasználóval.

Van a kornyezetemben tobb syno/xpeno NAS. Jellemzoen 4 lemezes HDD-s 4 Gb Ram-al Gigabit lan-al. Raid5/6ban kozel giagbit az R/W. Az eg egy vilagon semmi gond nincs veluk. mediakiszolgalo,  backup, archiv, stb. folyamatosan megy tobb userel. Ha Mac-en akarod elerni kapcsold be az AFP protokolt az a leggyorsabb. Samba jo a win-nek, NFS meg linuxnak. Gigabit lan-ra SSD minek? 

vati

Ceges NAS neha rettenetesen lelassult. Kiderult, hogy valakinek a windowsos gepen elindult a viruskereso, es mindent atnezett - tobbek kozt a NAS-on talalhato dolgokat is. Aztan megfegyelmeztek a viruskergetot, es azota szepen megy minden. (mondjuk en csak gitre hasznalom, arra eleg)

Amugy a telefonomat SSHFS-en keresztul szoktam mountolni. Linuxon egyszeru, Winen meg van egy SFTPNetDrive nevu progi, azzal is megy. Elobbi persze szepen mukodik, utobbit ujracsatlakozaskor tutujgatni kell (elvileg ujra tudna kapcsolodni, a gyakorlatban nem, vagy a megosztott file-okat hasznalo progik nem szeretik).

A strange game. The only winning move is not to play. How about a nice game of chess?