Naplózó filerendszerek (journaling)

Szeretnék egy ZFS-t egy Debian alá root filerendszernek. Ezen a poolon nem lesz felhasználói adat (/home, /srv), az másik diszkeken lesz másik poolban más redundanciával. Házi szerver, nem production kategória.

Van egy jó leírás itt: https://github.com/zfsonlinux/zfs/wiki/Debian-Stretch-Root-on-ZFS

Ehhez képest szerintem lehetne egyszerűsíteni a 3-as pont környékén, és ebben kérnék tanácsokat, és hogy jó-e a gondolatmenetem. Sokat olvastam már a ZFS-ről, de gyakorlati tapasztalat 0, az majd most jön.

1. A leírás nem az rpool-t csatolja fel /-nek, hanem rpool/ROOT/debian-t. A többi datasetben teljesül a hierarchia, hogy rpool/home->/home, rpool/var->/var, stb., de itt nem. Mi ennek az értelme? Az pool önmagában egy dataset is, tehát simán lehetne rpool->/. Hierarchia ellenére lehet állítgatni minden dataset propertyjeit külön-külön vagy egyben, snapshotolni is lehet külön-külön vagy egyben. Technikai limitációról se tudok, azt kivéve, hogy magát a root pool-t érdemes rpool-nak nevezni, de ez a ROOT/debian furcsa.

2. Csomó datasetre be van állítva a com.sun:auto-snapshot. Ez eléggé Solaris specifikusnak tűnik, ezért kihagynám. És engem marhára nem zavar, ha a rendszer snapshotokba belekerül pl. a /var/cache. Olyan kevés adat lesz ezen a poolon eleve (~10 GB) a teljes diszkhez képest (~240 GB), hogy inkább azt mondom, legyen meg inkább a kelleténél több a snapshotokban, mint hogy azt kockáztassam, hogy valami kimarad és ezért nem tudok visszaállítani valamit.

3. El van aprózva a sok dataset: /var/spool, /var/log, stb. Ez még elég konszolidált, sokan szétszedik /usr-t, /usr/local-t, /boot-ot, stb. Mi hátrányom van abból, ha én nem aprózom el, és extrém esetben csak egy dataset lesz az egész rootfs alatt? Szerintem nem sok. (És meg tudom gondolni magam később, init 1+rsync kombóval.)

4. UTF-8 normalizáció is be van állítva a leírás szerint. Pontosan tudom, hogy ez mit csinálna. De találkozott már valaki olyan esettel, ahol erre tényleg volt szükség? utf8only-t szívesen állítok. Nem hiszem, hogy lenne olyan eset, hogy egy é betű kétféleképpen van kódolva ugyanabban a mappában. Tudtommal a kliensek (Linux ext4 és Windows NTFS) nem végeznek normalizációt. Tehát ha én most itt beállítom, abból maximum baj lehet, de jó nem származik belőle.

Lehet hogy egy hulye kerdes, de: van-e lehetoseg 32bites (beagyazott jelleggel uzemeltetett) linuxra felcsatolni 16 terasnal nagyobb filerendszert? Egy regebbi (3.4.x-es) voyage alatt mint az ext4, mind az xfs azt mondja hogy nem. Azaz: mount: File too large.

Van ugye az eredeti Oracle-féle ZFS, meg van az OpenZFS. Aztán utóbbiból van verzió Linuxra (zfsonlinux SPL-lel), van FUSE, bizonyos BSD-ken van natívan valamelyik ZFS a kettő közül, stb.

Kicsit nehéz ezen kiigazodni, hogy melyik melyiknek a forkja, és mennyire stabil, kiforrott. Tehát a kérdés: melyik a jó, melyiket kerüljem? Nem konkrétan verziószámra gondolok, de az is lehet érdekes.

Kicsit a szöghöz keresem a kalapácsot, de alapvetően egy ZFS storage-et akarok építeni, és majdnem mindegy, hogy milyen OS lesz alatta.

