Hozzászólások
- Bejegyzés
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.
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.
Egy különbséget már látok. Ugyanakkora meghajtók esetén az xfs több szabad területet mutat, mint az ext4. Továbbá valahol olvastam, hogy sok kis fájl esetén gyorsabb az xfs az ext3-nál. Mivel fájlrendszermentések mennek rá, benne sok kis fájl is, reméltem gyorsabb is lesz.Az igazi motivációm azonban az volt, hogy az előtte rajta lévő ext4 olyan hibát produkált, amilyennel még nem találkoztam. Egy fájlnévben valami fura karakter szerepelt. Pedig csak egy rsync másolata egy éles tárterületnek. De ez még nem lett volna baj. Azonban ezt a fájlt nem lehetett letörölni. A root sem tudta. Ez csak adatterület volt. Nem foglalta senki. A fájl 0 bájt hosszúságúnak tűnt, de nem lehetett vele semmit kezdeni. fsck nem talált hibát. badblocks nem talált hibát. A smartctl is csak egyszer jelzett valamit, de a tesztjei hiba nélkül lefutottak, és a -H paraméterre azt mondja PASSED. Nagyon úgy tűnik, nincs hardver hiba a fájlrendszer alatt. Ám ezzel a fájllal semmit sem tudtam kezdeni.Végül újraformáztam a partíciót... Így került fel az xfs, hátha megbízhatóbb ...
Köszi a tapasztalatokat.Eg helyi mentés szerver másodlagos mentési területét formáztam most xfs-re, ezzel barátkozom, és eddig csak jót tapasztaltam. Olvasgattam a többi fájlrendszerről is, de a távlati terv az, hogy bővíthető lvm-re mennek az adatok, és úgy tűnt, a stabil fájlrendszerekből az xfs tudja egyedül a ment közbeni bővítést.A brtfs, meg zfs - ha jól emlékszem - azért estek ki a listáról, mert csak a fájrendszer több memóriát igényelne, mint amennyi a vasban összesen van.Az xfs-ről pedig eddig csupa jót olvastam. S bár másodlagos mentési szerepben az ilyen adatvesztés nem lényeges kockázat, azért ez a megbízhatatlanság meglep. Azt hittem, a fájlrendszer naplózása alap ma már minden rendszerben.
Hmmm … elvileg az LVM két adatlemezt használ, és egy napló eszközt. Ha jól láttam az lvconvert leírásában, a mirror és a raid1 között pont az a különbség, hogy a naplót külön eszközre teszi, vagy a tükrök mellé a két eszközre …Ezek szerint, lehet, hogy Neked mégis raid volt az lvm, és nem mirror ...
Úgy látom, ez a mirror típus. Nem is tudom, hogy RAID típust hogyan lehet létrehozni. Csak az lvconvert-nek találtam olyan paraméterezését, ahol a mirror típusból raid típus-t csinált. (Azaz a 3 lemez helyett elég volt neki 2.)
A mirror-ról én is sok rosszat halltottam, de úgy tűnik, hogy az LVM két módon is tud tükrözni. Mirror-ral, és raid-del is. Ez utóbbit próbáltad? Engem igazából ez érdekelne.
Azt látom, hogy az LVM tud mirror-t és RAID1-et is. A mirror az, amiről mindenhol írnak, és ami 3 lemezt igényel. De a RAID1 típusú LVM-ről nem nagyon találok tapasztalatokat.Van, aki használta már? Ez lényegesen rosszabb, mint az LVM a szoftveres RAID eszközök felett? Érdemes ezt használni?Egy réteg talán kisebb kockázat mint kettő. Elég sokszor olvastam már olyan problémákról, hogy a szoftveres raid "szétesett" ... kicsit tartok tőle.Másik pont, amiben bizonytalan vagyok, hogy érdemes-e a root partíciót LVM-be tenni, vagy ilyen szoftveres rétegeknél hasznosabb, ha a rendszer mindenképpen másik eszközön van mint az adat?
legutóbbi hsz