From: Tomasz Kłoczko Newsgroups: pl.comp.os.linux Subject: Re: 400 000 tys plików file system Lech R. PEDZIWIATR wrote: > bralu(nospam) wrote: > >> Wiatm >> Pracuje w firmie kótra sprzedaje zdjęcia w internecie. Jest ich około >> 400 000 tys w postaci jpg w duzej i małej rozdielczości od 1 do 4 MB. >> Obecnie używamy ext3 ale planujemy przejscie na XFS czy RaiserFS. >> Dystrybucja to RedHat jadra seri 2.4.20. >> Chciałem sie zapytać czy macie z tym jakieś problemy bo nie ukrywam ,że >> bezpieczeńswto jest w tej sprawie najważnijesze ? >> >> Pozdrawiam >> Michał Bralczyk > ... > Rozsadnie byloby uzyc reiserfs - pracuje bez zarzutu, ale bezpieczenstwo > osiagniesz TYLKO WTEDY, jesli uzyjesz dodatkowych metod, jak BACKUP i to w > PELNYM TEGO SLOWA znaczeniu, a nie n.p. w stylu: "codziennie kopiuje pliki > na inny dysk" lub "codziennie zgrywam wszystko na CD" i t.p. Bardzo mało w tym rozsądku a w dodatku w powyższym są zaszyte bzdury :> 1) Nie wiadomo jaka jest charakterystyka bciążenia ? czy przeważają odczyty czy zapisy, i czy wogóle któreś z tych operacji są w jakikolwiek sposób krytyczne ? 2) Czy i jaki jest rozkład plików na tym wolumenie ? Czy są one w jednym katalogu czy porozkładane po podkatalogach i w jaki sposób ? Do każdego z powyższych czynników można w jakiś sposób dobrać parametry tuningu systemu plikowego. Owe w największym zakresie są dostępne pod ext3. W przypadku zapisu grafik o ile są one użłożone na obciążonym wolumenie ważna może byc prealokacji (po to żeby nie degradować wydajności zwiększajacą się fragmentacja zasobów). W przypadku ext3 jest dostępna taka funkcjonalność (w przypadku reiserfs i xfs na L nie ma tego (xfs z IRIXa IIRC ma to więc ludzie z SGI prędzej czy później zapewne to dołożą). Minimalizacji utraty danych to rzecz którą zwykle rozparuje się nie na poziomie typu systemu plikowego tylko układu urządzeń blokowych wchodzących w skład wolumenu (np. mirroring), a takze samych urządzeń. Dlatego rozowa w tym konktekście o typach systemów plikowych nie tyle co jest mniej istotna co wręcz bez sensowna (przy założeniu że kod obsługi poszczegółnych fs ma porółnywalną stabilność .. co w tym wypadku ma miejsce). Klasyczny backup to *nie jedyna metoda* zabezpieczenia się przed utratą danych. Co więcej jest ona skteczna tylko do pewnych granic (powyżej pewnych rozmiarów danych już nie tyle koszt tej czynniści wzrasta do wartości nie do zakceptowania co czy to czas wykonania takiej operacji potrafi być juz dłuższy niż cykl backupu i/lub w przypadku wolumenów obciążonych rozpoczęcie robienia kopii równa się zarżnięciu I/O i padem np. serwisu udostępniajacego dane). W tym wypadku nie wiadomo nic na temat już tych powyższych dwuch punktów więc próba radzenia co do tego jakie rozwiązania należy wybrać jest pozbawiona podstaw. > Tylko wlasciwa STRATEGIA (duzo czytaj) backup zapewnia bezpieczenstwo > danych. Właściwa strategia opiera się na rozpoznaniu matrii do której ową się układa. > Co do dyskow: TYLKO praca w systemie RAID 5-10 zabezpieczy przed awariami > dyskow, t. zn. awaria jednego z elementow macierzy RAID nie powoduje > utraty, czy uszkodzenia danych. Kolejne bzdury pleciesz .. Znasz raptem tylko początek baaaardz długiej listy dostępnych tu sirodków (to tak apropo słowa "TYLKO"). Może jak zdasz sobie sprawę z tego, że 400 000 plików 1 do 4 MB to 400GB do 1.6TB to nieco inaczej popatrzysz na to o czym piszesz. Myśląc o typie systemu plikowego wcześniej wogóle zastanowiłbym się czy to np. koniecznie musi być na jednym wolumenie (to niejako na marginesie). Dla uproszczenie założe, że nie ma tu wymagań wydajnościowych i że można to zrobić na jakimś JBOD na dyskach SATA (powiedźmy 250MB) to będzie to około jednej typowej półki 3-4U 19' z max. dwunastoma dyskami. W takim rozwiązaniu pierwsza rzeczą jaką trzeba zapewnić z punktu niezawodności pracy to jest *właściwe chłodzenie*. Conajmniej dwa razy większa pojemność zapewni czy to zapas pojemności (przy założeniu że ilość danych będzie rosła) czy to możliwość robienia backupu np. poprzez cykliczne spinanie i rozpinania mirrora "na trzeciego" (pojeność użytkowa bęzie musiała być w takim rozwiązaniu równa jednej trzeciej pojemności surowej). Mówisz backup .. prosze bardzo. Weźmy np. napęd SDLT czy DDS4. Policz sobie ile będzie trwało zapisanie danych na takich tasiemkach zakładajac że masz o dysposyzji changer z odpowiednia ilościa kaset z (dla uproszczenia) jednym napędem. Załóżmy że kopię robimy na CD. Proponuję policzyć czas wypalenia odpowiedniej ilości płytek CD (nawet w przypadku DVD to że przez cały cza będzie musiał ktoś przy tym asystować całe rozwiazanie będzie absurdalne ponieważ potencjalnie ół człowiek bezie nasłabszym ogniwem z punktu widzenia zapewnienia braku utraty danych). O kupowaniu napędu np. LTO-2 nie ma co w tym konteście raczje co mówić bo już tylko jego kosz będzie równy kosztowi zakupu dodatkowej półki JBOD (co prawda dane mogą być tego watre ale tego w tym momencie nie można rozstrzygnąć). W tym wypadku poświeciłbym dużo więcej uwagi choćby temu co powyżej podkręsliłem (chłodzenie), bo szczegółnie początkujący administratorzy instalacji klasy worgroup i wyżej (a powyszą instalację IMO można już do klasy workgroup zaliczyć) poświecają wiele uwagi na rzeczy drogie czy to też skomplikowane zapominajac o choćby takich rzeczach jak zapewnienie właściwego zasilania typu zapewnienie redundancji czy podtrzymania tegoż Tu małe wtrącenie na ten temat .. Robisz kopię i w trakcie pada zasiilania. Pytanie: czy kopia ma jakąś warość ? Albo właśnie potrzeba zrobić zmiany w instalacji elektrycznej, a urządzenia nie mają możliwości podłączenia do dwuch niezależnych źródeł zasilania i przez to w trakcie takiej opercji koniecznie trzeba wszytko wyłączyć (bo to właśnie na takie okazje urząznia wyposarza się także w podwójne zasilacze). Przyład kiedy masz taką instalację (co zdarza się typowo): elektryk po mimoe tego że jest fachowncen z racji tego że nei zna terenu w jakim przyzaszło mu dizałać zrobił zwarcie w jednej z instalacji el i .. czy to właśnie rozbiący się backup na tym nie ucierpi czy też wszystko dalej działa. Tak czy inaczej dobierając (czy to rozwiązania sprzętowe czy to programowe) cokolwiek do powyższego pierwsze od czego bym zaczął to spojrzenie na wyniki iostat dla wolumenu na którym to obecnie pracuje. Reszta szczegułów powyżej tylko niejako wypunktowancyh może być dużo ważniejsza ale zakładam że skotro instalacja działa to nie ma tu jednak o czym za wiele mówić (że ktoś wiedział że coś tu może być istotne i zadbał o co trzeba) albo dane nie sa jednak na tyle ważne żeby ponosić przynajmniej część kosztów powyższego. I jeszcze na koniec. Z pierwotnego listu wynika że obecne rozwiąznie na ext3 *działa* i/lub nie ma w tym liście nic co uzasadniałoby jakiekolwiek zmiany owego fs. Przypomnę tu także elementarz czyli tzw. pierwsżza zasadę McGyver'a: "nie zepsute więc nie naprawiam". Czy są wogóle tu jakieś powody żeby cokowiek tu zmianiać ? (mowa o fs) bo ja jak na razie nic w tej matrii nie wiadomo. kloczek -- ----------------------------------------------------------- *Ludzie nie mają problemów, tylko sobie sami je stwarzają* ----------------------------------------------------------- Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl*