Naplózó filerendszerek (journaling)

Sziasztok!

a minap feltettem ce'l-debiant (voyage) egy alix.6e1-re. 4gigas cf-kartya'ra. a /var bizonyos resze es a /tmp tmpfs-kent vannak fent (/var/tmp, /var/run, /var/log, kb.), igy most az `lsof` szerint egy futo rendszerben nincs csak irasra nyitott file a / alatt. a / maga egy ext2 particio hogy journal commit ne legyen. ezzel az egesz konfiggal merul(t) fel par dilemma, ha valakinek van otlete/tapasztalata, azt megkoszonne'm!

tehat, ezek:

• miert nem tudom remount,ro-val readonly-ra tenni a /-t? csak azert mert annak par alkonyvtara rw-re van mountolva?
• ha osszeomlik a rendszer (megszunik az aramellatas), es tuti hogy nincs rw-re megnyitott file (az elozo pont ellenere, lsof-ban latszik), akkor mennyire krachol ossze egy ext2? ugye nyilvan nem "clean", a reboot soran atmegy rajta egy fsck, de ez mennyire lesz zord, ha egy not-clean ext2-t talal? csak mert nem tul egeszseges ha pl root jelszot ke'r igy hobbibol (mint ahogy a regi szep idokbol emlekszem, hogy ke'rt -- e's mert a ku"tyu"n nincs konzol (soros konzol van alapbol az alix lapon, de a ku"tyu" mint soros-hardver-vezerlo egyseg uzemel, es emiatt tiltva van, mind bios-bol, mind kernelbol, mind tty-bol).
• tud valaki esetleg egy jo letezo" writemostly network filerendszert? a /var/log ugye nem lenne rossz, ha le lenne mentve. de a cel alkalmazas ettol fuggetlenul fog loggolni es az a fontosabb (udp-n lo"k majd ki cel-csomagokat), szoval ez nem annyira esszencialis.

koszi, a

Hello

Most hogy penteken megjelent a ZFS Linuxra (mint a fooldalon a hirek kozott olvashato), mikent lehet azt a gepunkre varazsolni ? Mert a ceg oldalan tovabbra is csak a betara valo regisztracio lehetoseget talaltam.

Illetve mennyire stabil megvalositas ez vajon ? Varhato hogy esetleg a jovoben fabrikaljak, es az adataim elvesznek emiatt ?
Szoval mennyire stable ez a "stable" ?

BIGFILE egy 3.5G-s file. A következő jelenséget produkálja. (Más, kisebb (1G) fileokkal is könnyen reprodukálható a jelenség ... ) Mi lehet a gond? Disk? Memória?

SERVER:/tmp# md5sum BIGFILE
b42c7584c2af4cd8396d831e0e4bbb59  BIGFILE

SERVER:/tmp# md5sum BIGFILE
cbcec11bb82bb983a26615c7863bf793  BIGFILE

SERVER:/tmp# md5sum BIGFILE
7fddcbc38cbf17c7235726cb476d3c49  BIGFILE

SERVER:/tmp# md5sum BIGFILE
85fdfdd74dec330cad58b636c9bf9bfc  BIGFILE

SERVER:/tmp# echo "1" >/proc/sys/vm/drop_caches
SERVER:/tmp# md5sum BIGFILE
75b5bc8cc140852c6d7ddf1f79512023  BIGFILE

SERVER:/tmp# echo "1" >/proc/sys/vm/drop_caches
SERVER:/tmp# md5sum BIGFILE
87b3e6c187a5afd8bb6c7923719561ce  BIGFILE

Egy ideje használok Btrfs fájlrendszert:

/dev/disk/by-id/ata-TOSHIBA_MK2546GSX_97PKF24HS-part6 /home                btrfs      defaults,noatime 1 2

Elvileg van szabad hely:

Fájlrendszer          1K-blokk   Foglalt    Szabad Fo.% Csatl. pont
/dev/sda6             12578860  10702400   1876460  86% /home

Átmásolnék rá egy fájlt:

# ls -l /tmp/test.zip
-rw-r--r-- 1 auth.gabor users 190165248 2009 dec 15 /tmp/test.zip
# cp /tmp/test.zip /home/
cp: ”/home/test.zip” írása: Nincs több hely a lemezen

