Naplózó filerendszerek (journaling)

Feltettem az Ubuntu Servert (9.04) egy szoft RAID1 tömbre, 2 HDD 2 partíciójára (md0).
Ugyanezen 2 HDD 2 másik partíciójából pedig egy adat tömb lett (md1).
Illetve további 2 HDD-ből is lett egy újabb RAID1 tömb.

A fájlrendszerek működnek és köszönik jól vannak.
Viszont minden bootoláskor elhasal az fsck rajtuk.
Érdekes, hogy a rendszer tömbre nem ad ilyen hibát csak a két adatra.

A log:
Log of fsck -C -R -A -a
Fri Oct 30 02:26:23 2009


fsck 1.41.4 (27-Jan-2009)
r_base: The filesystem size (according to the superblock) is 119999525 blocks
The physical size of the device is 119999504 blocks
Either the superblock or the partition table is likely to be corrupt!

r_base: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)
r_films: The filesystem size (according to the superblock) is 244190000 blocks
The physical size of the device is 244189984 blocks
Either the superblock or the partition table is likely to be corrupt!

r_films: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)
home: clean, 579/10010624 files, 16785302/40019915 blocks
fsck died with exit status 4

Fri Oct 30 02:26:24 2009
----------------

Ezentúl az fdsik ilyet mond mindhárom tömbre:
Disk /dev/md0: 8587 MB, 8587051008 bytes
2 heads, 4 sectors/track, 2096448 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Disk identifier: 0x00000000


Disk /dev/md0 doesn't contain a valid partition table

A kérdés, hogy mi a probléma okozója és, hogy lehet elűzni?

Adott egy max 8000M méretű rendszerpartíció rajta linux serverrel,
amiről x időnként crontabból futtatva egy használható teljes backup kéne készüljön.
A fájlrendszer ext3.

A dd nem nagyon játszik. Futó rendszerről készült dd-s fájlt még nem sikerült visszaállítanom...

A legkényelmesebb az lenne tar-ral be lehet csomagolni az egészet,
de nem tudom, hogy a jogosultságok, ilyesmik, hogy maradnának meg,
illetve egyeltalán képes-e hozzáférni minden fájlhoz a rendszeren?

Tehát a nagy kérdés az, hogy futó rendszerről, hogy lehet normális (teljes) mentést készíteni?

PS: RAID1 nem játszik, ígyis 5 winyó van a gépben és otthoni szerverről van szó.
Ráadásul szoftveres RAID-del nagy károkat tudok okozni, ha rendszer kerülne rá.

Sziasztok!

Éppen sikerült belerohanni egy ext3 problémába: 32 000-nél több könyvtár készítését érte el egy program egy könyvtáron belül. Tűzoltás gyanánt gyorsan ReiserFS-re cseréltük a fájlrendszert.
Wiki oldalakon nem találtunk arra vonatkozó utalást, hogy egy könyvtáron belül hány könyvtárat tud kezelni a ReiserFS, csupán egy olyan oldalt találtunk, ahol 64 536 alkönyvtár kezelését említi alapesetben. Sajnos nem merjük az adatot kész tényként kezelni, mert olyan dologban is téved a cikk, mint pl., hogy a Slack-en valaha alapértelmezett volt a ReiserFS. A webarchive-on fellelhető egykori ReiserFS oldal sem segít.

Abban kérném a segítségetek, hogy pontosítsátok legyetek, kedvesek azt a számosságot, mely a címben szerepel. Természetesen alapértelmezett esetről van szó. A ReiserFS nem feltétlenül végleges megoldás az esetünkben, de konkrét tényekkel kell szolgálnom a megrendelő felé. Aztán majd szükség esetén XFS-re is válthatunk, ha a megrendelő kevesellné a létrehozható könyvtárak mennyiségét egy könyvtáron belül.

A válaszokat, hivatkozásokat előre is nagyon szépen köszönöm.

Sziasztok!

Bő egy hét Google-zés után úgy döntöttem, felteszem itt a kérdést, hátha találkozott már valaki ilyennel.

Adott egy 250 GB-os külső winchester, ami USB-vel csatlakozik a notebookomhoz. A winchester elsősorban Windows alatt van használva (7, Vista), emiatt összesen 3 NTFS partíció van rajta. Nemrégiben fogta magát és az egyik partíció (ofkoz a legnagyobb, a legtöbb adattal tele) nem működik. Továbbra is létezik, de a Windowsok azt hiszik, nincs megformázva, ezért kapásból felajánlják minden megnyitási kísérletre, hogy ott azon nyomban megformázzák. Ezt természetesen nem engedtem.
Rengeteg (20+) Windowsra íródott helyreállító programot próbáltam, mind látja a partíciót, azt is megmondják, hogy mennyi foglalt, mennyi szabad belőle, de nem tudnak vele mit kezdeni. Én arra tippelek, hogy a fáljrendszerrel/MBR-rel történhetett valami.
Az említett programok az adatok elenyésző részét vissza tudnák állítani, de nagyon lassan és a lényeg, hogy nem mindet. Nos nekem mind kellene. Elméletileg adat nem sérült meg, ugyanis a partíciót nem bántottam, nem formáztam le, stb., minden érintetlen épp emiatt.

