ext3 nyűg

Linux-kezdő

Hi!

Bocsi, ha nagyon láma a kérdés, de ma az egyik gépen ez fogadott a konzolon:

EXT3-fs error (device hda3): ext3_free_blocks: Freeing blocks in system zones - Block = 8388608, count = 1 Aborting journal on device hda3.
ext3_free_blocks: aborting transaction: Journal has aborted in __ext3_journal_get_undo_access<2>EXT3-fs error (device hda3) in ext3_free_blocks: Journal has aborted ext3_reserve_inode_write: aborting transaction: Journal has aborted in __ext3_journal_get_write_access<2>EXT3-fs error (device hda3) in ext3_reserve_inode_write: Journal has aborted

Ez még néhányszor, majd.

Journal has aborted
EXT3-fs error (device hda3) in ext3_delete_inode: Journal has aborted
ext3_abort called.

__journal_remove_journal_head: freeing b_committed_data
EXT3-fs abort (device hda3): ext3_journal_start: Detected aborted journal
Remounting filesystem read-only

És tényleg ro lett. Ez nagyjából milyen hiba? Úgy értem hw/ sw? Ez kb. egy 4- 5 hetes partíció, nagyjából átlagos terheléssel. Logot megnéztem, de a fentieken kívül mást nem nagyon tartalmaz. Mit érdemes ezzel tenni? Simán remountoljam rw- re, vagy reboot, vagy mentés után formázzam újra a partíciót?

Köszi a válaszokat.

  • 2151 megtekintés

Hi!

A fenti probléma egy adat (/data/) partíción jelentkezett, és aztán többet nem (egy sima restarttal oldódott meg). Utána viszont kb. 3 naponta a / partíció csinál egy olyat, hogy read- only lesz. Az lenne a kérdésem, hogy ez mitől lehet? Eddig ilyennel nem volt még dolgom. Mondjuk ez még nem is lenne baj, mert ez egy kis gép, összetákolt debian, lehet, hogy kicsit hibás a hardvere, viszont a főgépemen egy jó régen telepített debian van, és eddig semmi gondja nem volt. Viszont ma reggel harmadszor fogadott az a kép, hogy RO lett a gyökerem. Ezt nem akarom újraindítani, ilyenkor mindig csinálok egy 

mount -o /dev/akarmi / remount,rw

- t, ami látszólag működik is, gyakorlatilag is, de hogy tudom kideríteni az okát, és leginkább megszüntetni a problémát? Persze, olvasnék logot, de RO rendszerre nem ír logot. Ha továbbra is jelentkezik, a log könyvtáramat átrakom egy másik partícióra, de jó lenne, ha lenne valakinek ötlete. A 2 gép amúgy egymás mellett van, de gondolom nem levegőben terjed :- ). Tudom, sokat segíteni a pontos hibaüzenet, de az most nincs meg. Majd a köv. esetnél talán.

Üdv!

Ma megint előfordult, immáron negyedszer. Egyelőre nem mountoltam vissza rw- re, hátha tudtok valamit mondani, hogy mit nézzek meg. 


 ls --sort=time -lr /var/log/

-rw-r-----  1 root              adm         5370 2007-02-21 06:25 kern.log
-rw-rw-r--  1 root              utmp       17280 2007-02-21 23:51 wtmp
-rw-r--r--  1 root              root       12192 2007-02-23 01:31 samba-log.smbd
-rw-r--r--  1 root              root       11152 2007-02-23 01:31 samba-log.0.0.0.0
-rw-r-----  1 root              adm         3696 2007-02-23 01:31 mail.warn
-rw-r-----  1 root              adm       853224 2007-02-23 06:30 cron.log
-rw-r-----  1 root              adm       491149 2007-02-23 06:30 messages
-rw-r-----  1 root              adm       195981 2007-02-23 06:30 daemon.log
-rw-r-----  1 root              adm       364878 2007-02-23 06:30 auth.log
-rw-r-----  1 root              adm       814915 2007-02-23 06:30 syslog
-rw-r-----  1 root              adm       397708 2007-02-23 06:30 mail.log
-rw-r-----  1 root              adm       397572 2007-02-23 06:30 mail.info
-rw-r-----  1 root              adm        27714 2007-02-23 06:30 debug
-rw-r-----  1 root              adm         5165 2007-02-23 21:31 mail.err
-rw-r-----  1 root              adm        16210 2007-02-23 22:42 user.log
drwxr-xr-x  2 root              root        4096 2007-02-24 01:00 ntpstats

