[megoldva] gyenge NAS-ra milyen fs lenne jó?

Naplózó filerendszerek (journaling)

Építettem egy NAS-t egy Banana Pi single board computer és egy darab SATA hdd használatával.

A hdd-n jelenleg a korábbi dLink NAS által létrehozott ext4 fájlrendszer van, ami egyébként jól működik.

A dLink eszköz több olyan partíciót is létrehozott, amit most senki semmire nem használ, ezért az egész hdd-t újra akarom építeni. Lesz egy nagy partíció és titkosítás.

Az merült fel bennem, hogy ha már úgyis mindent újraépítek, akkor esetleg az ext4 helyett is lehetne más.

A hdd eléggé tele van, viszont elég sok a duplikáció is. Ha jól emlékszem, a btrfs és a zfs is tud blokkszintű deduplikációt. Ennek örülnék.

Nem tudom, más előnye lenne-e zfs-nek vagy btrfs-nek (van más fs még esetleg, ami szóba jöhet?). Snapshot-ot RAID-et meg ilyesmiket nem tervezek használni, ez a NAS leginkább backup célra szolgál, illetve mesefilmeket szoktak a gyerekek nézni róla a TV-n.

A kérdésem igazából az, hogy a BPi szűkös erőforrásai elegendőek lehetnek-e egy zfs vagy btrfs számára. Úgy emlékszem azt olvastam, a zfs-nek sok memória kell. Az nem zavar, ha a deduplikációs keresgélés sokáig tart, ha később, amikor már nem kell a deduplikációval szüttyögni, akkor normális (vagyis kb. a mostani) sebességgel tudja az olvasásokat és írásokat kiszolgálni.

Ilyen eszközt vettem: http://wiki.banana-pi.org/Banana_Pi_BPI-M1%2B

2 magos ARM Cortex-A7 processzor 1GHz órajellel, 1G RAM

  • 1087 megtekintés

( Sixday v | 2020. 08. 04., k – 13:22 )

zfs-t hasznalo nas-ok dokumentaciojanal egyontetuen 8GB ram a kovetelmeny, ettol eleg tavol vagy :)

( ibenny v | 2020. 08. 04., k – 13:33 )

Szerkesztve: 2020. 08. 04., k – 13:46

" kérdésem igazából az, hogy a BPi szűkös erőforrásai elegendőek lehetnek-e egy zfs vagy btrfs számára "

Nem. :) Maradj nyugodtan valami "mezei" fs-nel. Egyebkent a titkositas is odacsap a teljesitmenynek.

( fairlane | 2020. 08. 04., k – 13:44 )

Ahogy a címben írtad "Gyenge NAS". A dedup és a crypto is nagy valószínűséggel CPU-ból lenne megoldva, így esélyes, hogy ezek bekapcsolása agyoncsapná a teljesítményt.

Próbáld ki egy üres HDD/SSD-vel, ha tudod, az megmutatja, hogy mit bír el a BPi

Zfs-hez kevés a memória (ahogy már írták), btrfs-sel nincs tapasztalatom. 

...úgyis jönnek...

( tigrincs | 2020. 08. 04., k – 13:53 )

Miert nem veszel egy normalis NAS-t? Amennyi idot ezzel elcsesztel (megy/nem megy teszt topic lofasz meg szenvedes)

Miert nem veszel egy normalis NAS-t?

Vettem egyet*. Nem voltam vele elégedett. Innen indult az egész történet. Egyébként a "normális NAS"-ban kevesebb memória volt, mint amennyi a Banana Pi-n van.

Amennyi idot ezzel elcsesztel (megy/nem megy teszt topic lofasz meg szenvedes)

Időt a normális NAS-sal csesztem el. Teszteléssel, hibakereséssel, olvasgatással.

A saját NAS összerakásával kb. 2-3 napot töltöttem el, és ez bőven belefér a hobbira szánt időbe.

Ne aggódj, ha sok idő elcseszése nézne ki, akkor más megoldást keresnék. Egyelőre jó iránynak tűnik ez.

* Persze lehet azt mondani, hogy az nem volt normális, és X meg Y kellett volna, vagy esetleg nem ilyen árkategóriát kellett volna néznem, hanem 5x-10x ennyiért venni egyet. Késő bánat + nem akartam erre túl sok pénzt elszórni.

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.

( pirate | 2020. 08. 04., k – 14:05 )

A BananaPI-n USB2 portok vannak rajta, az is ront a teljesitmenyen.

rPI4 + USB3-as kulso lemez: elegedett vagyok a teljesitmennyel (samba + xfs)

"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."

A BananaPI-n USB2 portok vannak rajta, az is ront a teljesitmenyen.

Az a tény, hogy USB2-es portok vannak rajta, az hogyan és minek a teljesítményén ront?

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.

Nem kétlem, hogy így lenne, ha USB-n csatolnám a lemezt.

Viszont pont azért vettem Banana Pi-t, mert van rajta SATA csatlakozó, így eszembe se jutott, hogy a SATA lemezt egy konverter segítségével USB2-re csatlakoztassam.

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.

Ó, nincs ezzel baj, csak az első kommentedet félreértettem. Azt hittem, azt mondod, hogy valami módon az, hogy USB2 van a lapon, valami mást belassít. Mittudomén, leterhel valami buszt vagy lefoglalja a processzor kapacitásának egy részét, vagy akármi.

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.

( Tron | 2020. 08. 04., k – 14:10 )

XigmaNAS (freebsd)

