Új hozzászólás Aktív témák

• #3478 bambano titán GD #3477

  Új Válasz 2007-05-20 15:55:56 #3478

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  bambano

  titán

  LOGOUT blog

  válasz GD #3477 üzenetére

  ''mindezt csak véleménycsereként nem kötekedés vagy okoskodás'': ne aggódj, majd hétfőn felébrednek a linux fanok és fogok kapni hideget-meleget, hogy rosszat mertem szólni a kernelre
  
  ''azért nem gondolom hogy túl nagy veszteség lenne a naplózó történet'': naplózó filerendszer elképzelésem szerint kétféleképpen működhet:
  
  1. - jön adat, leteszik az adatot a metadata (a journalba) területre
  - leteszik a szükséges rendszerterület változtatást a metaadat területre (inode-ok, clusterek, stb).
  - átmásolják a metaadat területről az adatot a rendes helyére
  - átmásolják a metaadat területről a rendszerterület változtatásokat a rendszerterületre
  - adminisztrálják a journalt
  2. - jön az adat, leteszik a végleges helyére
  - a rendszerterület változtatást leteszik a metaadat területre
  - a rendszerterület változtatást végrehajtják a rendszerterületen
  - adminisztrálják a journalt.
  
  Ezzel szemben az ext2-nél lerakják az adatot a végleges helyére és lerakják a rendszerváltozásokat a végleges helyükre. Ez pont fele annyi lemezio művelet.
  
  Ami már nem az én elképzelésem, hanem az én mérésem, hogy ez nagyságrendileg 40-50% teljesítményvesztés, minél kisebb gépen és minél gyengébb hdd-vel nyomod, annál látványosabban lassú a naplózás. Én pont a felét mértem a gépemen. Amíg valaki nem mutat egy 200MB/sec fölötti írási végeredményt bonnie++ kimenetben, addig pesszimista vagyok a naplózós rendszerek írásával kapcsolatban. Az olvasás vélhetőleg nem lassul jelentősen, tehát egy ext3-ról fat32-re másolás az simán lefuthat teljes sebességen.
  
  Elfogadom, ha azt mondod, hogy neked a felezett teljesítmény nem észrevehető, irigyellek a gépedért. De ne szvsz legyen hanem konkrét mérés.
  Szerintem a hw nem előzött sehova, a kernel simán kihajt mindent a vasból, ami benne van.
  
  A raid, lvm, ext3, xfs, reiser4 használata esetén azt lehet állítani, hogy ha és amennyiben a tisztelt programozók nem rontottak el semmit az adott alrendszer programkódjában, akkor az adott alrendszer a tőle elvárt előnyöket nyújtja.
  
  Na ezen szokott megbukni a dolog, mostanában annyi ótvaros pocsék kód került a kernelbe, hogy sírhatnékom van. Ennek van pl. olyan eredménye, hogy megdöglik a raid1 kötet második diszkje, ami lehúzza az egész gépet, elérhetetlen, használhatatlan lesz tőle minden. Pedig a raid1-nek elvileg a rendelkezésre állást is javítania kellene diszkhiba esetén, de nem, hanem ettől omlik porba a gép.
  
  Vagy: diszk hiba miatt megdöglik raid1, szabályosan kicserélem a diszket, újraindítom a gépet és pillanatok alatt felbootol. Majd pár óra múlva megomlik az egész. Alapos vizsgálat után kiderül, hogy a frissen berakott lemezt a raid1 nem szinkronizálta, maradt üresen. Minden olvasási művelet, ami a második lemezen zajlott, 0-val feltöltött szektorokat olvas be, ettől a bináris programokban folytonossági hiba keletkezik és értelmezhetetlen problémák kerülnek elő. Végül az egész összeborul. Visszabootolva egy korábbi kernelt, pár óra alatt lemegy a szinkronizálás és utána megy minden korrekten.
  
  Vagy: mostanában valami olyan baja van a raid kódnak, hogy ha kidöglik a diszk alóla, megpróbálja szinkronizálással helyrehozni. Na ettől szépen megáll az egész blokkos eszköz, mint a szög.
  
  Nem merném azt állítani, hogy minden fejlesztő mindig gondolkodik és mindig helyes eredményre jut. Szoktunk néha agyhalottazni, nem minden ok nélkül. Fentiek megtörtént esetek, tehát aki vitatkozni akar vele, annak azt kell bizonyítania, hogy vak vagyok vagy hazudok. Meg azt is, hogy az általam leírt hibára a hivatalos kernel changelogban adott magyarázat nem igaz.

Új hozzászólás Aktív témák