Naplózó filerendszerek (journaling)

Nincs szerencsem a naplozo fs-ekkel :) Jopar eve ext2-rol ext3-ra valtva nem naplozott, akkor reiserfs ment fel, ott a nagy file-ok mozgatasanal elofordult, hoyg lefagyott es se a celhelyen, se a forrashelyen nem votl meg a file.
Aztan jott az etch ext2 fs-t atallitom ext3-ra: http://hup.hu/node/67652

Most a melohelyi routerben van gond (40G-s Samsung wincsi, a merete alapjan cca. oteves lehet) kettyent mehg. Mintha lefagyna. Kiderult, hoyg nem fagy le, csak ro lesz az fs. Vicces. Meg viccesebb, hogy restart utan journalt allit vissza, ezert nem megy a dhcp szerver (/etc/default/dhcpd-server fileban az eth3-ra all at. Mikor lehetett itt eth3, nem tudom). Kicsit gugliztam, hoyg lehet kikapcsolni a naplot. Nem lenne bonyolult, itt [url=http://linux.ittoolbox.com/groups/technical-functional/redhat-l/ext3-fi…
] egy [/url] pelda. A gond csak az, hogy
1. LiveCD, vagy a sajat Debian gepembe atrakva nem enged fsck-t futtatni, tune2fs meg kozli, hogy futtassam elobb az fsck-t. Azonyga, nem tud valami flagot beallitani a superblockban.
2. Sajat rendszer es init 2 vagy bootkor single, lehet fsck, lehet tune2fs, de restart utan leszarja nagy ivben.
3. Volt meg debugfs is (errol jo lenne vmi leiras, kulonosen az "ssv" paracsrol, mert az szep es jo, hogy az "ssv -l" kiirja, hogy milyen lehetosegeket tudok atirni a superblockban, csak azt nem, mi a jelenlegi ertek es melyik pontosan mi). Abban is hiaba kapcsoltam ki a journaling-ot, restart utan visszairta.

Meg viccesebb, hogy a /var/log-ot nem bantja a journal visszaallitas, de az /etc-t igen. smartctl is jelez errorokoat a wincsin, szoval sztem orulnom kell, hogy igy jelentkezett, nem adatvesztessel :)

Hat ennyi, berakok egy uj wincsit, rsync-cel arakom egy az egyben a rendszert, lilot meg valahoyg megoldom (vagy slave lesz az uj wincsi, mindegy), aztan remelhetoleg vegeter a kalvaria :)

Ui: vegulis nem tanacsot kerek, irhattam volna blogba is, csak erdekes, ami tortent. Bar, ha van valakinek a superblock felepiteserol leirasa, annak orulnek :)

Ismeri valaki? Esetleg van valakinek, aki segítene megmenteni egy 100 és egy 300 GB-os adathalmazból, amit lehet?

Sziasztok,

van olyan linuxos fájlrendszer, amely ntfs-hez hasonló acl-ekkel rendelkezik?

A cél a következő lenne: egy linuxos storaget szeretnénk építeni, amely továbbosztaná a többi gépnek a tárterületet (nfsv4-en a linuxos szervereknek, sambán a win2k8-as szervernek). A gond ott van, hogy a win2k8-as szerveren roaming profile-ok vannak, amelyek igényelnek néhány spéci ntfs-es jogosultságot (jelenleg openafs-t használunk samba-val kiegészítve, de az openafs tudtommal csak az alap linuxos acl-eket támogatja - posix acl kiegészítés nélkül -, így nem jó).

Előre is köszi a válaszokat

érdemes új winchesterre ext4 fájlrendszert feltenni?
általában reiserfs volt amit használok. eddig meg voltam elégedve vele. bár a BKL néha zavaró. kérdés, hogy 1Tb méretű partícióknál is optimális e még? vagy inkább ext4? esetleg jfs? vagy xfs?
régebben használtam xfs fájlrenszert is. remek olvasási teljesítményt nyújtott, a fájltörlés viszont lassú volt. a nagyobb hibája pedig az volt, hogy nagyon rosszul tolerálta az "áramszünetet" és a "takarítónénit":)

Sziasztok!

Gyorsan átfutottam a wikipedia-s fájlrendszereket összehasonlító táblázatot, de nem lettem okosabb.

Egy ~2TB-os partícióra kellene fájlrendszert néznem. A használat úgy nézne ki, hogy 500MB-20GB közti méretű fájlok kerülnének rá, hetente kb. 3 db. A szélsőséges méretekből kevés van, az átlagméret ~3,5 GB körül mozog. Ha valamit rámásolok, az egyben történik, és ott is marad, nem, lesz törölve, csak visszaolvasva, de az olvasás nem szekvenciálisan történik, hanem ide-oda ugrálva a fájlban.

Van ennek a használati módnak szerintetek valami speciális igénye, ha szeretném, hogy gyors legyen, vagy mehet rá egy ext3, vagy bármi? Milyen blokkméretet érdemes ehhez választani?

Bocsánat, ha nagyon hülye kérdést tettem fel, csak nem tudtam eldönteni, mit lenne érdemes...

Volt egy két partícióból létrehozott RAID1 tömb. Ezt szétszedtem majd ezután:
Az egyik HDD-n az ext3 fájlrendszer zsugorítva lett, majd egy kicsit visszanövelve.
Kapott még egy új partíciót és fájlrendszert a szabad helyre.
Erre lett létrehozva az új RAID1 tömb, de most teljes HDD-re, nem csak partíciókra.
Hiba nélkül mountolható a teljes fájlrendszer és működik is.
Viszont néhány fájl eltűnt. Egyeseknél ha megpróbálok azonos névvel újat odatenni IO error lép fel.