Ezt találtam: https://btrfs.wiki.kernel.org/index.php/RAID56. TLDR: BTRFS mellett RAID5/6 használata életveszélyes és tilos. Ez remélem azt jelenti, hogy a BTRFS fájlrendszer szinten tud RAID-et (à la ZFS), ami szar, de ha nekem van egy mdraid-em, és azon felül egy nyers BTRFS, az menni fog, ugye? A Synology-s BTRFS+RAID nem szar, ugye?

A másik, fő kérdésem az, hogy egy RAID5/6 által nyújtott redundancia és a BTRFS által adott checksum össze tud játszani valahogy? Amikor a Linux kernel a diszkről olvas, egyszerre olvassa az összes diszkről az adatokat és RAID paritást is, és on-the-fly ellenőriz, vagy a RAID paritás csak egy esetleges rebuild esetén kerül felhasználásra? Ha hibás adat jön fel a RAID tömbből pl. bad block miatt, a BTRFS checksum észreveszi, hogy baj van, de hogy tudja javítani? Megkéri a RAID alrendszert, hogy más diszkről olvassa be az adatot, hátha az jó lesz, vagy simán csak olvasási hibát jelez és széttárja a kezét?

Sziasztok,

Részemről sok helyen nem nagyon használok már partíciót. Ext4-es raid tükörnél sem mindig, habár ott néha hasznos hogy kisebbre tegyük kicsivel a méretet, így új diszknél nem lesz gond ha kisebb a fizikai méret, mert ugye kisebbre nem lehet sync-elni ha diszket kell cserélni.

Viszont BtrFS munkaállomáson sem igen használok már. Simán formázom az sdb-t.

Milyen esetekben lehet vajon hátrány a hiányzó partíció Linux alatt (például ha nem kell swap) ?

Sziasztok!

Adott két keveset futott merevlemez amit évekkel ezelőtt kezdtem el használni, de csak rövid ideig. A rajta lévő filerendszert kellene újra életre kelteni valahogy.
Amire emlékszem biztosan:
- debian vagy ubuntun üzemeltek
- szoftveres raidben (mivel kettő, gondolom tükröztem)
- ext3 vagy 4 lehet rajta
- 2009 októberében gyártott lemezek, így +3 éves intervallum érdekes (ha kb be kell lőni mi lehetett a szoftverkörnyezet)

Merre lehet elindulni velük? Hogyan tudom ennyi ismeretlenes egyenletben kideríteni apránként, hogy mi is volt valójában és hozzáférni az adatokhoz? Az addig megvan, hogy beteszem egy mostani szerverbe egyiket vagy mindkettőt.

SSD-ről klónoznék át Ext4-re telepített Arch Linuxot másik SSD-re, csak a / partíciót. Egy másik topikban locsemege kolléga az rsync -avHASX /forras /cel parancsot ajánlotta. Ezzel így tényleg működik, vagy figyelnem kell még valamire? Az rsync man-ja emlegeti még az -s kapcsolót is, amely a fájlnevekben a szóközt őrzi meg, ez tényleg szükséges? Nem szeretnék szívni azzal, hogy mikor állítom vissza a rendszert, akkor bootoláskor derüljön ki, hogy nem működik.

Lehet még azzal cifrázni, hogy mindjárt mentéskor Tar Gizibe csomagolom az rsyncelt fájlokat? Vagy ami még jobb, úgy működne, hogy először tar -czf /forrás /cél paranccsal csinálom a backupot, megőrizve a hard linkeket, jogosultságokat, egyebeket, és akkor nem kell rsync sem, nem ragaszkodnék hozzá.

Az EFI bootot megoldom, és a PARTUUID-t módosítom az EFI loaderben, az nem okoz gondot.

Sziasztok!

Nem teljesen pontosan írja le a cím a problémát, vagy inkább a segítségkérés okát, de picit kifejtem:
- van 12 db 6T-s diszk egy JBOD dobozban
- 2*1T lemez, meg 2*240 GB SSD a gépben