Próbálkoztam Linux alatt is. Gparted szintén megmutatja, hogyan is néz ki a partíciós táblám, azt is mutatja, hogy 158GB használt, 29GB szabad az említett primary 1-es partíción.

Fel is tudom mountolni, de üres mappát kapok, holott a Nautilus is mutatja az állapotsoron a szabad hely mennyiségét.

A Google a testdisket és a gpartot javasolta. Testdisk is szépen felismer mindent, de analizálás után hozzátesz két sort, amit másutt eddig nem láttam:

Warning: Incorrent number of heads/cylinder 1 (NTFS) != 255 (HD)
Warning: Incorrect number of sectors per track 1 (NTFS) != 63 (HD)

Erre is próbáltam rákeresni, nem sok segítséget találtam.

Testdisk az Analyse, majd Quick Search után szépen mutatja a 3 partíciót, hibát már nem ír, lent a

Structure: OK

felirat látható.

Ezután engedi a Write funkciót (Write partition table to disk), végre is hajtja szerinte sikeresen. De semmi nem változik látszólag.

Gpart viszont ezt mondja: http://hup.pastebin.com/f34ef5b0c

Erre viszont nem mertem rányomni már semmit, mert nem értem pontosan.

A Windows ellenőrző eszközeit is lefuttattam, darálják egy jó ideig, aztán kilépnek, mert sikeresnek nyilvánítják az ellenőrzést.

Még valami: Testdisk szerint az MBR is tökéletes állapotban van, egyezik a Backup MBR-rel, de azért helyreállíttattam, de semmi nem változott.

Ha bárki látott már ilyet, esetleg tudna segíteni, ne tartsa vissza! Előre is köszönöm!

Hello!

Kaptunk egy jopofa aramszunetet, ami az UPS-t is hazavagta (meg nyomozzuk)

Nem tudok mount-olni egy particiot, mert:

# mount /dev/fslv00 /dba
Replaying log for /dev/fslv00.
open: Device busy
mount: /dev/fslv00 on /dba: Unformatted or incompatible media
The superblock on /dev/fslv00 is dirty. Run a full fsck to fix.

FSCK-ra:

fsck /dev/fslv00

The current volume is: /dev/fslv00
Primary superblock is valid.
*** Phase 1 - Initial inode scan
*** Phase 2 - Process remaining directories
*** Phase 3 - Process remaining files
*** Phase 4 - Check and repair inode allocation map
File system inode map is corrupt; FIX?

Merjek Y-t nyomni?

AIX Version 5.3 with Oracle 9.2.0.7 a kornyezet.

Üdv mindenkinek, remélem jó topicba írom a problémámat. Van egy ntfs partícióm ami fedora 10-ből hibátlanul működik ntfs-3g-velazonban a windows 7 (7100-as build 64 bites, ms oldaláról szedett) egy áramszünet óta minden bootkor ellenőrzi, elvileg javítja a hibákat is. Azonban csak a betűjel látszik, tulajdonságoknál "raw"-ot ír, valami olyasmi a hibaüzenet hogy "this file system is corrupted and not accessible for Windows". Próbáltam a felügyeleti eszközök-lemezkezelésben felmountolni, de csak formázni engedné. Hagy a chkdsk egy logfilet bootex.log a kérdéses partíción. Nem igazán tudom hogyan lehetne rávenni a win7-et hogy lássa a partíciót, minden segítséget előre is köszönök.

[szerencsetlenkedes update:]
Mivel tovabbra sem sikerult ravenni a win7-et a particio csatolasara, az alabbiakkal probalkoztam:
testdisk, getdataback latja a fileokat, tesdiskkel probaltam javitani, semmi sem valtozott. Ezekutan ezeket probaltam meg:

C:\Windows\system32>fsutil dirty query g:
Error: The file or directory is corrupted and unreadable.
Error: The parameter is incorrect.

C:\Windows\system32>chkntfs g:
The type of the file system is NTFS.
Cannot query state of drive G:

Tehat chkntfs szerint ntfs a filerendszer.