[code]


[code]
 ls --sort=time -lr /var/log/ntpstats | tail -n 10
-rw-r--r--  1 root root  91356 2007-02-22 00:59 peerstats.20070221
-rw-r--r--  1 root root  68756 2007-02-22 00:59 loopstats.20070221
-rw-r--r--  1 root root  96301 2007-02-23 00:59 peerstats.20070222
-rw-r--r--  1 root root  72481 2007-02-23 00:59 loopstats.20070222
-rw-r--r--  1 root root  93463 2007-02-24 00:59 peerstats.20070223
-rw-r--r--  1 root root  70343 2007-02-24 00:59 loopstats.20070223
-rw-r--r--  2 root root  25099 2007-02-24 06:34 peerstats.20070224
-rw-r--r--  2 root root  25099 2007-02-24 06:34 peerstats
-rw-r--r--  2 root root  18859 2007-02-24 06:34 loopstats.20070224
-rw-r--r--  2 root root  18859 2007-02-24 06:34 loopstats

Szóval elvileg még reggel fél 7- kor minden jó volt.
6.25- kor szokott elindulni cron- ból egy updatedb &, az általában nem végez 9 perc alatt, bár nem tudom mennyire lehet összefüggés.

Ha tudtok valami okosat mondani, nagyon hálás lennék :- ).

Köszi.

nem hiaba rakja at ro-ba, az adatvesztest szeretne elkerulni

kerek szepen "df -h" es "mount" kimenetet es egy dmesg-et(eleg az utolso 10-20 sor is talan, de nem arthat az egeszet latni). ha lehet a dmesget inkabb linkeld be valahonnan kivulrol, mert hosszu lesz nagyon ide :)

hatha latunk beloluk valamit

--
whatever

Hi!

http://213.178.121.35/ext3_nyug/

Nem tudom ez mennyire aktuális. Ma dél körül már nem tudtam visszamountolni, és rebootoltam. Természetesen jött a prompt, hogy fsck- t futtassak. Lefuttatam, sok mindent csinált, aztán rebootoltam, és azóta ez van. Azóta nem volt hiba egyelőre.

Hogy tudom megtudni, hogy HW- hiba? Azon kívül, hogy dd- vel végigmegyek az egészen? A kis gépnél elég valószínű, hogy HW hiba, de itt nem örülnék neki.

Távoli logot terveztem, de gondoltam megvárom, amíg etch stable lesz, bár ki tudja, hogy az mikor lesz... .

Köszi.

dmesg igazabol a hiba utan kovetlenul lenne erdekes, de igy is kiderult, hogy nem artana minden particiot fsck-zni, termeszetesen single user modban.

aztan azt islatom, hogy elegge kozelitesz a 100%-os helykihasznalashoz es azert a normal mukodeshez ext3-nak kell egy adag szabadhely (gondolom ezert nem engedi alapbol fullra teleirni) szerintem vagy torolj valamit, vagy noveld meg a helyet :)

szoval helycsinalas fsck es ha meg mindig rosszalkodik, akkor valoszinu, hogy hw hiba, nezd meg akkor majd egy biztosan jo kabellel eloszor

--
whatever

Nem tudom pontosan hogy működik azt ext3, de 5% fenn van tartva csak a root felhasználónak, szóval ha a df 0%- ot is mutatna (vagyis 100%- at), akkor is lenne még egy csomó hely, amit a kernel használhatna. fsck- kat most futtattam single user módban, csak a /- t tartalmazó partícióra volt hibás, a többi OK volt. Holnap szerzek jó kábelt.

( tr1719 | 2007. 02. 26., h – 20:03 )

Hi!

Átirányítottam a logot egy másik gépre, és pár sikerült is kapnom egy ilyet: 


hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=30075539, high=1, low=13298323, sector=30075534
end_request: I/O error, dev hda, sector 30075534
EXT3-fs error (device hda3): ext3_get_inode_loc: unable to read inode block - inode=934102, block=1867788