Hogyan lenne érdemes összefogni a lemezeket, hogy optimális legyen a helykihasználás, és a redundancia legalább 2 lemez halálát elviselje. (elsősorban azért, mert a fene tudja, mennyi idő alatt tudunk pótolni kieső lemezeket... - egyetemen vagyunk...)
Raidz2 nyilván a cél, de azt írják, érdemes inkább 8 lemezzel megcsinálni, ekkor olyan 35T lesz a nettó kapacitás.
Ebben az esetben marad 4 lemez, amit mondjuk össze tudok fogni 2*2 mirrorba, vagy egy másik Raidz2-be.

Esetleg érdemes a vdeveket másképp szervezni?

Másik kérdés, hogy a 2 SSD-t az egyik zpool-hoz rendeljem hozzá, vagy mondjuk megfelezve kapja meg mindkettő a rá eső részt log-ként.
A nagyobb részre sok, relatíve nagy, nyers videó menne, a kisebbre elsősorban asztali gépek mentései.
De igazából feltétlenül muszáj megosztani a tárolókapacitást.
Igazán nem kritikus a sebesség, a szerverben 2db GbE van, a kliensek is gigabiten ülnek.

A fő problémám az, hogy ez egy picit (ha nem is nagyon) túl van a hobbi-kategórián, és a RAID-ek méretezése, optimializálása az eddigi tudásomtól, tapasztalataimtól messze áll.
Olvasgattam, de kíváncsi vagyok, ki mit ajánl, milyen megfontolások lennének (amikről esetleg nem is hallottam), mikre érdemes odafigyelni.

Openindiana van rajta.

Kiegészítés:
16GB, Xeon 1620-V3
A lemezek egy LSI SAS2008 vezérlőn ücsörögnek, egy Intel JBOD dobozban. Ez utóbbi pontos típusát nem tudom fejből.
A lemezek típusa: Seagate ST6000VN0031 7200rpm

Köszönöm!

Sziasztok!
Van valami módja hogy egy bizonyos fájl elöző verziójára valahogy visszatérjek?
A sztori kispénzű helyen windows XP-s gépek (!) linux szerveren tárolnak dolgokat és benyaltak egy cryptoshield 2.0 -t szinte mindent sikerült visszaállítanom a biztonsági mentésekből de kéne 2db fájl amiket jó lenne frissebb verzióban is látni. Most a könyvtárban ott van a crypted fájl és a biztonsági mentésből visszatólt is, de ez pár napos (és sok-sok ember pár napos munkája)

Jelenleg egy laptopon egy 20150924 "állású" - tehát meglehetősen régen nem frissített - openSUSE rendszer található, kb. 400 GB-nyi helyen (ennek is nagyobb része akkoriban üres volt - az elmondás alapján). Miután nem akar elindulni - a gép igen (bootol) ÉS nem volt leejtve!, de nem indul maga a rendszer, hanem mindenféle krix-krax következtében "megáll" konzolképernyővel (a Caps Lock bill. is villog...)

Próbáltam ma egy 20160306-os ISO image útján frissíteni, de a btrfs rész csatolásánál az egész leáll hibával!
A rendszerpartíció kiválasztásának a lehetőségéig eljut, de utána jön a hibaüzenet.
Hivatkozik a YasT-ra (is), valamint egyéb másra (ezeket nem írtam fel...), de...

1. lenne-e lehetőség egy - szigorúan és minimális adatmentésre (max. 0,5-1 GB-nyi anyag lenne: LO fájlok, néhány kép stb.)?
2. olvasható-e pl. Win7 alól ez a fájlrendszer? Ez utóbbira próbáltam rákeresni, de érdemi, avagy értelmes dolgot nem találtam...
3. esetleg egy másik openSUSE telepítésű gépen keresztül "megfogható" lenne az a néhány adat?

Előre is köszönöm az esetleges válaszokat.