C:\Windows\system32>fsutil fsinfo ntfsinfo g:
Error: The file or directory is corrupted and unreadable.
The FSUTIL utility requires a local NTFS volume. Fsutil szerint meg nem az, vagy en ertem felre?
Probaltam meg a boot menu repair windows-os inditast is, onnan futtattam egy chkdsk /f g:-t, legnagyobb meglepetesemre jopar hibat javitott amit egyebkent bootkor nem szokott. Rebootoltam, semmi...tovabbra is chkdsk minden inditaskor, g: tartalma meg sehol. Eventviewerben rengeteg ilyen hibauzenet:
Error 7/26/2009 1:41:47 PM Ntfs 55 (2)
Tovabbi tippeknek nagyon orulnek, mert kezdek kifogyni az otletekbol.

osod88

reiserfs.

spark:/var/mail/gujhely/.Trash.Junk# ls -lisA
total 1372
   ?    ? ?--------- ? ?       ?             ?                ? courierimapacl
   ?    ? ?--------- ? ?       ?             ?                ? courierimapkeywords
6437 1372 drwx------ 2 gujhely gujhely 1404984 2008-04-24 01:13 cur
   ?    ? ?--------- ? ?       ?             ?                ? maildirfolder

Minden (rsync, find) panaszkodik, hogy no permission to read.
Törölni simán rm paranccsal nem tudom, mert no permission.