Ilyenkor mi van? Mentés, formázás, visszatöltés? Vagy van valami eszköz ezt rendbetenni? :)

Adott egy fájlrendszer, amin van több, mint 15 millió apró fájl. Jelenleg ext3, mert bevált és stabil.

Éjszakánként azonban rákergetek egy rsync-et, backupolás céljából. Mivel a fájlok többsége nem változik, így tényleges másolás szinte alig történik, viszont a könyvtárlista készítése (fstat) több óráig is eltart, amíg veszettül seekel a diszk.

Ha van valakinek valami ötlete, hogy hogyan lehetne optimalizálni ezt a folyamatot, akkor nosza, mondja!

Oké, nyilván, az SSD egyfajta megoldás, mert nem kell rajta fejet pozícionálni :)

Pl. valami olyanra gondoltam, mint a FAT fájlrendszer, hogy a diszk elején egykupacban van a FAT tábla, ahonnan az összes metaadatot be lehetne kesselni egy szekvenciális olvasással, elvégre RAM van dögivel. (vagy, ha nem is megy egy szekvenciális olvasással, mivel minden egy helyen van, nem kell sokat seekelni.)

Szeretnék áttérni freebsdre (7.x-stable), de az adatokat ugyanúgy el akarom érni később linuxról is (gentoo, 2.6.30), szóval kell egy fs az adatoknak, amit mindkettő visz. Elsőre xfs, nfs jutott eszembe, amit mindkettő visz, de az xfsről azt hallottam, hogy hw hibákra és crashekre érzékeny, könnyen eltűnnek olyankor az adatok a cache-elés miatt, de nem tudom, lehet-e gyakoribb syncelésre állítani, van-e értelme egyáltalán annak. NFS pedig inkább végső megoldás lenne, mert nem megosztani akarom, így lehet, hogy felesleges tököléssel járna.

Ti milyen fst javasoltok?

Sziasztok,

van egy friss telepitesu rendszerem, amin a df -h es mount nem latjak a a raid1 tombot. Debian stable, ext3, mdadm. A df -h /dev/md0-ra a /dev jelenik meg. Egy merevlemezen van a /boot, / es swap, 2x2TB merevlemezen meg a raid1 /home. Az mdadm --detail helyesen latja a particio meretet. A kerdesem az lenne, hogy ez a 2TB-nak koszonheto-e, valamint hogyan lehet a helyzeten segiteni. Egyelore nem talaltam tul sok hasznosat.

Koszonom.

Teszteli valaki közben Debian testing ágban a Btrfs-t?

Kíváncsi lennék hogyan áll megbízhatóság terén. Compression és dedup miatt lenne érdekes, meg úgy egyébként.

szerk.: közben benéztem a wiki-ben és látom hogy a deduplication még csak tervben van.

szerk2.: az ext4 wiki oldalán található infó szerint:

Transparent compression No
Transparent encryption No
Data deduplication No

ez nem gáz egy kicsit? nem foglalkoztam az ext4-gyel ezidáig mert nagyon nem érdekelt, csak most ránéztem, és azt látom, hogy hórukk módra nekigrottak felpolírozni az ext3-at, és akkor még on-the-fly tömörítés sincs? nem lét kérdés, de új fs-nél alap lenne legalább ezt belevenni manapság imho.

egyik ext4 partíción eltűnt minden szabad hely, pedig a valóságban lennie kellene.
Fájlrendszer Méret Fogl. Szab. Fo.% Csatl. pont
...
/dev/sdb9 776G 737G 0 100% /media/sdb9

umount/remount, ill fsck.ext4 -f /dev/sdb9 majd reboot után is ugyanez a helyzet.
mit lehet tenni? vagy itt csak a backup&format segít?

Update,
nem ez az első ilyen eset.

Van valami megoldás linux alatt a fenti (ring-buffer, circular-buffer) fájlrendszerre?
Ha nem létezik ilyen, valami más megoldás arra, hogy van egy kötet, amibe folyamatosan
kerüölnek bele a fájlok, és ha a kötet mérete közelít a maximálishoz, akkor a régebbi fájlokat törli?

Köszi

(ez esetleg megfelel erre a célra?: LinLogFS - http://www.complang.tuwien.ac.at/czezatke/lfs.html)