fsck error:
The filesystem size (according to the superblock) is 243007488 blocks
The physical size of the device is 226319695 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort?

Majd ilyenek sorra, nem győztem, így megszakítottam:
Error reading block 233036734 (Invalid argument) while reading indirect blocks of inode 46899209. Ignore error? yes
Force rewrite? no

A -cc paraméterrel, pedig:
Error reading block xxx (Invalid argument) while reading inode and block bitmaps

Van erre megoldás? Ha igen mi?
Illetve azt a kevés eltűnt fájlt viszontláthatom-e valaha?

(Az resize2fs addig el se indul, amíg egy manuális fsck le nem fut...)

Lehet ilyen eltérés a resize2fs-nek és a fdisk-nek megadott méreteknél, ha mindkettőnél xxx GB volt megadva?

A problémám az alábbi! Adott egy ext3-as truecrypt-es partíció, és időnként azt a jelenséget produkálja, hogy amikor egy könyvtárat akarok létrehozni, akkor 5-10 másodpercbe is telik neki, mire megcsinálja. Strace-el néztem az mkdir call-on áll ennyi ideig. Van valakinek ötlete a hiba okára, vagy arra, hogy hogyan tudom az okot kideríteni?

Más, csak nem akartam neki új topicot:

reset high speed USB device using ehci_hcd and address 3

Tudja valaki, hogy ezt mi okozza? USB-s külső vinyó esetén?

Adott nehany particio, ami nem /, nem /var, nem /tmp, nem /usr es nem mas egyebb hasonlok tarolasara es futtatasara szolgal, hanem csakis szemelyes dokumentumok felhalmozasara, feldolgozasara, mozgatasara stb. Kerdes: szukseg van-e ezeken is az. un. lefoglalt tarhelyre, ha ext3-at hasznalok? Illetve teljesen biztonsagos ennek felszamolasa ("tune2fs -m 0")? Eleg sok helyet veszitek ugyanis nagymeretu particiok eseten ezzel az 5%-kal. Es, ahogy latom, az XFS meg a JFS tavolrol sem foglal le alapbol akkora helyet. (De azokat a fajlrendszereket meg nem merem hasznalni.)

Azt tapasztalom, hogy ha új fájlt hozok létre, vagy másolok egyet, akkor az legyen akár egy pici (pár kbyte) fájl, akkor is lassan jön létre, legalábbis néha (de ahhoz elég sűrűn, hogy most már idegesítsen). A jelenség egyébként amiatt van, hogy a fájl létrehozásakor rettenetesen elkezd tekerni a disk. Arra tippelek, hogy valami journal vagy valamilyen hasonló területe túl kicsi, ezért mindig bővítenie kell, amikor új file jön létre.

Amióta nem kell pecselni a kernelt, azóta használok reiserfs-t, ugyanígy létrehozva, de ilyet még nem láttam. A reiserfstune ilyet mond:

ap:~# reiserfstune /dev/mapper/data_vg-data_lv
reiserfstune: Journal device has not been specified. Assuming journal is on the main device (/dev/mapper/data_vg-data_lv).

Current parameters:

Filesystem state: consistent

Reiserfs super block in block 16 on 0xfd07 of format 3.6 with standard journal
Count of blocks on the device: 244187136
Number of bitmaps: 7452
Blocksize: 4096
Free blocks (count of blocks - used [journal, bitmaps, data, reserved] blocks): 25411625
Root block: 109964222
Filesystem is clean
Tree height: 5
Hash function used to sort names: "r5"
Objectid map size 2, max 972
Journal parameters:
Device [0x0]
Magic [0x129e0fe4]
Size 8193 blocks (including 1 for journal header) (first block 18)
Max transaction length 1024 blocks
Max batch size 900 blocks
Max commit age 30
Blocks reserved by journal: 0
Fs state field: 0x0:
sb_version: 2
inode generation number: 9989
UUID: 57b57549-7082-404d-bb36-a5071d1025d5
LABEL:
Set flags in SB:
ATTRIBUTES CLEAN

A disken egyébként jobbára filmek vannak, azaz 3-400M-s meg 700M körüli file-ok, meg egy kevés, ami 1G feletti. Meg egy marék 5-6M-s file. Nagyon apró és sok file nincs rajta.

Ötlet, hogy miért lehet ez?

Ezt most nem ertem. deb/lenny alatt, ext3fs: ha egy konyvtarat feltoltok file-okkal, szep sorrendben, majd egyesevel probalom elerni (masolas, feldolgozas, `ls -U`, barmi), akkor teljesen veletlenszeruen jonnek a file-ok. Mondhatni, kriptografiailag is megbizhato veletlenszamgeneratort kapunk... (najo talan nem, de annyira random hogy semmi rendszert nem ve'lek felfedezni benne). Ez viszont igy nyilvan nem az igazi es ez nem kifejezes (lasd: szekvencialis eleres; random seekek; uninterruble sleep, reszponzivitas hianya; diszk elettartama; ...)

Tehat ezt most igy hogy?

Pelda:

#!/bin/sh
mkdir files
for f in `seq -w 1 1000` ; do echo $f > files/$f.dat ;  done
ls -U files | sed 's/\.dat//g' > out

gnuplot> plot 'out' u 0:1 w p pt 2