spark:/var/mail/gujhely/.Trash.Junk# rm maildirfolder
rm: cannot remove `maildirfolder': Permission denied

Mit lehet tenni azon kívül, hogy az ember létrehoz egy új logikai kötetet, átmásol mindent, ami jó, a régit meg megszünteti?

reiserfsck?
debugreiserfs?

Évek óta nem használok reiserfs-t, és amikor még igen, akkor se volt hasonló problémám.

G

Hello mindenkinek.

Segítséget kérnék egy xfs filrendszerben bekövetkezett adat vesztéshez, alább részletezve a történetem:

Van egy ubuntu severem szoftveres Raid5 tömbbel (adattárolás) ami xfs-el használtam, a rendszer egy 8gb-os pendrive-ról futott (0 swappynes-el, 2GB rammal) mostanáig. Történt ugyanis hogy valami oknál fogva az alaplapom hálókártyája nem akart továbbiakban hálózatról felébredni (WOL). Ekkor jöttek a nagy disztró cserélgetések telepítgetések /etc-ben turkálás, satöbbi. (ekkor még hiánytalanul megvolt minden) Egy idő után ráuntam a hiábavaló próbálkozásokra és úgy döntöttem hogy visszaállítok mindent a régibe wol nélkül. és a pendrive -ra visszamásoltam dd -vel egy szűz ubuntu 8.04 servert amit korábban telepítettem majd lementettem dd -vel (az utolsó próbálkozásnál egy 9.04 ubuntu volt fenn) ekkor mindent összeraktam majd meglepve tapasztaltam hogy a gép nem akar rendesen indulni kidobott egy konzolt hogy az raid tömbön lévő xfs filerendszer hibás és nem mountolható javitsam manuálisan. Itt még az gondoltam, hogy semmi gond egy xfs_check majd xfs_repair de nem nem oldotta meg. Ekkor kómás fejjel (mert persze mikor szórakozzon az ember egy 2 TB -os adattömbel rajta minden adatával) ha, nem az éjszaka közepén. Egy szó mint száz gondoltam miért ne telepítsem újra a rendszert az majd megoldja (rossz gondolat, nagyon rossz) a telepítés lefutott majd mikor ellenőrizni akartam az adataimat a csatolási ponton nem talált semmit......... A df meg azt jelezte hogy "Minden oké van 2 terra helyem.............."

Remek

Szóval megkérdeznék valaki xfs terén járatosabb embert hogy mit lehet egyáltalán ilyenkor csinálni? A tömb majdnem tele volt eltűnése előtti időszakban szóval elég sokat vesztenék.

Kérlek ha tudtok bármilyen megoldást segítsetek.

Bármi egyéb adat terminálkimenet, stb... kell írjátok és posztolom.

Update:

Az eredeti rendszernek megvan még az image-e azt az elején gondosan lementettem dd-vel.

Update 2:

Üdv mindeniknek!

Probléma megoldva!

Dióhéjban hogy mi történt a legutóbbi poszt óta. Mivel semmi használható ötlet nem került elő ezért jegeltem mindent, a 3 darab terrabyte-os merevlemez a polcra került. Úgy terveztem hogy, pár hónap múlva újra nekiesek de édesanyám időközben bekövetkezett halála miatt mindennel felhagytam. Ezért most már lassan 3/4 évvel később estem újra neki a dolognak. Azzal a felkiáltással hogy vagy megoldom a problémát vagy elkezdem másra felhasználni a meghajtókat. Testdisk -el próbálkoztam, a régi pendrive ISO -kal, de semmi sem használt! Feladtam és az egyik meghajtót le is zéróztam hogy máshol felhasználjam, pár hét múlva meg jött volna a többi de úgy gondoltam hogy még egyszer utoljára körbenézek a neten hátha találok valamit... Nos találtam! A wikipedia xfs bejegyzése alatt megemlítették hogy már van egy xfs undelete/recovery program ami meglehetős biztonsággal használható. Mondtam üsse kő megpróbáljuk. Igen ám de a program Windows -on fut no mármost hogy a bánatba rakom össze a raid tömböt  Windows alatt? Szerzek egy 2 TB-s meghajtót és dd-vel átmásolom oda hogy a Windows lássa? Abban a formában kissé drága mulatság lett volna (2TB seagate KB 44000HUF) tekintve azt is hogy a program is fizetős! De szerencsére nem adtam fel ilyen könnyen és ekkor észrevettem hogy a programnak van egy opcionális raid plugin-je amivel össze lehetne állítani a tömböt (bár már csak 2 meghajtó volt érintetlen de a raid5 miatt nem volt probléma). Ekkor fogtam magam és az asztali gépemre telepítettem Vistát egy még szüz winchesterre. miután eljutottam a program használatáig (és végigvártam a millió patch lejövetelét... lol)

Mivel a program is és a plugin is fizetős volt ezért óvatos voltam és először megnéztem hogy a raidet tényleg összetudja -e rakni mert addig semmi értelme megvenni. Szerencsére az összeállítás sikerült és talált egy xfs partíciót. De megnyitni nem tudja, mert ugye trial a szentem. Itt vettem egy nagy levegőt és megrendeltem a licenszet a plugin-hoz. Ami érdekes módon nem volt a legsimább de 1 órán belül megjött úgyhogy kipróbálás és indítás. A tömb összeált recovery indít majd 12 óra várakozás (hát 2TB-hez kell is idő). Szóval minden lefut és talál is adatot 1.8 TB mennyiségben ekkor megrendeltem a recovery-hez is a licenszet folyamat ugyan az. mentés elindít... egy idő után arra lettem figyelmes hogy az egyik inodexxxxxxxx könyvtár alól szabályosan másolja ki az adatokat. AZ EREDETI KÖNYVTÁR STRUKTÚRA SZERINT! Ekkor megnéztem azt az alkönyvtárt, és az államat a padlón hagytam! Ott volt minden érintetlenül! A teljes adat állomány minden ugyan úgy!

Ezek után úgy hiszem summázhatjuk hogy a raid hibátlanul üzemelt, csak a filerendszer "sérült" meg (bár a "sérülni" sem helyes kifejezés egyszerűen annyi volt hogy az inode táblán minden nullázódott)

Van erre mód?

ext3, kb. 92G méret.

gép single user módban, filesystem unmountolva (feltételezem, mert egyébként nem tudtam volna kinyírni)
épp backuphoz készítettem volna el az új external hdd-t, de figyelmetlen voltam, és a mkfs.ext3 nem az external, hanem a rendes hdd-n futott. :-(

Ezután (amikor reggel konstatáltam, hogy ez bizony el lett írva), elindítottam egy másolatot dd-vel. Most épp itt áll a dolog, Fut a dd.

Teljes backup nincs az elveszett tartalomról, csak kb. 30G

Nagyon örülnék, ha a korábbi tartalom helyreállítható lenne.

+1: jó lenne valami olyan tool, ami nem esik kétségbe, ha hibás blokk van a vinyón, mert az eredetin, pont ezen a partíción van 106 bad block. (Ezt is tegnap vettem észre, épp a szokásos 30G-s backup készítés során, ezért is akartam készíteni egy full backupot)

Tippem szerint a dd el fog hasalni a hibás blokkokon, majd újra kell futtassam hiba kihagyással, vagy dd_rescue-t, de ez most részletkérdés. Tegyük fel, hogy van másolatom a partícióról, és a másolaton tudok dolgozni.

G

Sziasztok!

Olyan linuxos fájlrendszerre vagy kernelbeállításra vagy egyéb megoldásra lenne szükségem, ami az ls -laR -t nagyon gyorssá teszi tízezer könyvtárra és egy egymillió fájlra (nem egyenletes eloszlásban). Az optimális megoldás futásideje összemérhető kéne, hogy legyen azzal az idővel, amit az ls -laR hatására a kernel lemezolvasással tölt, de seekelés nélkül, tehát mondjuk max 10 másodperc.

Úgy sejtem, hogy az ls -laR -ből az -l kapcsoló a lassú, mert az minden fájlra hív egy stat()-ot, és mivel az egyes fájlok inode-jai nincsenek közel egymáshoz a lemezen (legalábbis ext3-on, ext4-en és reiserfs-en), ezért minden egyes stat()-hoz seekelni kell, ezért lassú. Az inode-ok szekvenciális egymás mellé pakolásával az ls -laR sokat gyorsulhatna. Van ilyen fájlrendszer vagy beállítás?

Kösz:

pts