egyetlen hdd esetében UFS lőhető be. Remekül el fog viháncolni a banánodon.

Ez de perverz... :)

( •̀ᴗ•́)╭∩╮

"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"

Az élet ott kezdődik, amikor rájössz, hogy szart sem kell bizonyítanod senkinek

Ha meg akarod nevettetni Istent, készíts tervet!

$ sysctl dev.cpu.0.%pnpinfo
dev.cpu.0.%pnpinfo: name=cpu@0 compat=arm,cortex-a7

$ uname -a
FreeBSD bananapi-m1p 12.0-RELEASE FreeBSD 12.0-RELEASE r341666 GENERIC  arm

$ mount | grep ufs
/dev/ufs/rootfs on / (ufs, local, soft-updates)
/dev/da0s1 on /home/hdd (ufs, local, noatime)

Igaz, titkosítás nincs (meg natúr FreeBSD).

( Sanya v | 2020. 08. 04., k – 15:02 )

Nem értek hozzá, de NAS-ba minek titkosított partíció?

Leginkább azért, hogy ha mondjuk betörnek, és a betörő felmarkolja és elviszi az irodám polcán fekvő hdd-t, akkor ne tudja egy kíváncsi bűnöző vagy új tulajdonos megnézni a különféle feljegyzéseimet, könyvelést, igazolványok scannelt másolatait, stb.

Végül is eddig se volt, csak felmerült, hogy esetleg nem ártana, ha különösebb gond nélkül menne. Ahogy pl. a laptopra dugott külső hdd-n (ami szintén backup), LUKS-szal titkosított minden, mert miért ne, a NAS-on se lenne baj, ha titkosítva lenne. Persze ha ez túlzás lesz a gyenge hardvernek, akkor csuklás nélkül kihúzom a listáról. Néhány spreadsheet már így is egyedileg titkosított, legfeljebb majd végignézem a listát és másokat is titkosítok a laptopon. A NAS meg majd csak eltárolja az eredményt.

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.

Valoszinuleg jobb valasztas az ext4, mint az ext3. De azzal nincs tapasztalatom NAS-on, illetve nincs osszehasonlitasi alapom, viszont ez a cikk alapjan gyorsabbnak kell Lennie: https://web.archive.org/web/20120302034319/http://linuxologist.com/1gen…

plusz gyorsabban csinalja meg az fsck-t a wiki szerint mint az ext3 :)

( uid_16313 | 2020. 08. 05., sze – 12:02 )

Lehet kipróbálnám a JFS-t, annak híresen alacsony a CPU igénye.

( sigellef | 2020. 08. 05., sze – 13:02 )

ext2

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

Az ext2 tényleg csak annyit ír, ami a fájlok/mappák tárolásához kell. Nincs journal, kevés memória/processzor terhelés... régen ugye pár MByte RAM-mal, 400MHz procival (vagy ezeknél soványabb rendszereken) is használható volt. A mai Linuxok is szépen futnak rajta (Auchan-os Selecline cloudbook-on ezt a fájlrendszert használom Ubuntu MATE 20.04-gyel) . ... elvileg kritikus adatok tárolására nem való, de gondolom egy "gyenge NAS"-t senki se használna ilyenre. Mondjuk, én régen több évig használtam ext2-t, és nem volt adatvesztéses problémám.

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

( bennyh | 2020. 08. 06., cs – 13:16 )

Azért egy BTRFS LZO tömörítéssel még nem feltétlen elvetendő. Egy próbát tennék vele, max gyorsan elveted, ha mégsem müxik :)

Színes vászon, színes vászon, fúj!

Kérem a Fiátot..

( gee v | 2021. 04. 15., cs – 16:08 )

Na a régi hdd-n maradt az ext4 és használtam eddig, de most, hogy kinőttem, lett egy új hdd. Gondoltam, akkor már kipróbálom, hogy mit tud a Banán.

Az új hdd-re LUKS került (nem partícionáltam). A LUKS leírás szerint érdemes nullával felülírni, hogy a nagyon szofisztikált hackerek ne tudják, hogy melyik blokkokban volt és melyekben nem volt adat. Ezt elkezdtem, ez alatt a processzor kb. fullon pörgött, 17% user, 75% sys, 0% idle, system load 3. Ment 35 percig, aztán meguntam, főleg, amikor kiszámoltam, hogy kb. 9 napig tartana, amíg végigírná az egész hdd-t.

Tettem fel btrfs-t a LUKS tetejére, most fut az rsync, másol a régi hdd-ről. A régi hdd-t etherneten és NFS-en keresztül éri el, az új (LUKS+btrfs) lóg direktben a SATA porton.

A processzor 38 fokos, a load 3 körül van, processzor kb. 80%-on dolgozik 16% user, 54% system, 16% idle, 5% IO wait.

A rendszer teljesen reszponzív (well, annyira, amennyire alapból is).

Ennek alapján úgy tűnik, hogy a NAS funkciókhoz ez teljesen megfelelő lesz.

Azt nem tudom még, hogy a hdd-ről olvasás mennyire lesz megterhelő és vajon a Plex számára marad-e elég kraft. Ez majd egy következő teszt lesz, de mivel a Plex-hez simán nem volt néhány mese esetén elég erős a Banán, ezért az már így is a listán van, hogy a Plex máshová költözne, valami erősebb eszközre.

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.

Mondjuk engem nem zavar, hogy a kernel partíciós táblát lát ott, ahol nincs. A parancsoknak én a /dev/sda-t adom, azokat meg nem zavarja ha van mellette /dev/sda42 is.

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.