- This topic has 23 hozzászólás, 4 résztvevő, and was last updated 9 years, 10 months telt el by
.
- Bejegyzés
3 - A fájl egy rsync-cel létrehozott távoli szerver fájlrendszermásolata volt, és a forrás fájlrendszeren nem jelentkezett törlési probléma. Ott a fájl egy szabvány html fájl volt.
A logikád alapján a gépeden is egy szabvány, törölhető fájl kellett volna, hogy legyen. És mégse az volt.
A forrás nem volt törölhetetlen, a másolat már az volt, ebből gondoltam, hogy a másolatot tároló fájlrendszerrel lehet probléma. Ezt megerősítette még a másolat jellemzőinek eltérése az eredetitől, és eléggé furcsa voltuk is.
ebből gondoltam, hogy a másolatot tároló fájlrendszerrel lehet probléma
Szerintem nem a fájlrendszerrel volt gond, de ezt már sose tudjuk meg. Ha legközelebb ilyesmibe futsz, inkább kérdezz, mielőtt mindent legyalulsz.
Azt hiszem, akkor a képzelőerőm is korlátos. Mivel lehetne még ilyen esetben probléma?Egy fájlrendszertől azt várjuk el, hogy minden körülmény esetén konzisztens maradjon, és a tárolt fájlokat - vagy azok lehető legnagyobb részét - visszaadja.Egy nem kezelhető fájl-t a fájlrendszer semmilyen körülmény esetén sem lenne szabad, hogy tároljon. Vagy tévedek?Sajnálom már én is, hogy legyalultam, de a meglévő tényekhez én semmilyen más teóritát sem tudok elképzelni. Egyedül a véletlenszerű hardver hibát tartanám még lehetséges oknak, de azóta több teszt is lefutott a meghajtón, és semmit nem jeleztek.
Úgy gondolod, hogy egy egészen betesztelt fájlrendszer (ext4) egy ilyen egyszerű hibát vétsen? Én speciel nem hiszem.Nem tudom a hátterét a dolgoknak, de inkább tudnám elképzelni, hogy valami véletlenül belepiszkált a mentési folyamatba, vagy esetleg valami külső dolog piszkált be, esetleg egy szkript véletlenül rosszul futott le, stb.
Lehetséges olyan scriptet írni, ami inkonzisztenssé tesz egy fájlrendszert? Ha igen, akkor számomra ez is elég nagy meglepetés. Nálam csak perl és bash scriptek futnak, alap io kezeléssel. Semmi bináris matatás. Főleg nem a mentési területeken.A szinkronizálás közbeni hibát is kisebb valószínűségűnek látom, hisz ha az rsync valamit nem tud lemásolni, akkor gondolom, nem másolja le. Ha jól tudom, másolás közben ideiglenes állományban tárolja az adatokat, és csak a sikeres átérkezés után helyezi el azt a végleges nevén. Ettől persze ez a folyamat is lehet hibás, de hogy az ext4- vagy az rsync-e a teszteltebb, azt nem tudnám megtippelni.
Nem, nem azt mondtam, hogy bármi is “inkonzisztenssé” tette a fájlrendszert. Szerintem a fájlrendszerrel nem történt semmi baj, csak valami létrehozott rajta egy fura nevű fájlt (bármit is jelentsen a “fura” jelző), és esetleg beállította az immutable flag-et. Mint mondtam, tényleg nem látom, mi és hogy fut nálad, ezek csak feltételezések - úgy, hogy hardverhibát nem tartok valószínűnek, ext4-hibát nem tartok valószínűnek, rsync-hibát nem tartok valószínűnek.A bash szkriptek hívnak külső bináris fájlokat, gondolom. Esetleg valamelyik szkriptben történik egy rossz értékadás, esetleg valami hibát eredményezett (pl. egy pillanatra nem volt írható egy fájl, vagy épp véletlenül rossz könyvtárba keveredett, stb.), annak a fals kimenetét felhasználod. Vagy esetleg egy ls parancs olyan fájlokat is talált, amelyek nevében szóköz vagy valami speckó karakter van, amit rosszul dolgoz fel, stb.Én inkább valami ilyesmi hibára gyanakodnék.
Igen, értem, de a scriptjeim évek óta futnak, és ez egy mentést végző szerver, tehát nem túl szofisztikáltak. Másrészt ebből az irányból úgysem tudom már kideríteni, mi történt, ezért én a másik oldalról közelítetem meg.Ez egy nagy mentési terület n. almappájában egy fájl volt. Elég minimális a valószínűsége, hogy véletlen eredményeként épp ennek a fájlnak a neve jött volna ki valamelyik scriptben, vagy valami hiba okán.Másodszor: tény, hogy piros volt a fájl az mc-ben, ?-es, és 0 méretű valamint attribútumú. Az immutable flag nem csinál ilyent egy fájllal.Azt is kérdezhetném akkor, hogy milyen tevékenység képes ezt végezni egy fájllal úgy, hogy nincs valós esélye, hogy ezt a fájlt az rsync másolása után bárki is érintette volna?Nekem itt a sok minimális esély közül mégis az ext4 hibája a legvalószínűbb.Főleg úgy, hogy egy ext3 hibát már sikerült átélnem: mikor nagy csindadrattával bevezették az ext3-at, és kifejtették, hogy a naplózás miatt csak a még ki nem írt fájlok és adataik veszhetnek el, akkor egy egészséges áramszünet után úgy omlott össze az egész ext3 fájlrendszerem, ahogy volt. És nem csak néhány fájl sérült meg ... Azóta kissé tartok a tesztelt fájlrendszerektől.
Igen, értem, de a scriptjeim évek óta futnak
Az ext4 is évek óta van. Ráadásul az ext4-et (szerintem) többen használják, mint a szkriptjeidet 😉
Elég minimális a valószínűsége, hogy véletlen eredményeként épp ennek a fájlnak a neve jött volna ki valamelyik scriptben, vagy valami hiba okán.
Sose lehet tudni. A "helloworld"-nél bonyuloltabb szkriptek, főleg ha nem tíz sorosról van szó, amiben ls parancsokat, sed-eket hívogat, esetleg echo *-szerű parancs is van benne, könnyen téveszthet (mármint a szkript írójának szándékához képest). Ismétlem, nem tudom, miket használsz a gépen, illetve milyen szkripteket, ezért csak találgatok.
Másodszor: tény, hogy piros volt a fájl az mc-ben, ?-es, és 0 méretű valamint attribútumú. Az immutable flag nem csinál ilyent egy fájllal.
Nem tudom, hogy az mc-ben mi lesz piros, már csak azért sem, mert a színeket felül lehet írni. Nem lehet, hogy egy broken symlink volt?Másrészt nem azt mondtam, hogy az immutable flag-től lett ilyen a fájl. Az immutable flag csak "rákerült", a fájl már eleve ilyen volt. Így értem.
Azt is kérdezhetném akkor, hogy milyen tevékenység képes ezt végezni egy fájllal úgy, hogy nincs valós esélye, hogy ezt a fájlt az rsync másolása után bárki is érintette volna?
Ismétlem: nem tudom. Te futtatod a szervert, te tudod, mik futnak rajta. Ha nem csak akkor kapcsolod be, amikor mentés történik rá, akkor "bármi" lehet.
Azóta kissé tartok a tesztelt fájlrendszerektől.
Az XFS is tesztelt fájlrendszer 😛Szerk.: ha a szkriptek publikusak lehetnek (esetleg IP-címek, ilyesmik kitörlése után), töltsd fel valahova, megnézem 🙂
- Be kell jelentkezni a hozzászóláshoz.
legutóbbi hsz