Ez szerintetek mindenképpen HW hiba? Vagy egyáltalán mi ez? Ha igen, akkor hogy tudom dd- vel megpróbálni kiolvasni az adott szektort? Vagyis ez hol pontosan?

Köszi.

"DriveReady SeekComplete Error"-t és "UncorrectableError"-t nekem a DVD olvasó szokott küldeni amikor nem tudja olvasni a kutya szájából előrángatott DVD-imet. Tehát valószínűleg nálad is hibás szektort jelent (vagy hibás IDE vezérlő / kábel / diszk elektronika). Vagy valami más. :)

Igen mindenkepp, a hda-d nem talalja a 30075539-es szektort. (egy esetben lehet valami mas, hogyha nagyobb particiot raktal ra, mint a diszk fizikai merete -- nem tudom hogy?an -- es most a vege utan keresget... :-), de szerintem nyugodj bele, kezd szarramenni a winchestered...)

Szerintem ne az adott szektort probald kiolvasni, hanem minel elobb lementeni az osszes mashonnet nem potolhato cuccodat, esetleg a teljes winchestert: dd noerror /dev/hda /dev/hdb

Zsiraf

Nem akarok flamet indítani, de milyet érdemes venni?

Ez valami maxtor, talán másfél, vagy 2 és fél éves. Mielőtt egyesült a nem tudom melyik másik céggel, tök jó vinyókat gyártott, az összes vinyóm maxtor, és egyiknek sincs semmi baja, van még 2 működö '98- as 6GB- s quantum fireball, semmi bajuk, viszont ez már úgy indult, hogy megvétel után vittem vissza, hogy hibás, s kicserélték (állítólag), és most 2 év után nem bírja. Milyen ajánlotok? A Western Digital Caviarról hallottam jókat, pl.: http://www.westerndigital.com/en/products/products.asp?driveid=159&lang… , csak hát nekem már 2 sata kábelem is elolvadt munkahelyemen (itthon még IDE van; amúgy még azt nem próbáltam cserélni, okozhatja a kábel a fenti hibát), lehet jó minőségű SATA kábelt kapni, mert ez a piros nálam nem nagyon jön be.

Köszi.

Seagate természetesen. Nekem is ban egy 120G-s maxtorom, de félek, hogy egyszer bekrepál csak úgy. (Volt már 1-2 érdekes jelenség vele.) Viszont van egy kb '94-es pc, abban egy fél gigás seagate van, és a mai napig működik. :) (Nagyon durva egyébkét, hallani, ahogyan szép nyugodtan felpörög. :))

Az nagyon szeretem/nem szeretem dolog.
Amit tudok mondani, hogy vettem mostanába tizendarab low-end seagate-et és kettő meghalt pár héten belül. Szval az arány nálam nem olyan jó, bár a kereskedő ( :) ) megesküdött rá, hogy nagyon jó, és nincs velük probléma. WD, Samsung is van néhány új, azzal nem volt gond. De ez korántsem reprezentatív vélemény ;) Legyen mentés, raid, stb ha fontos az adat.

( tr1719 | 2007. 08. 10., p – 22:16 )

Sajna újra előjött a fenti hiba, tehát a kisgépen a /- em readonly lett, és hiába mountolom vissza rw- vé, ~2 perc után újra ro lesz. Egy fsck val. megoldaná, de az lenne a kérdésem, hogy menet közben mennyire lehet. Tehát a gyökérről van szó, sokan olvasnak róla, folyamatosan (pl. apache, nfs, stb), mennyi/ milyen kárt tud okozni, ha a gyökeret fsck- zom menet közben? Egy újraindítás nyílván jobb lenne, de azt most nem túl egyszerű megoldani :- ).

Futó rendszeren fsck olyan mind windows alatt a scandisket elindítani. Gyors particiohalal:-)
Mindenképp single-userben futtasd az fsck-t.
Inkabb legyen szerveridoben kieses(mertugye tolsz egy full backup-ot ekkor gondosan es elorelatoan) mint nullarol kezdett particio, adatok nelkul.

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

( reznor | 2008. 01. 08., k – 11:50 )

Hi!

Asszem elég hasonlatos a problémám... Sajna.

Az alábbi részlet a dmesg-ből van:

EXT3-fs warning (device hdb1): ext3_clear_journal_err: Filesystem error recorded from previous mount: IO failure
EXT3-fs warning (device hdb1): ext3_clear_journal_err: Marking fs in need of filesystem check.
EXT3-fs warning: mounting fs with errors, running e2fsck is recommended
EXT3 FS on hdb1, internal journal
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
ACPI: Power Button (FF) [PWRF]
ACPI: Power Button (CM) [PWRB]
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
IPv6 over IPv4 tunneling driver
eth0: no IPv6 routers present
journal_bmap: journal block not found at offset 4108 on hdb1
Aborting journal on device hdb1.
ext3_abort called.
EXT3-fs error (device hdb1): ext3_journal_start_sb: Detected aborted journal
Remounting filesystem read-only
__journal_remove_journal_head: freeing b_frozen_data
__journal_remove_journal_head: freeing b_frozen_data
__journal_remove_journal_head: freeing b_frozen_data
__journal_remove_journal_head: freeing b_committed_data
__journal_remove_journal_head: freeing b_frozen_data
__journal_remove_journal_head: freeing b_frozen_data
__journal_remove_journal_head: freeing b_frozen_data

A lényeg, hogy ftp-zni próbálok, megy egy darabig, aztán puff leakad, merthogy a filerendszer read-only lett...

Benyomom a mount parancsot, kiírja, hogy ext3fs és rw. Persze írni nem lehet rá... Akkor most mi van?

Gondoltam küldök rá egy fsck-t... Umount /dev/hdb1 és kapom az üzit, hoyg nem lehet, mert használatban van. Abszolut nem használja senki és semmi...

Most az fsck-t futtatom rajta: fsck -pfv /dev/hdb1 paranccsal és csinálja, úgy tűnik...

Mi a tippetek? Régi wd 60gigás vinyó, ős sok kilóméterrel a háta mögött... Eljött talán a szörnyű vég???

Esetleg próbálkozzak ext2-vel? vagy reiserfs? mit használjak, és van -e értelme kínlódnom vele?

Előre is köszi: rez

Javitsd ki , maradj ext3-nal, mert azt lehet legnagyobb esélyel viszaállitani.

hdparm belitásánál a
-W Get/set the IDE/SATA drive's write-caching feature.
kerüld.

smartctl --all /dev/vinyo mondhat erdekeset.

Esetleg frissitsd a kernelt, ha azota javitottak ext3 vagy vinyovezerlodet erinto bugot.

Hát ez ennyit adott:

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_ FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000b 200 200 051 Pre-fail Always - 0
3 Spin_Up_Time 0x0007 120 104 021 Pre-fail Always - 3066
4 Start_Stop_Count 0x0032 098 098 040 Old_age Always - 2234
5 Reallocated_Sector_Ct 0x0033 199 199 140 Pre-fail Always - 1
7 Seek_Error_Rate 0x000b 200 200 051 Pre-fail Always - 0
9 Power_On_Hours 0x0032 067 067 000 Old_age Always - 24316
10 Spin_Retry_Count 0x0013 100 100 051 Pre-fail Always - 0
11 Calibration_Retry_Count 0x0013 100 100 051 Pre-fail Always - 0
12 Power_Cycle_Count 0x0032 098 098 000 Old_age Always - 2060
196 Reallocated_Event_Count 0x0032 199 199 000 Old_age Always - 1
197 Current_Pending_Sector 0x0012 200 200 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0012 200 200 000 Old_age Always - 0
199 UDMA_CRC_Error_Count 0x000a 200 253 000 Old_age Always - 602108
200 Multi_Zone_Error_Rate 0x0009 200 200 051 Pre-fail Offline - 0

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA _of_first_error
# 1 Short offline Completed without error 00% 489 -

Device does not support Selective Self Tests/Logging

Mit jelent a type: pre-fail vagy old_age felíratok?

Kimentettem az adatokat, töröltem a partíciót, létrehoztam egy új ext3-at és mkfs-el megcsináltam, majd lefuttattam az alábbi parancsot mégegyszer:

fsck -pfvc /dev/hdb1 (c paraméter: a bad blockokat is keresi) tehát egy teljes surface test-et csináltam magyarul.

Eredménye: nincs bad block, minden tökéletesnek tűnik.

Visszamountoltam a helyére, elkezdtem visszamásolni a file-okat.

Remélem meggyógyult és nem kell többet ebbe a topicba írnom...