🚀 go-pugleaf

On Thu, 16 Aug 2007 09:04:58 +0200
Slawomir Stanczak <null@blackhole.net> wrote:

> Witam,
> 
> Wiadomo że systemy unix-owe używają swoich dedykowanych systemów
> plików. Linux umożliwia implementację wielu fs; xfs, ext3, reiserfs,
> jfs itp. Mój dylemat polega na tym że nie wiem co wybrać.
> 

ext3 - przetestowany i bezpieczny. W przypadku nieczystego zamknięcia
systemu różne systemy mają różne problemy. xfs umie zastąpić ostatnie
bajty pliku używanego przy resecie jako zera, jfs nie podmontuje się,
jeśli nie będzie sprawdzony przez fsck. Przy czym montowanie jfs
bez sprawdzenia nie pokazuje żadnego błędu. ext3 po prostu odtwarza
journal i działa dalej.

morr

-- 
Daniel 'Shinden' Horecki
http://morr.pl

>..., jfs nie podmontuje się,
> jeśli nie będzie sprawdzony przez fsck. Przy czym montowanie jfs
> bez sprawdzenia nie pokazuje żadnego błędu. ext3 po prostu odtwarza
> journal i działa dalej.
>
> morr

Uwazasz, ze to bezpieczne? Skoro JFS sprawdza byki po niezamierzonym 
zamknieciu, to ma ku temu powody, jak znaczna wiekszosc FS. To ze nie 
znajduje zadnych bykow, to tylko chwala mu za to. Nie jestem znawca, ale 
wydaje mi sie, ze nadmierna polityka sprawdzania FS nigdy jeszcze nikomu nie 
zaszkodzila, a wrecz czasami pomagala.


-- 
Pozdrawiam,
M.K.


"Pora zmywac sie na zmywak - dwa miliony polakow nie moze sie mylic..." 

HawkEye <HawkEye_WYTNIJ_TO_@gazeta.pl> wrote:
> >..., jfs nie podmontuje się,
> > jeśli nie będzie sprawdzony przez fsck. Przy czym montowanie jfs
> > bez sprawdzenia nie pokazuje żadnego błędu. ext3 po prostu odtwarza
> > journal i działa dalej.
> >
> > morr
> 
> Uwazasz, ze to bezpieczne?

No, po to całe to księgowanie, bariery io, etc...

> Skoro JFS sprawdza byki po niezamierzonym 
> zamknieciu, to ma ku temu powody, jak znaczna wiekszosc FS. To ze nie 
> znajduje zadnych bykow, to tylko chwala mu za to. Nie jestem znawca, ale 
> wydaje mi sie, ze nadmierna polityka sprawdzania FS nigdy jeszcze nikomu nie 
> zaszkodzila, a wrecz czasami pomagala.

Powiedz to komuś kto ma fs 2TB, gdzie fsck trwa nawet 1h.

Pozdrawiam,

			Krzysztof Oledzki

-- 
Krzysztof Olędzki
e-mail address:		ole(a-t)ans(d-o-t)pl
Registered User:	Linux - 189200, BSD - 51140
Nick Handles:		KO60-RIPE, KO581 (Network Solutions)

Krzysztof Oledzki pisze:
> HawkEye <HawkEye_WYTNIJ_TO_@gazeta.pl> wrote:
>>> ..., jfs nie podmontuje się,
>>> jeśli nie będzie sprawdzony przez fsck. Przy czym montowanie jfs
>>> bez sprawdzenia nie pokazuje żadnego błędu. ext3 po prostu odtwarza
>>> journal i działa dalej.
>>>
>>> morr
>> Uwazasz, ze to bezpieczne?
> 
> No, po to całe to księgowanie, bariery io, etc...
> 
>> Skoro JFS sprawdza byki po niezamierzonym 
>> zamknieciu, to ma ku temu powody, jak znaczna wiekszosc FS. To ze nie 
>> znajduje zadnych bykow, to tylko chwala mu za to. Nie jestem znawca, ale 
>> wydaje mi sie, ze nadmierna polityka sprawdzania FS nigdy jeszcze nikomu nie 
>> zaszkodzila, a wrecz czasami pomagala.
> 
> Powiedz to komuś kto ma fs 2TB, gdzie fsck trwa nawet 1h.

Do tego klienta ze stoperem w ręku mierzy downtime, który się później 
przeniesie na bardzo bolesne kary za przekroczenie SLA.

-- 
Pozdrawiam
Filip Kata

Użytkownik "Filip Kata" <filip@filipkata.com> napisał w wiadomości 
news:fbgfc2$srj$1@inews.gazeta.pl...
> Krzysztof Oledzki pisze:
>> HawkEye <HawkEye_WYTNIJ_TO_@gazeta.pl> wrote:
>>>> ..., jfs nie podmontuje się,
>>>> jeśli nie będzie sprawdzony przez fsck. Przy czym montowanie jfs
>>>> bez sprawdzenia nie pokazuje żadnego błędu. ext3 po prostu odtwarza
>>>> journal i działa dalej.
>>>>
>>>> morr
>>> Uwazasz, ze to bezpieczne?
>>
>> No, po to całe to księgowanie, bariery io, etc...
>>
>>> Skoro JFS sprawdza byki po niezamierzonym zamknieciu, to ma ku temu 
>>> powody, jak znaczna wiekszosc FS. To ze nie znajduje zadnych bykow, to 
>>> tylko chwala mu za to. Nie jestem znawca, ale wydaje mi sie, ze 
>>> nadmierna polityka sprawdzania FS nigdy jeszcze nikomu nie zaszkodzila, 
>>> a wrecz czasami pomagala.
>>
>> Powiedz to komuś kto ma fs 2TB, gdzie fsck trwa nawet 1h.
>
> Do tego klienta ze stoperem w ręku mierzy downtime, który się później 
> przeniesie na bardzo bolesne kary za przekroczenie SLA.
>
To po to sa rozne wynalazki jak mirrory itepe ;P Poza tym, przy 2TB, uwazam 
ze powinno sie juz uzywac jednak sprawdzonych rozwiazan, a nie komputer made 
by sąsiad i dyski made by okazja na alledrogo lub u Zdziska w garazu, gdzie 
zasilacz w tym kompie to spirala skrecona z kilkoma rezystorami na cegle i 
gdzie ups to pewnie akumulator od Syrenki made in FSM.

Przy duzych macierzach nie uzywa sie kontrolerow z chipsetem VIA lub SIS, 
tylko niestety profesjonalnych rozwiazan z podtrzymywaniem bateryjnym i 
wlasna pamiecia.

Niby jestem laik, a jednak uwazam i nadal bede sie upieral, ze cos za cos... 
W ostatecznosci mozna przerzucic sie na Solarisa(wkrotce 3bsd) i jego ZFS ;) 
Ale i tu nie dam reki uciac, czy ten system nie sprawdza bykow... W koncu to 
system plikow, wciaz zalezny od mechanicznych (wadliwych, psujacych sie) 
urzadzen.
-- 
Pozdrawiam,
M.K.


"Pora zmywac sie na zmywak - dwa miliony polakow nie moze sie mylic..." 

On 04.09.2007, HawkEye <HawkEye_WYTNIJ_TO_@gazeta.pl> wrote:
>>>> Skoro JFS sprawdza byki po niezamierzonym zamknieciu, to ma ku temu 
>>>> powody, jak znaczna wiekszosc FS. To ze nie znajduje zadnych bykow, to 
>>>> tylko chwala mu za to. Nie jestem znawca, ale wydaje mi sie, ze 
>>>> nadmierna polityka sprawdzania FS nigdy jeszcze nikomu nie zaszkodzila, 
>>>> a wrecz czasami pomagala.
>>>
>>> Powiedz to komuś kto ma fs 2TB, gdzie fsck trwa nawet 1h.
>>
>> Do tego klienta ze stoperem w ręku mierzy downtime, który się później 
>> przeniesie na bardzo bolesne kary za przekroczenie SLA.
>>
> To po to sa rozne wynalazki jak mirrory itepe ;P

I jak mirror (dobrze rozumiem że chodzi o RAID-1?) ma zabezpieczyć przed
niepoprawnym zamknięciem systemu operacyjnego?

> Poza tym, przy 2TB, uwazam 
> ze powinno sie juz uzywac jednak sprawdzonych rozwiazan, a nie komputer made 
> by sąsiad i dyski made by okazja na alledrogo lub u Zdziska w garazu, gdzie 
> zasilacz w tym kompie to spirala skrecona z kilkoma rezystorami na cegle i 
> gdzie ups to pewnie akumulator od Syrenki made in FSM.

Od razu widać że nie masz styczności z poważniejszymi rozwiązaniami.
Owszem, niekontrolowane rebooty zdarzają się również przy rackowych
serwerach HP z redundantnymi zasilaczami zasilanych z dwóch różnych
UPS-ów. Nie jest wiele tych rebootów, ale jednak zdarzają się (błąd
człowieka, te sprawy).

> Przy duzych macierzach nie uzywa sie kontrolerow z chipsetem VIA lub SIS, 
> tylko niestety profesjonalnych rozwiazan z podtrzymywaniem bateryjnym i 
> wlasna pamiecia.

A co to ma do rzeczy? To tylko gwarancja, że co system operacyjny zleci
macierzy, to zostanie odnotowane na dysku. I nic więcej.

> Niby jestem laik, a jednak uwazam i nadal bede sie upieral, ze cos za cos... 
  ^^^^^^^^^^^^^^^^
O widzisz. To dlaczego wypowiadasz się tonem eksperta? A potem będziesz
płakać że my wszyscy jesteśmy zacietrzewieni, bo wykazujemy twoją
niewiedzę w pewnych dziedzinach, o których raczyłeś napisać jakiś
komentarz.

-- 
Secunia non olet.
Stanislaw Klekot

HawkEye pisze:
> Użytkownik "Filip Kata" <filip@filipkata.com> napisał w wiadomości 
> news:fbgfc2$srj$1@inews.gazeta.pl...
>> Krzysztof Oledzki pisze:
>>> HawkEye <HawkEye_WYTNIJ_TO_@gazeta.pl> wrote:
>>>>> ..., jfs nie podmontuje się,
>>>>> jeśli nie będzie sprawdzony przez fsck. Przy czym montowanie jfs
>>>>> bez sprawdzenia nie pokazuje żadnego błędu. ext3 po prostu odtwarza
>>>>> journal i działa dalej.
>>>>>
>>>>> morr
>>>> Uwazasz, ze to bezpieczne?
>>>
>>> No, po to całe to księgowanie, bariery io, etc...
>>>
>>>> Skoro JFS sprawdza byki po niezamierzonym zamknieciu, to ma ku temu 
>>>> powody, jak znaczna wiekszosc FS. To ze nie znajduje zadnych bykow, 
>>>> to tylko chwala mu za to. Nie jestem znawca, ale wydaje mi sie, ze 
>>>> nadmierna polityka sprawdzania FS nigdy jeszcze nikomu nie 
>>>> zaszkodzila, a wrecz czasami pomagala.
>>>
>>> Powiedz to komuś kto ma fs 2TB, gdzie fsck trwa nawet 1h.
>>
>> Do tego klienta ze stoperem w ręku mierzy downtime, który się później 
>> przeniesie na bardzo bolesne kary za przekroczenie SLA.
>>
> To po to sa rozne wynalazki jak mirrory itepe ;P Poza tym, przy 2TB, 
> uwazam ze powinno sie juz uzywac jednak sprawdzonych rozwiazan, a nie 
> komputer made by sąsiad i dyski made by okazja na alledrogo lub u 
> Zdziska w garazu, gdzie zasilacz w tym kompie to spirala skrecona z 
> kilkoma rezystorami na cegle i gdzie ups to pewnie akumulator od Syrenki 
> made in FSM.

Mówię o rozwiązaniach typu 2 data center w różnych lokalizacjach, 
macierzach klasy enterprise (DMX) i pełnej redundancji na każdym 
poziomie. Zawsze może się coś stać, błąd człowieka, systemu i różne inne 
nie przewidziane atrakcje.

> Przy duzych macierzach nie uzywa sie kontrolerow z chipsetem VIA lub 
> SIS, tylko niestety profesjonalnych rozwiazan z podtrzymywaniem 
> bateryjnym i wlasna pamiecia.

Co Ty nie powiesz. Chyba rozmawiamy na dwóch różnych poziomach. Ja nie 
biorę pod uwagę rozwiązań desktopowych.

-- 
Pozdrawiam
Filip Kata

Zejdz ze mnie czleku ok? Uznajmy, ze ani ja, ani Ty nie bedziemy sobie 
wchodzic w parade. Inna sprawa, ze z administracja mam do czynienia na 
codzien. Nie zarzadzam wielkimi serwerowniami, ale pewna _praktyczna_ wiedze 
o tym mam. Do tego nie czytasz _dokladnie_ watkow, wybierasz cos z kontekstu 
i pozniej rzucasz do mnie gownem, by pokazac zawsze swoja wyzszosc, jaki Ty 
to madry jestes. Odczep sie i daj zyc innym, chyba ze te zaczepki to 
zachecenie na randke?Niesmialy jestes czy jak? Ale musze Cie 
zmartwic-zdecydowanie pedziow, obszczymorow i takich jak Ty nie toleruje. 
Mozesz jeszcze napisac i podkreslic, zem cham, ze sie czepiam, ale jak juz 
na poczatku napisalem-ja z Toba nie bede juz dyskutowal, bo z 
zacietrzewionym "polaczkiem" w dyskusje nie bede wchodzil. Poszperaj jeszcze 
po innych grupach, wez cos napisz i wreszcie sie odpicuj odemnie.... bo 
tylko tyle potrafisz.... Zalosny jestes. 

Użytkownik "Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam> 
napisał
> Owszem, niekontrolowane rebooty zdarzają się również przy rackowych
> serwerach HP z redundantnymi zasilaczami zasilanych z dwóch różnych
> UPS-ów. Nie jest wiele tych rebootów, ale jednak zdarzają się (błąd
> człowieka, te sprawy).
>
I wowczas wlasnie przydaje sie sprawdzenie dysku na wystapienie wszelakich 
bledow. Na desktopie mozna to czasem zignorowac.Skoros taki znafftza, to 
powinienes wiedziec, ze zadne oprogramowanie, chocby napisane przez Ciebie o 
Bogu, nie jest do konca pewne. I nie zalezy to nawet juz od danego programu, 
modulu, ale od calosci - od srodowiska systemowego, od sprzetu, od admina 
etc etc Gdyby wszystko bylo doskonale, to nie mielibysmy fixpackow, Twoja 
praca byla by zbedna, producenci np. streamerow poszli by z torbami itd. 
Dziwie sie poza tym, tak WIELKIEMU mistrzowi od bezpieczenstwa, ktory 
ignoruje jego podstawowe zasady... Do reszty odsylam do wczesniejszego 
postu.


-- 
M.K.


"Pora zmywac sie na zmywak - dwa miliony polakow nie moze sie mylic..." 

> Mówię o rozwiązaniach typu 2 data center w różnych lokalizacjach, 
> macierzach klasy enterprise (DMX) i pełnej redundancji na każdym poziomie. 
> Zawsze może się coś stać, błąd człowieka, systemu i różne inne nie 
> przewidziane atrakcje.
>
Niby o czym wczesniej pisalem? Wlasnie o tym.... Uwazasz, ze sprzet/system 
jest na 100% pewny? Podam Ci przyklad z autopsji: nowiutki dysk SATA - 
edycja RAID (cokolwiek by to mialo znaczyc). Pelny format w NTFS. Po kilku 
dniach pad pradu. przy bootowaniu windowsa chkdsk nagle wykazuje kilka bad 
sektorow. ale ale.... te sektory powinny przeciez przy formacie dysku byc 
juz zaznaczone jako zle! na cale szczescie byl to dysk dla samby, i wielkich 
szkod nie bylo, ale co by bylo, gdyby to byl dysk systemowy? zauwaz, ze 
przypadkowo o tych b/s sie dowiedzialem,-gdyby nie elektrownia, do dzis bym 
pewnie nawet nie wiedzial o tym fakcie (partycja glownie na smieci,wiec nie 
ma potrzeby okresowego jej sprawdzania) jak juz wspomnialem-czasami 
nadmierna zapobiegliwosc nie szkodzi, a wrecz pomaga.

Wy podajecie jakies skrajne przypadki, ktorymi sie zajmujecie, ale przeciez 
nie wszedzie sa tej wielkosci dyski, powiedzmy >500GB. Zgodze sie, ze np. w 
przypadku coraz bardziej popularnych softrouterow, jak np. mikrotik, ktory 
moze dzialac na kartach flash, zbedne bylo by sprawdzanie fs za kazdym 
resetem/zaniku napiecia itd. Zauwaz jednak, ze w wiekszosci przypadkow mamy 
jedynie domniemanie o bezawaryjnosci sprzetu, a jednym z najbardziej 
awaryjnych i czulych na awarie podzespolem, to wlasnie dysk twardy, ze 
wzgledu na mechaniczna budowe, jak i ciagla prace tego mechanizmu. Kiedys na 
serwisie mialem dysk, ktory np, jak sie juz zagrzal, to chodzil normalnie, 
ale w fazie startu systemu zdazalo sie, ze np. nie znajdywal boot 
sektora-pomagalo odczekanie z minute, restart i dopiero dysk inicjowal boot 
loadera.
Znam tez takich "specow" (ale to juz przyznaje-sami sa/beda sobie winni), 
ktorzy (male bo male-nie wszedzie serwer to,jak u Was,jakas "ogromniasta 
szafa") podkrecaja procek/magistrale/ram. Nawet jak system wstanie i bedzie 
zachowywal sie stabilnie-istnieje niebezpieczenstwo, ze przy zwisie moze 
nawet caly fs pojsc w pyl.

Inna kwestia w tym watku jest to, ze pytajacy nie podal/nie sprecyzowal w 
jakim srodowisku pracuje.Moze byc to ogromny data center, ale moze to byc 
rowniez serwer malej sieci lokalnej. Zaznaczyl wrecz:
"Podstawowym kryterium jest bezpieczeństwo danych, wydajność ma drugorzędne 
znaczenie."

Czy tylko ja dostrzeglem to zdanie?

Na koniec napisze to jeszcze raz-ja jestem zwyklym szarym zjadaczem chleba, 
wiec tylko wyrazam swoja opinie. Chcecie, stosujecie sie do tego, co Wam 
sumienie podpowiada, ew. do Waszej wiedzy i doswiadczenia. Jednak wciaz nikt 
mi nie przedstawil konkretow, ze mozna sobie odpuscic fsck i ze dany fs jest 
wowczas 100% godny polecenia. Wspomnialem o ZFS, a jesli ktos z Was uzywa 
czegos, co gwarantuje w 100% "bezpieczenstwo danych" to chwala mu za to i 
tylko przyklasne :)

-- 
Pozdrawiam,
M.K.


"Pora zmywac sie na zmywak - dwa miliony polakow nie moze sie mylic..."

HawkEye <HawkEye_WYTNIJ_TO_@gazeta.pl> wrote:
> Użytkownik "Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam> 
> napisał
> > Owszem, niekontrolowane rebooty zdarzają się również przy rackowych
> > serwerach HP z redundantnymi zasilaczami zasilanych z dwóch różnych
> > UPS-ów. Nie jest wiele tych rebootów, ale jednak zdarzają się (błąd
> > człowieka, te sprawy).
> >
> I wowczas wlasnie przydaje sie sprawdzenie dysku na wystapienie wszelakich 
> bledow.
Serio, nie rozumiesz na czym polega cały problem, prawda?

Pozdrawiam,

			Krzysztof Oledzki

-- 
Krzysztof Olędzki
e-mail address:		ole(a-t)ans(d-o-t)pl
Registered User:	Linux - 189200, BSD - 51140
Nick Handles:		KO60-RIPE, KO581 (Network Solutions)

HawkEye <HawkEye_WYTNIJ_TO_@gazeta.pl> wrote:
> > Mówię o rozwiązaniach typu 2 data center w różnych lokalizacjach, 
> > macierzach klasy enterprise (DMX) i pełnej redundancji na każdym poziomie. 
> > Zawsze może się coś stać, błąd człowieka, systemu i różne inne nie 
> > przewidziane atrakcje.
> >
> Niby o czym wczesniej pisalem? Wlasnie o tym.... Uwazasz, ze sprzet/system 
> jest na 100% pewny? Podam Ci przyklad z autopsji: nowiutki dysk SATA - 
> edycja RAID (cokolwiek by to mialo znaczyc).
Tyle zapewne, że dysk ma zredukowane timeouty i szybciej poddaje się
w przypadku roblemu z odczytaniem danego bloku. A robi tak z tego
powodu, że przecież jest 2 dysk, z tymi samymi danymi. RAID edition, prawda?
Poza tym, Windows nie sprawdza NTFS bez powodu. Robi to tylko wtedy,
kiedy wie, że na dysku są błędy, a zazwyczaj wynika to właśnie z badblokdów.
Normalnie, po restarcie, system wstaje bez chkdsk.

> Pelny format w NTFS. Po kilku 
> dniach pad pradu. przy bootowaniu windowsa chkdsk nagle wykazuje kilka bad 
> sektorow.
Heheh, edycja RAID bez RAIDA? Genialne.

> ale ale.... te sektory powinny przeciez przy formacie dysku byc 
> juz zaznaczone jako zle!
A niby z jakiej okazji, jak wtedy jeszcze złe nie były?

> na cale szczescie byl to dysk dla samby,
Jak to dla samby? NTFS dla samby? Tobie chodzi o udostępnianie
plików po SMB/CIFS? Bo samba to taka implmenetacja tego propotokłu pod
Linuksa/FreeBSD/etc. Poza tym, szczerze? W większości wypadków
wolałbym stracić system niż dane. System reinstaluje się szybko,
odzyskiwanie danych (zakładając, że nie ma backupu) jest zazwyczaj
dość problematyczne.

> i wielkich 
> szkod nie bylo, ale co by bylo, gdyby to byl dysk systemowy?
To trzebaby wyrzucić admina z pracy albo chociaż wysłać go na jakieś
szkolenie. Bo to strach powierzać takiej osobie sprawę bezpieczeństwa
informacji.

> zauwaz, ze 
> przypadkowo o tych b/s sie dowiedzialem,-gdyby nie elektrownia, do dzis bym 
> pewnie nawet nie wiedzial o tym fakcie (partycja glownie na smieci,wiec nie 
> ma potrzeby okresowego jej sprawdzania) jak juz wspomnialem-czasami 
> nadmierna zapobiegliwosc nie szkodzi, a wrecz pomaga.
Pewnie o takich rozwiązaniach jak SMART też nie słyszałeś?

> Wy podajecie jakies skrajne przypadki, ktorymi sie zajmujecie, ale przeciez 
> nie wszedzie sa tej wielkosci dyski, powiedzmy >500GB.
Powiedziałbym raczej, że zazwyczaj dyski są mniejsze, 146GB czy 300GB.
Całą tajemnica polega na tym, że jest ich kilka, kilaknaście albo kilkadziesiąt.

> Zgodze sie, ze np. w 
> przypadku coraz bardziej popularnych softrouterow, jak np. mikrotik, ktory 
> moze dzialac na kartach flash, zbedne bylo by sprawdzanie fs za kazdym 
> resetem/zaniku napiecia itd.
A to niby z jakiej okazji? Jak nie ma księgowania to po każdym nieplanowanym
restarcie na fs mogą być dość poważne uszkodzenia. Jak nie zostaną naprawione
to zaraz może się okazać, że system się wykrzaczy.

> Zauwaz jednak, ze w wiekszosci przypadkow mamy 
> jedynie domniemanie o bezawaryjnosci sprzetu, a jednym z najbardziej 
> awaryjnych i czulych na awarie podzespolem, to wlasnie dysk twardy, ze 
> wzgledu na mechaniczna budowe, jak i ciagla prace tego mechanizmu.
I po to właśnie stosuje się RAID, z magicznymi liczbami 1/5/6/10/...

> Kiedys na 
> serwisie mialem dysk, ktory np, jak sie juz zagrzal, to chodzil normalnie, 
> ale w fazie startu systemu zdazalo sie, ze np. nie znajdywal boot 
> sektora-pomagalo odczekanie z minute, restart i dopiero dysk inicjowal boot 
> loadera.
Ale widzisz też różnicę pomiędzy błędami na fs a fizycznym uszkodzeniem dysku?
To że system będzie przez 2h sprawdzał dzielnie metadane nie oznacza, że trafi
na takie fizyczne uszkodzenie. Nie tędy droga.

> Znam tez takich "specow" (ale to juz przyznaje-sami sa/beda sobie winni), 
> ktorzy (male bo male-nie wszedzie serwer to,jak u Was,jakas "ogromniasta 
> szafa") podkrecaja procek/magistrale/ram. Nawet jak system wstanie i bedzie 
> zachowywal sie stabilnie-istnieje niebezpieczenstwo, ze przy zwisie moze 
> nawet caly fs pojsc w pyl.
A jak nie fs, to pliki bazy danych, a jak nie pliki bazy danych to
pościągane filmiki. I co? Po każdym takim restarcie będziesz oglądał
wszystki filmy i słuchał wszytskich mp3, żeby zobaczyć, czy któryś
się nie uszkodził? Bo, jak sam napisałeś, wszystko jest awaryjne.

> Inna kwestia w tym watku jest to, ze pytajacy nie podal/nie sprecyzowal w 
> jakim srodowisku pracuje.Moze byc to ogromny data center, ale moze to byc 
> rowniez serwer malej sieci lokalnej.
Bez znaczenia.

> Zaznaczyl wrecz:
> "Podstawowym kryterium jest bezpieczeństwo danych, wydajność ma drugorzędne 
> znaczenie."
Bingo! Jak można mówić o bezpieczństwie i o wydajności jak np. po
awarii zasilania przez 2h dostepu do danych nie ma? I co wtedy mają
zrobić pracownicy, iść może do domu? ;)

I jeszcze taka zagadka: który fs zapewnia większe bezpieczeństwo:
taki z księgowaniem, czy taki bez. I który będzie wyjdaniejszy?

> Czy tylko ja dostrzeglem to zdanie?
Chyba tylko Ty go nie rozumiesz.

Pozdrawiam,

			Krzysztof Oledzki

-- 
Krzysztof Olędzki
e-mail address:		ole(a-t)ans(d-o-t)pl
Registered User:	Linux - 189200, BSD - 51140
Nick Handles:		KO60-RIPE, KO581 (Network Solutions)

On Tue, 4 Sep 2007 09:52:06 +0200, HawkEye wrote:

> Użytkownik "Filip Kata" <filip@filipkata.com> napisał w wiadomości 
> news:fbgfc2$srj$1@inews.gazeta.pl...
>> Krzysztof Oledzki pisze:
>>> HawkEye <HawkEye_WYTNIJ_TO_@gazeta.pl> wrote:
>>> No, po to całe to księgowanie, bariery io, etc...
>>>
>>>> Skoro JFS sprawdza byki po niezamierzonym zamknieciu, to ma ku temu 
>>>> powody, jak znaczna wiekszosc FS. To ze nie znajduje zadnych bykow, to 
>>>> tylko chwala mu za to. Nie jestem znawca, ale wydaje mi sie, ze 
>>>> nadmierna polityka sprawdzania FS nigdy jeszcze nikomu nie zaszkodzila, 
>>>> a wrecz czasami pomagala.
>>>
>>> Powiedz to komuś kto ma fs 2TB, gdzie fsck trwa nawet 1h.
>>
>> Do tego klienta ze stoperem w ręku mierzy downtime, który się później 
>> przeniesie na bardzo bolesne kary za przekroczenie SLA.
>>
> To po to sa rozne wynalazki jak mirrory itepe ;P Poza tym, przy 2TB, uwazam 
> ze powinno sie juz uzywac jednak sprawdzonych rozwiazan, a nie komputer made 
> by sąsiad i dyski made by okazja na alledrogo lub u Zdziska w garazu, gdzie 
> zasilacz w tym kompie to spirala skrecona z kilkoma rezystorami na cegle i 
> gdzie ups to pewnie akumulator od Syrenki made in FSM.

Po to są filesystemy w stylu VxFS+VxVM z czymś takim jak DRL (Dirty Region
Logging) gdzie przy sprawdzaniu naprawdę DUŻYCH filesystemów (DUZO
większych niż 2TB) jest on wykorzystywany i sprawdza się wyśmienicie. Poza
tym mirroring raczej średnio zabezpiecza Cię przed zrobieniem fsck...
Snapshoty w PEWNYM stopniu zabezpieczają Cię przed awariami filesystemu ale
i to nie zawsze.

> 
> Przy duzych macierzach nie uzywa sie kontrolerow z chipsetem VIA lub SIS, 
> tylko niestety profesjonalnych rozwiazan z podtrzymywaniem bateryjnym i 
> wlasna pamiecia.
> 

Przy dużych macierzach używa się własnych systemów operacyjnych, odrębnych
maszyn zapakowanych w obudowę macierzy, cache rzęddu dziesiątków GB a o
chipsetach można książkę napisać.

> Niby jestem laik, a jednak uwazam i nadal bede sie upieral, ze cos za cos... 
> W ostatecznosci mozna przerzucic sie na Solarisa(wkrotce 3bsd) i jego ZFS ;) 
> Ale i tu nie dam reki uciac, czy ten system nie sprawdza bykow... W koncu to 
> system plikow, wciaz zalezny od mechanicznych (wadliwych, psujacych sie) 
> urzadzen.

ZFS też nie jest taki rewelacyjny jeśli chodzi o sprawdzanie WIELKICH
wolumenów - poza tym jest tylko na Solka, Maca , BSD i linuksa z FUSE. Na
AIXa czy HPUX brak takiego czegoś jak ZFS.

-- 
Pozdrawiam
Piotrek

On 08.09.2007, HawkEye <HawkEye_WYTNIJ_TO_@gazeta.pl> wrote:
> Użytkownik "Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam> 
> napisał
>> Owszem, niekontrolowane rebooty zdarzają się również przy rackowych
>> serwerach HP z redundantnymi zasilaczami zasilanych z dwóch różnych
>> UPS-ów. Nie jest wiele tych rebootów, ale jednak zdarzają się (błąd
>> człowieka, te sprawy).
>>
> I wowczas wlasnie przydaje sie sprawdzenie dysku na wystapienie wszelakich 
> bledow.

Nie. Wtedy przydaje się odtwarzanie dziennika transakcji. To taka dość
stara technika pochodząca z baz danych, wiesz. Albo zapis powodzi się
całkowicie, albo nie powodzi wcale, nie ma stanów pośrednich.

> Na desktopie mozna to czasem zignorowac.Skoros taki znafftza, to 
> powinienes wiedziec, ze zadne oprogramowanie, chocby napisane przez Ciebie o 
> Bogu, nie jest do konca pewne. I nie zalezy to nawet juz od danego programu, 
> modulu, ale od calosci - od srodowiska systemowego, od sprzetu, od admina 
> etc etc Gdyby wszystko bylo doskonale, to nie mielibysmy fixpackow, Twoja 
> praca byla by zbedna, producenci np. streamerow poszli by z torbami itd. 
> Dziwie sie poza tym, tak WIELKIEMU mistrzowi od bezpieczenstwa, ktory 
> ignoruje jego podstawowe zasady... Do reszty odsylam do wczesniejszego 
> postu.

Odezwał się znawca wykazujący się ignorancją co i rusz. Zgodnie z tym
tokiem myślenia fsck powinien być wykonywany co jakieś dwa dni,
zwłaszcza na dyskach SATA, bo mogą się pojawić błędy w zapisie
(interfejs SATA nie daje gwarancji, że dane zapisane na dysku są tymi
samymi, które zostały przesłane kablem).

-- 
Secunia non olet.
Stanislaw Klekot

On 08.09.2007, HawkEye <HawkEye_WYTNIJ_TO_@gazeta.pl> wrote:
> Zejdz ze mnie czleku ok?

To może zacznij brać odpowiedzialność za to co mówisz? To naprawdę
wystarczy, żebyśmy się przestali ciebie czepiać.

> Uznajmy, ze ani ja, ani Ty nie bedziemy sobie 
> wchodzic w parade. Inna sprawa, ze z administracja mam do czynienia na 
> codzien. Nie zarzadzam wielkimi serwerowniami, ale pewna _praktyczna_ wiedze 
> o tym mam.

Właśnie widać. A teoretyczną wiedzę masz jeszcze większą.

> Do tego nie czytasz _dokladnie_ watkow, wybierasz cos z kontekstu 
> i pozniej rzucasz do mnie gownem, by pokazac zawsze swoja wyzszosc, jaki Ty 
> to madry jestes.

Ależ skąd, bynajmniej. Ja tylko wyciągam bzdury, które napisałeś takim
tonem, jakbyś był znawcą.

> Odczep sie i daj zyc innym, chyba ze te zaczepki to 
> zachecenie na randke?Niesmialy jestes czy jak? Ale musze Cie 
> zmartwic-zdecydowanie pedziow, obszczymorow i takich jak Ty nie toleruje. 

O, tak jawne wycieczki osobiste? Wiesz, człowiek na pewnym poziomie
potrafi zmieszać drugiego z błotem nie schodząc z tematów technicznych,
o ile ten drugi zasłużył sobie na to wykazanym poziomem wiedzy. Ale
zwyzywać kogoś (albo przynajmniej zestawić z) od pedziów czy
"obszczymorow" potrafi każdy.

-- 
Secunia non olet.
Stanislaw Klekot

Piotr Smerda wrote:
> [...]
> ZFS też nie jest taki rewelacyjny jeśli chodzi o sprawdzanie WIELKICH
> wolumenów - [...]

Hmmm, nie wiem co rozumiesz przez słowo "sprawdzanie" ale jeśli chodzi 
Ci o odpowiednika fsck to ZFS nie ma takowego.

przemol

Piotr Smerda pisze:
> On Tue, 4 Sep 2007 09:52:06 +0200, HawkEye wrote:
> 
> ZFS też nie jest taki rewelacyjny jeśli chodzi o sprawdzanie WIELKICH
> wolumenów - poza tym jest tylko na Solka, Maca , BSD i linuksa z FUSE. Na
> AIXa czy HPUX brak takiego czegoś jak ZFS.

Hmm nie czuję jakoś potrzeby zastępowania JFS-a 2 i LVM-a ZFS-em.

-- 
Pozdrawiam
Filip Kata

HawkEye pisze:
> Użytkownik "Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam> 
> napisał
>> Owszem, niekontrolowane rebooty zdarzają się również przy rackowych
>> serwerach HP z redundantnymi zasilaczami zasilanych z dwóch różnych
>> UPS-ów. Nie jest wiele tych rebootów, ale jednak zdarzają się (błąd
>> człowieka, te sprawy).
>>
> I wowczas wlasnie przydaje sie sprawdzenie dysku na wystapienie 
> wszelakich bledow.

Nie po to kupuję macierz za kilka milionów złotych, żeby puszczać na
niej fsck. Do tego

> Na desktopie mozna to czasem zignorowac.Skoros taki 
> znafftza, to powinienes wiedziec, ze zadne oprogramowanie, chocby 
> napisane przez Ciebie o Bogu, nie jest do konca pewne. I nie zalezy to 
> nawet juz od danego programu, modulu, ale od calosci - od srodowiska 
> systemowego, od sprzetu, od admina etc etc Gdyby wszystko bylo 
> doskonale, to nie mielibysmy fixpackow, Twoja praca byla by zbedna, 
> producenci np. streamerow poszli by z torbami itd.

Sądząc po stylu wypowiedzi i stosowaniu wyrazów typu "znafftza" nie mamy
o czym dyskutować.

> Dziwie sie poza tym, 
> tak WIELKIEMU mistrzowi od bezpieczenstwa, ktory ignoruje jego 
> podstawowe zasady... Do reszty odsylam do wczesniejszego postu.

Hmm jakie podstawy ingoruje Dozzy?

Ogólnie bełkot...

-- 
Pozdrawiam
Filip Kata

przemol wrote:

> Piotr Smerda wrote:
>> [...]
>> ZFS też nie jest taki rewelacyjny jeśli chodzi o sprawdzanie WIELKICH
>> wolumenów - [...]
> 
> Hmmm, nie wiem co rozumiesz przez słowo "sprawdzanie" ale jeśli chodzi
> Ci o odpowiednika fsck to ZFS nie ma takowego.

Moze mial na mysli sprawdzanie przez "zpool scrub"

-- 
Jakub Wartak
http://vnull.pcnet.com.pl

HawkEye pisze:
>> Mówię o rozwiązaniach typu 2 data center w różnych lokalizacjach, 
>> macierzach klasy enterprise (DMX) i pełnej redundancji na każdym 
>> poziomie. Zawsze może się coś stać, błąd człowieka, systemu i różne 
>> inne nie przewidziane atrakcje.
>>
> Niby o czym wczesniej pisalem? Wlasnie o tym.... Uwazasz, ze 
> sprzet/system jest na 100% pewny? Podam Ci przyklad z autopsji: nowiutki 
> dysk SATA - edycja RAID (cokolwiek by to mialo znaczyc).

SATA jest ogólnie cieńkie pod względem żywotności w porównaniu do SCSI.

> Pelny format w 
> NTFS. Po kilku dniach pad pradu.

Nie rozumiem tego padu prądu... Przecież mam 2 niezależne tory 
zasilania, redundantne UPSy, a na końcu generatory, które pozwalają mi 
działać non stop. Do tego jest środowisko DR w innej lokalizacji, a nad 
wszystkim siedzi klaster.

Nie uważasz, że są inne sposoby na utrzymanie integralności danych?

> przy bootowaniu windowsa chkdsk nagle 
> wykazuje kilka bad sektorow. ale ale.... te sektory powinny przeciez 
> przy formacie dysku byc juz zaznaczone jako zle! na cale szczescie byl 
> to dysk dla samby, i wielkich szkod nie bylo, ale co by bylo, gdyby to 
> byl dysk systemowy?

Czy to systemowe czy z danymi udziały się tworzy w protekcji raid. 
Liczba na końcu jest odpowiednio dobierana do wymagań.

> zauwaz, ze przypadkowo o tych b/s sie 
> dowiedzialem,-gdyby nie elektrownia, do dzis bym pewnie nawet nie 
> wiedzial o tym fakcie (partycja glownie na smieci,wiec nie ma potrzeby 
> okresowego jej sprawdzania) jak juz wspomnialem-czasami nadmierna 
> zapobiegliwosc nie szkodzi, a wrecz pomaga.

Czemu mam cały czas odczucie, że piszesz o dekstopie...

> Wy podajecie jakies skrajne przypadki, ktorymi sie zajmujecie, ale 
> przeciez nie wszedzie sa tej wielkosci dyski, powiedzmy >500GB.

500 GB są wolne...

> Zgodze 
> sie, ze np. w przypadku coraz bardziej popularnych softrouterow, jak np. 
> mikrotik, ktory moze dzialac na kartach flash, zbedne bylo by 
> sprawdzanie fs za kazdym resetem/zaniku napiecia itd. Zauwaz jednak, ze 
> w wiekszosci przypadkow mamy jedynie domniemanie o bezawaryjnosci 
> sprzetu, a jednym z najbardziej awaryjnych i czulych na awarie 
> podzespolem, to wlasnie dysk twardy, ze wzgledu na mechaniczna budowe, 
> jak i ciagla prace tego mechanizmu. Kiedys na serwisie mialem dysk, 
> ktory np, jak sie juz zagrzal, to chodzil normalnie, ale w fazie startu 
> systemu zdazalo sie, ze np. nie znajdywal boot sektora-pomagalo 
> odczekanie z minute, restart i dopiero dysk inicjowal boot loadera.

Ja bym taki od razu wymienił na gwarancji u dostawcy.

> Znam tez takich "specow" (ale to juz przyznaje-sami sa/beda sobie 
> winni), ktorzy (male bo male-nie wszedzie serwer to,jak u Was,jakas 
> "ogromniasta szafa") podkrecaja procek/magistrale/ram. Nawet jak system 
> wstanie i bedzie zachowywal sie stabilnie-istnieje niebezpieczenstwo, ze 
> przy zwisie moze nawet caly fs pojsc w pyl.
> 
> Inna kwestia w tym watku jest to, ze pytajacy nie podal/nie sprecyzowal 
> w jakim srodowisku pracuje.Moze byc to ogromny data center, ale moze to 
> byc rowniez serwer malej sieci lokalnej. Zaznaczyl wrecz:
> "Podstawowym kryterium jest bezpieczeństwo danych, wydajność ma 
> drugorzędne znaczenie."

Wide powyższe punkty.

> Czy tylko ja dostrzeglem to zdanie?

... gorzej ze zrozumieniem.

> Na koniec napisze to jeszcze raz-ja jestem zwyklym szarym zjadaczem 
> chleba, wiec tylko wyrazam swoja opinie. Chcecie, stosujecie sie do 
> tego, co Wam sumienie podpowiada, ew. do Waszej wiedzy i doswiadczenia. 
> Jednak wciaz nikt mi nie przedstawil konkretow, ze mozna sobie odpuscic 
> fsck i ze dany fs jest wowczas 100% godny polecenia. Wspomnialem o ZFS, 
> a jesli ktos z Was uzywa czegos, co gwarantuje w 100% "bezpieczenstwo 
> danych" to chwala mu za to i tylko przyklasne :)

Toć napisałem. Niezależne linie zasilające, upsy, generatory, raid, hot 
swappowalne elementy typu CPU, ram, zasilacze, dyski, systemy backupu, 
zapasowe ośrodki i na końcu oprogramowanie - klastry, loadbalancery itp.

PS. Nawet na domowym PC przydaje się RAID i jakiś mały UPS, żeby się 
system ładnie złożył.

-- 
Pozdrawiam
Filip Kata

epsilon$ while read LINE; do echo ">$LINE"; done < Filip Kata
>> Pelny format w 
>> NTFS. Po kilku dniach pad pradu.
>Nie rozumiem tego padu prądu... Przecież mam 2 niezależne tory 
>zasilania, redundantne UPSy, a na końcu generatory, które pozwalają mi 
>działać non stop.

A i tak może się to zdupcyć.

-- 
  Kruk@ -\                   | I  am  Solo  of  Borg: You will be assimila-
          }-> epsilon.eu.org | ted...trust me.
http:// -/                   | 
                             | 

Mariusz Kruk pisze:
> epsilon$ while read LINE; do echo ">$LINE"; done < Filip Kata
>>> Pelny format w 
>>> NTFS. Po kilku dniach pad pradu.
>> Nie rozumiem tego padu prądu... Przecież mam 2 niezależne tory 
>> zasilania, redundantne UPSy, a na końcu generatory, które pozwalają mi 
>> działać non stop.
> 
> A i tak może się to zdupcyć.

I nawet się to zdarza, niestety :/

-- 
Pozdrawiam
Filip Kata

epsilon$ while read LINE; do echo ">$LINE"; done < Filip Kata
>>>> Pelny format w 
>>>> NTFS. Po kilku dniach pad pradu.
>>> Nie rozumiem tego padu prądu... Przecież mam 2 niezależne tory 
>>> zasilania, redundantne UPSy, a na końcu generatory, które pozwalają mi 
>>> działać non stop.
>> A i tak może się to zdupcyć.
>I nawet się to zdarza, niestety :/

Ano. Jako przestrogę wszystkim uważającym, że redundancja na wszystko
pomaga dedykuję na koniec opis pewnej awarii:
[...]
Przyczyna awarii byl zanik napiecia 15 kV ze STOEN i jednoczesne
wystapienie awarii agregatu pradotworczego (agregat testowany byl
dwa tygodnie temu). W zaistnialej sytuacji czas naprawy agregatu
przez elektryka dyz. przekroczyl niestety maksymalny czas podtrzymania
napiecia przez systemy UPS-ow.
[...]
-- 
/\-\/\-\/\-\/\-\/\-\/\-\/\ As  far  as  we know, our computer has never
\  Kruk@epsilon.eu.org   / had an undetected error.
/ http://epsilon.eu.org/ \ 
\/-/\/-/\/-/\/-/\/-/\/-/\/ 

Mariusz Kruk pisze:
> epsilon$ while read LINE; do echo ">$LINE"; done < Filip Kata
>>>>> Pelny format w 
>>>>> NTFS. Po kilku dniach pad pradu.
>>>> Nie rozumiem tego padu prądu... Przecież mam 2 niezależne tory 
>>>> zasilania, redundantne UPSy, a na końcu generatory, które pozwalają mi 
>>>> działać non stop.
>>> A i tak może się to zdupcyć.
>> I nawet się to zdarza, niestety :/
> 
> Ano. Jako przestrogę wszystkim uważającym, że redundancja na wszystko
> pomaga dedykuję na koniec opis pewnej awarii:
> [...]
> Przyczyna awarii byl zanik napiecia 15 kV ze STOEN i jednoczesne
> wystapienie awarii agregatu pradotworczego (agregat testowany byl
> dwa tygodnie temu). W zaistnialej sytuacji czas naprawy agregatu
> przez elektryka dyz. przekroczyl niestety maksymalny czas podtrzymania
> napiecia przez systemy UPS-ow.
> [...]

To ja dodam awarię 2 klimatyzatorów CLIVETa - chodzą na zmianę. Oba 
padły w tym samym momencie. Gdyby nie odpalenie z palca (cholerna 
elektronika), które zadziałało dopiero za n-tym razem, to wszystko by 
się powoli zaczęło składać.

-- 
Pozdrawiam
Filip Kata

Filip Kata <filip@filipkata.com> writes:

> SATA jest ogólnie cieńkie pod względem żywotności w porównaniu do SCSI.

Widze tu dobrze zrobiona robote marketingowa.
-- 
Krzysztof Halasa

On Mon, 10 Sep 2007 at 16:39 GMT, Krzysztof Halasa <khc@pm.waw.pl> wrote:
> Filip Kata <filip@filipkata.com> writes:
> 
>> SATA jest ogólnie cieńkie pod względem żywotności w porównaniu do SCSI.
> 
> Widze tu dobrze zrobiona robote marketingowa.

Fakty, fakty, Panowie... Grzecznie poprosze:-) Jakies wyliczenia na
poparcie obu wypowiedzi? Osobiscie slyszalem, ze MTBF dla dyskow SATA
liczony jest przy zalozeniu obciazenia 8h/dobe, a dla SCSI 24h/dobe. To do
mnie przemawia:-) Ale nikt nie zagwarantowal mi tez, ze jest to prawda
objawiona. Zamieniam sie wiec w sluch:-) i poslucham bardziej
doswiadczonego towarzystwa:-)

Pozdrawiam!
-- 
Piotr Skowronski
piotr[kropka]skowronski[ucho]dolinka[kropka]net[kropka]pl

Mariusz Kruk <Mariusz.Kruk@epsilon.eu.org> wrote:
> epsilon$ while read LINE; do echo ">$LINE"; done < Filip Kata
> >>>> Pelny format w 
> >>>> NTFS. Po kilku dniach pad pradu.
> >>> Nie rozumiem tego padu prądu... Przecież mam 2 niezależne tory 
> >>> zasilania, redundantne UPSy, a na końcu generatory, które pozwalają mi 
> >>> działać non stop.
> >> A i tak może się to zdupcyć.
> >I nawet się to zdarza, niestety :/
> 
> Ano. Jako przestrogę wszystkim uważającym, że redundancja na wszystko
> pomaga dedykuję na koniec opis pewnej awarii:
> [...]
> Przyczyna awarii byl zanik napiecia 15 kV ze STOEN i jednoczesne
> wystapienie awarii agregatu pradotworczego (agregat testowany byl
> dwa tygodnie temu). W zaistnialej sytuacji czas naprawy agregatu
> przez elektryka dyz. przekroczyl niestety maksymalny czas podtrzymania
> napiecia przez systemy UPS-ow.
> [...]

Hehe :) Też dostałem tego maila. ;)

Pozdrawiam,

			Krzysztof Oledzki

-- 
Krzysztof Olędzki
e-mail address:		ole(a-t)ans(d-o-t)pl
Registered User:	Linux - 189200, BSD - 51140
Nick Handles:		KO60-RIPE, KO581 (Network Solutions)

Piotr Skowronski <adres@dla.spamerow> writes:

> Fakty, fakty, Panowie... Grzecznie poprosze:-) Jakies wyliczenia na
> poparcie obu wypowiedzi? Osobiscie slyszalem, ze MTBF dla dyskow SATA
> liczony jest przy zalozeniu obciazenia 8h/dobe, a dla SCSI 24h/dobe.

A ja slyszalem ze cykl start/stop jest dla dysku gorszy niz
16 godzin pracy. Ale to takie tam "sluchy" - prawda jest taka,
ze padaja zarowno dyski SCSI jak i ATA, jak ktos wierzy w ich
niezawodnosc (obojetnie ktorych) to jest dziwny.

Roznice miedzy podobnymi :-) dyskami (Serial Attached akurat)
SCSI i ATA, wedlug producenta:

Barracuda ES.2 SAS 3.0-Gb/s 500-GB Hard Drive
- 24x7 operation and 1.2 M hrs. MTBF

Barracuda ES.2 SATA 3.0Gb/s 500GB Hard Drive:
- 24x7 operation and 1.2 M hrs. MTBF

Nieco inny dysk:
Cheetah® 15K.5 SAS 3Gb/s 300-GB Hard Drive - ST3300655SS
- MTBF 1400000 hours

Porownywac mozna producentow i np. rodziny dyskow, ale interfejsy?
-- 
Krzysztof Halasa

Krzysztof Halasa pisze:
> Filip Kata <filip@filipkata.com> writes:
> 
>> SATA jest ogólnie cieńkie pod względem żywotności w porównaniu do SCSI.
> 
> Widze tu dobrze zrobiona robote marketingowa.

Wystarczy przeczytać whitepaper, który wypuściło Google na temat dysków 
trochę temu. Do tego dochodzi autopsja. Dodatkowo jako argument mogę 
podać ilość hot-spare'ów, które np. IBM zaleca per półka dyskowa w 
swoich macierzach. ZTCP to na półkę SCSI jeden, a na półkę SATA dwa. 
Oczywiście mówimy o rozwiązaniach, gdzie dyski się kręcą 24/7.

-- 
Pozdrawiam
Filip Kata

Filip Kata pisze:
> Krzysztof Halasa pisze:
>> Filip Kata <filip@filipkata.com> writes:
>>
>>> SATA jest ogólnie cieńkie pod względem żywotności w porównaniu do SCSI.
>>
>> Widze tu dobrze zrobiona robote marketingowa.
> 
> Wystarczy przeczytać whitepaper, który wypuściło Google na temat dysków 
> trochę temu.

Update: znalazłem whitepaper, nie ma tam porównania SATA vs. SCSI. 
Dałbym sobie rękę uciąć, że to tam było... :) Poszukam jeszcze gdzie to 
mogło być.

-- 
Pozdrawiam
Filip Kata

Krzysztof Halasa pisze:
> Piotr Skowronski <adres@dla.spamerow> writes:
> 
> 
> Porownywac mozna producentow i np. rodziny dyskow, ale interfejsy?

Nie do kon'ca, SATA ma duz.o wie;cej przek?aman' na bitach, ale i tak MTBF 
jest g?ównym wyznacznikiem.

-- 
Pozdrawiam
Filip Kata

Krzysztof Halasa pisze:
> Piotr Skowronski <adres@dla.spamerow> writes:
> 
>> Fakty, fakty, Panowie... Grzecznie poprosze:-) Jakies wyliczenia na
>> poparcie obu wypowiedzi? Osobiscie slyszalem, ze MTBF dla dyskow SATA
>> liczony jest przy zalozeniu obciazenia 8h/dobe, a dla SCSI 24h/dobe.
> 
> A ja slyszalem ze cykl start/stop jest dla dysku gorszy niz
> 16 godzin pracy. Ale to takie tam "sluchy" - prawda jest taka,
> ze padaja zarowno dyski SCSI jak i ATA, jak ktos wierzy w ich
> niezawodnosc (obojetnie ktorych) to jest dziwny.
> 
> Roznice miedzy podobnymi :-) dyskami (Serial Attached akurat)
> SCSI i ATA, wedlug producenta:
> 
> Barracuda ES.2 SAS 3.0-Gb/s 500-GB Hard Drive
> - 24x7 operation and 1.2 M hrs. MTBF
> 
> Barracuda ES.2 SATA 3.0Gb/s 500GB Hard Drive:
> - 24x7 operation and 1.2 M hrs. MTBF
> 
> Nieco inny dysk:
> Cheetah® 15K.5 SAS 3Gb/s 300-GB Hard Drive - ST3300655SS
> - MTBF 1400000 hours
> 
> Porownywac mozna producentow i np. rodziny dyskow, ale interfejsy?

Nie do końca, SATA ma dużo więcej przekłamań na bitach. Do tego trzeba 
by było spojrzeć na mniejsze dyski (wydajność), a nie na typowy storage 
od którego się nie wymaga szybkości (vide 300 i 500 GB).

-- 
Pozdrawiam
Filip Kata

Krzysztof Halasa napisał(a):
> Filip Kata <filip@filipkata.com> writes:
> 
>> SATA jest ogólnie cieńkie pod względem żywotności w porównaniu do SCSI.
> 
> Widze tu dobrze zrobiona robote marketingowa.

Raczej urban legend :)

Może także rozciąganie przypadłości poprzedników.

pozdr

Radek

Dnia Tue, 11 Sep 2007 08:56:57 +0200, Filip Kata napisał(a):
> Dałbym sobie rękę uciąć, że to tam było... :) Poszukam jeszcze gdzie to 
> mogło być.

Bardzo proszę poszukać bo sam jestem ciekawy jak to wygląda.
A co to za whitepaper który Pan znalazł? Mógłby Pan wkleić link?

-- 
Wojtek /aquaz/ Dziubiński

Wojtek /Aquaz/ Dziubinski pisze:
> Dnia Tue, 11 Sep 2007 08:56:57 +0200, Filip Kata napisał(a):
>> Dałbym sobie rękę uciąć, że to tam było... :) Poszukam jeszcze gdzie to 
>> mogło być.
> 
> Bardzo proszę poszukać bo sam jestem ciekawy jak to wygląda.
> A co to za whitepaper który Pan znalazł? Mógłby Pan wkleić link?

Proszę

http://research.google.com/archive/disk_failures.pdf

-- 
Pozdrawiam
Filip Kata

Radoslaw Korzeniewski pisze:
> Krzysztof Halasa napisał(a):
>> Filip Kata <filip@filipkata.com> writes:
>>
>>> SATA jest ogólnie cieńkie pod względem żywotności w porównaniu do SCSI.
>>
>> Widze tu dobrze zrobiona robote marketingowa.
> 
> Raczej urban legend :)

Raczej nie. Na przestrzeni ostatnich lat z moich obserwacji w macierzach 
poleciało więcej dysków SATA niż SCSI.

-- 
Pozdrawiam
Filip Kata

Mariusz Kruk pisze:
> epsilon$ while read LINE; do echo ">$LINE"; done < Filip Kata
>>>>> Pelny format w 
>>>>> NTFS. Po kilku dniach pad pradu.
>>>> Nie rozumiem tego padu prądu... Przecież mam 2 niezależne tory 
>>>> zasilania, redundantne UPSy, a na końcu generatory, które pozwalają mi 
>>>> działać non stop.
>>> A i tak może się to zdupcyć.
>> I nawet się to zdarza, niestety :/
> 
> Ano. Jako przestrogę wszystkim uważającym, że redundancja na wszystko
> pomaga dedykuję na koniec opis pewnej awarii:
> [...]
> Przyczyna awarii byl zanik napiecia 15 kV ze STOEN i jednoczesne
> wystapienie awarii agregatu pradotworczego (agregat testowany byl
> dwa tygodnie temu). W zaistnialej sytuacji czas naprawy agregatu
> przez elektryka dyz. przekroczyl niestety maksymalny czas podtrzymania
> napiecia przez systemy UPS-ow.
> [...]
No tak, ale co z tego? Watek dotyczy tego, czy filesystem padnie w razie
awarii dyskow/macierzy. W przypadku przelaczenia zasilania na UPS (w
razie awarii przylacza pradowego) wlacza sie generator - wiec jezeli
zasilanie nie wroci w ciagu czasWlaczeniaGeneratora+jakisMargines, czyli
zachodzi bardzo wysokie prawdopodobienstwo ze za chwile calkowicie
zabraknie pradu, to niestety trzeba odmontowac filesystemy, tak zeby
wykluczyc mozliwosc utraty danych. Dane beda niedostepne dla
uzytkownikow tylko na czas awarii - a nie kilkadziesiat (pesymistyczna
wizja) godzin pozniej.
Wiec jakkolwiek zgadzam sie - awarie sie zdarzaja - to wcale nie musza
oznaczac utraty danych.
A trzymajac sie watku - uzywam XFS na 20 2TB filesystemach serwowanych
przez macierz klasy enterprise i z naszych testow wyraznie wynika, ze
jest najszybsze (kilkadziesiat procent przewagi nad ext3). Jezeli
performance nie jest az tak istotny to chyba polecilbym (z filesystemow
dostepnych w jadrze linuksa) ext3 ze wzgledu na prostote i stosunkowo
dobra odpornosc na awarie (ktorych jednak trzeba unikac :) )

Filip Kata <filip@filipkata.com> writes:

> Nie do końca, SATA ma dużo więcej przekłamań na bitach.

Tak? Ten "Barracuda ES.2 SATA 3.0Gb/s 500GB Hard Drive" ma wiecej
niz "Barracuda ES.2 SAS 3.0-Gb/s 500-GB Hard Drive"?
A moze to odpowiadajacy im Samsung ma wiecej? Tego ostatniego moge
nie kwestionowac, nie lubie Samsungow.

> Do tego trzeba
> by było spojrzeć na mniejsze dyski (wydajność), a nie na typowy
> storage od którego się nie wymaga szybkości (vide 300 i 500 GB).

Cheetah 15K.5 SAS (ST3300655SS) to jest typowy storage, od ktorego
nie wymaga sie szybkosci? Musze przyznac, ze w kazdym razie nie dla
mnie jest takim.
-- 
Krzysztof Halasa

epsilon$ while read LINE; do echo "$LINE"; done < "Marek Magryś"
>Mariusz Kruk pisze:
>> epsilon$ while read LINE; do echo ">$LINE"; done < Filip Kata
>>>>>> Pelny format w 
>>>>>> NTFS. Po kilku dniach pad pradu.
>>>>> Nie rozumiem tego padu prądu... Przecież mam 2 niezależne tory 
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>> zasilania, redundantne UPSy, a na końcu generatory, które pozwalają mi 
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>> działać non stop.
      ^^^^^^^^^^^^^^^^^^
>>>> A i tak może się to zdupcyć.
>>> I nawet się to zdarza, niestety :/
>> 
>> Ano. Jako przestrogę wszystkim uważającym, że redundancja na wszystko
>> pomaga dedykuję na koniec opis pewnej awarii:
>> [...]
>> Przyczyna awarii byl zanik napiecia 15 kV ze STOEN i jednoczesne
>> wystapienie awarii agregatu pradotworczego (agregat testowany byl
>> dwa tygodnie temu). W zaistnialej sytuacji czas naprawy agregatu
>> przez elektryka dyz. przekroczyl niestety maksymalny czas podtrzymania
>> napiecia przez systemy UPS-ow.
>> [...]
>No tak, ale co z tego?

Patrz podkreślenie.


-- 
[------------------------] Microsoft Office 2000: Praca krzepi
[  Kruk@epsilon.eu.org   ] 
[ http://epsilon.eu.org/ ] 
[------------------------] 

Marek Magryś pisze:
>
> No tak, ale co z tego? Watek dotyczy tego, czy filesystem padnie w razie
> awarii dyskow/macierzy. W przypadku przelaczenia zasilania na UPS (w
> razie awarii przylacza pradowego) wlacza sie generator - wiec jezeli
> zasilanie nie wroci w ciagu czasWlaczeniaGeneratora+jakisMargines, czyli
> zachodzi bardzo wysokie prawdopodobienstwo ze za chwile calkowicie
> zabraknie pradu, to niestety trzeba odmontowac filesystemy, tak zeby
> wykluczyc mozliwosc utraty danych.

U mnie nie ma przerwy przy przełączeniu na generator. Wszystko idzie 
przez UPSy więc jak jest spadek napięcia to prąd idzie z baterii, po 
rozgrzaniu agregatu, gdy on zaczyna dostarczać zasilanie to UPSy już nie 
zasilają i tylko filtrują.

-- 
Pozdrawiam
Filip Kata

Krzysztof Halasa pisze:
> Filip Kata <filip@filipkata.com> writes:
> 
>> Nie do końca, SATA ma dużo więcej przekłamań na bitach.
> 
> Tak? Ten "Barracuda ES.2 SATA 3.0Gb/s 500GB Hard Drive" ma wiecej
> niz "Barracuda ES.2 SAS 3.0-Gb/s 500-GB Hard Drive"?

Pomiędzy modelami nie rozgraniczam. To są moje obserwacje ilośi dysków 
SATA i SCSI, które padły w ciągu roku. Przeliczona na 100 dysków z tego 
co pamiętam.

> A moze to odpowiadajacy im Samsung ma wiecej? Tego ostatniego moge
> nie kwestionowac, nie lubie Samsungow.

Jak mam macierz to zazwyczaj są w niej dyski od jednego dostawcy, nie 
mix niewiadomego pochodzenia.

>> Do tego trzeba
>> by było spojrzeć na mniejsze dyski (wydajność), a nie na typowy
>> storage od którego się nie wymaga szybkości (vide 300 i 500 GB).
> 
> Cheetah 15K.5 SAS (ST3300655SS) to jest typowy storage, od ktorego
> nie wymaga sie szybkosci? Musze przyznac, ze w kazdym razie nie dla
> mnie jest takim.

Jeśli chodzi o 146GB to się zgodzę, ale 300 i 500 to nie wydajność. O 
SASach nie wspominam bo dopiero się pojawiły macierze, które je 
obsługują i nie mam porównania.

-- 
Pozdrawiam
Filip Kata

Piotr Skowronski pisze:
> On Mon, 10 Sep 2007 at 16:39 GMT, Krzysztof Halasa <khc@pm.waw.pl> wrote:
>> Filip Kata <filip@filipkata.com> writes:
>>
>>> SATA jest ogólnie cieńkie pod względem żywotności w porównaniu do SCSI.
>> Widze tu dobrze zrobiona robote marketingowa.
> 
> Fakty, fakty, Panowie... Grzecznie poprosze:-) Jakies wyliczenia na
> poparcie obu wypowiedzi? Osobiscie slyszalem, ze MTBF dla dyskow SATA
> liczony jest przy zalozeniu obciazenia 8h/dobe, a dla SCSI 24h/dobe. To do
> mnie przemawia:-) Ale nikt nie zagwarantowal mi tez, ze jest to prawda
> objawiona. Zamieniam sie wiec w sluch:-) i poslucham bardziej
> doswiadczonego towarzystwa:-)

Z moich doświadczeń, statystycznie SATA wypada gorzej(więcej dysków 
zakończyło żywot). Poza tym moża zajrzeć do datasheetów Seagate'a. 
Wybieramy dysk, otwieramy specyfikację i dla dysków mamy MTBF w 
godzinach, lub AFR w skali roku. Przelicznik to:

MTBF = T/AFR , gdzie T = 1 rok = 8760h

MTBF = 8760/AFR

Co do założeń to patrząc tylko na dyski z zastosowaniem 
server/enterprise storage obie wartości są liczone dla pracy 24/7

Do tego możemy również porównać wartości przekłamań na 
bitach(Nonrecoverable Read Errors per Bits Read), których średnio jest 
10 razy więcej.

-- 
Pozdrawiam
Filip Kata

Filip Kata <filip@filipkata.com> writes:

> Pomiędzy modelami nie rozgraniczam. To są moje obserwacje ilośi dysków
> SATA i SCSI, które padły w ciągu roku. Przeliczona na 100 dysków z
> tego co pamiętam.

Ale co to za porownanie, niektore firmy w ogole nie produkuja dyskow
SCSI/SAS, a te, ktore produkuja (PATA/SATA) sa kiepskie.

Pisalem, ze mozna porownywac firmy, po prostu sam interface ma sie
nijak do niezawodnosci, i istnieja dokladnie takie same dyski, tyle
ze z roznymi interfejsami.

> Jak mam macierz to zazwyczaj są w niej dyski od jednego dostawcy, nie
> mix niewiadomego pochodzenia.

Ale jak sa dwie macierze, z czego jedna SCSI, a druga ATA, to
dyski w obu moga byc roznych firm, nie? Wtedy takie porownanie
jest bez sensu, jesli chodzi o porownanie szyn oczywiscie.

>> Cheetah 15K.5 SAS (ST3300655SS) to jest typowy storage, od ktorego
>> nie wymaga sie szybkosci? Musze przyznac, ze w kazdym razie nie dla
>> mnie jest takim.
>
> Jeśli chodzi o 146GB to się zgodzę, ale 300 i 500 to nie wydajność.

Bez zartow, wzialem za przyklad jeden z najszybszych dostepnych
dyskow, jesli te nie sa wydajne (wedlug producenta "fifth-generation
Cheetah 15K is the fastest, highest capacity and most reliable ever",
sztuka kosztuje ponad 3kzl) to ktore sa?

146 od 300 rozni sie wylacznie iloscia talerzy i glowic.

> O
> SASach nie wspominam bo dopiero się pojawiły macierze, które je
> obsługują i nie mam porównania.

To jeden diabel, wez np. ST3300655LW albo LC - to jest dokladnie
to samo, tyle ze z rownoleglym SCSI (ew. SCA) zamiast SAS.
-- 
Krzysztof Halasa

Filip Kata <filip@filipkata.com> writes:

> Z moich doświadczeń, statystycznie SATA wypada gorzej(więcej dysków
> zakończyło żywot).

No tak, ale juz chyba ustalilismy, ze to porownywanie producentow
a nie SATA vs. SCSI.

> Poza tym moża zajrzeć do datasheetów
> Seagate'a. Wybieramy dysk, otwieramy specyfikację i dla dysków mamy
> MTBF w godzinach, lub AFR w skali roku.

Jasne, ale juz chyba pokazalem, ze wartosci moga byc identyczne,
i tylko nieznacznie mniejsze (nie do zauwazenia przez "normalnego"
klienta) od najbardziej niezawodnego i w ogole super hiper dysku,
jaki tylko jest dostepny.

> Do tego możemy również porównać wartości przekłamań na
> bitach(Nonrecoverable Read Errors per Bits Read), których średnio jest
> 10 razy więcej.

Nie liczylem sredniej, ale pokazalem chyba dwa dyski z identycznymi
wartosciami (jeden SCSI, drugi SATA)?
-- 
Krzysztof Halasa

Krzysztof Halasa pisze:
> Filip Kata <filip@filipkata.com> writes:
> 
>> Pomiędzy modelami nie rozgraniczam. To są moje obserwacje ilośi dysków
>> SATA i SCSI, które padły w ciągu roku. Przeliczona na 100 dysków z
>> tego co pamiętam.
> 
> Ale co to za porownanie, niektore firmy w ogole nie produkuja dyskow
> SCSI/SAS, a te, ktore produkuja (PATA/SATA) sa kiepskie.

Ja nie porównywałem firm, gdzie to przeczytałeś? Ja porównywałem dyski z 
takim interfejsem i z takim.

> Pisalem, ze mozna porownywac firmy, po prostu sam interface ma sie
> nijak do niezawodnosci, i istnieja dokladnie takie same dyski, tyle
> ze z roznymi interfejsami.

No to widać jednak robi jakąś różnicę(vide mój post z danymi Seagate'a 
na temat MTBF i errorami), chyba że producenci używają gorszych części 
do produkcji dysków SATA(gdzieś była taka dyskusja).

>> Jak mam macierz to zazwyczaj są w niej dyski od jednego dostawcy, nie
>> mix niewiadomego pochodzenia.
> 
> Ale jak sa dwie macierze, z czego jedna SCSI, a druga ATA, to
> dyski w obu moga byc roznych firm, nie?

W obrębie jednej macierzy raczej nie.

> Wtedy takie porownanie
> jest bez sensu, jesli chodzi o porownanie szyn oczywiscie.
>
>>> Cheetah 15K.5 SAS (ST3300655SS) to jest typowy storage, od ktorego
>>> nie wymaga sie szybkosci? Musze przyznac, ze w kazdym razie nie dla
>>> mnie jest takim.
>> Jeśli chodzi o 146GB to się zgodzę, ale 300 i 500 to nie wydajność.
> 
> Bez zartow, wzialem za przyklad jeden z najszybszych dostepnych
> dyskow, jesli te nie sa wydajne (wedlug producenta "fifth-generation
> Cheetah 15K is the fastest, highest capacity and most reliable ever",
> sztuka kosztuje ponad 3kzl) to ktore sa?

Wg każdego producenta jego dysk jest the fastest, the best, the 
najsuperzajebistszy.

> 146 od 300 rozni sie wylacznie iloscia talerzy i glowic.
> 
>> O
>> SASach nie wspominam bo dopiero się pojawiły macierze, które je
>> obsługują i nie mam porównania.
> 
> To jeden diabel, wez np. ST3300655LW albo LC - to jest dokladnie
> to samo, tyle ze z rownoleglym SCSI (ew. SCA) zamiast SAS.

Pisałem to w kontekście, że jeszcze mi żaden nie padł. Za krótki okres 
czasu do statystyki.

-- 
Pozdrawiam
Filip Kata

Krzysztof Halasa pisze:
> Filip Kata <filip@filipkata.com> writes:
> 
>> Z moich doświadczeń, statystycznie SATA wypada gorzej(więcej dysków
>> zakończyło żywot).
> 
> No tak, ale juz chyba ustalilismy, ze to porownywanie producentow
> a nie SATA vs. SCSI.

Przecież ja nigdzie nie napisałem, że producentów porównuję!

>> Poza tym moża zajrzeć do datasheetów
>> Seagate'a. Wybieramy dysk, otwieramy specyfikację i dla dysków mamy
>> MTBF w godzinach, lub AFR w skali roku.
> 
> Jasne, ale juz chyba pokazalem, ze wartosci moga byc identyczne,
> i tylko nieznacznie mniejsze (nie do zauwazenia przez "normalnego"
> klienta) od najbardziej niezawodnego i w ogole super hiper dysku,
> jaki tylko jest dostepny.
> 
>> Do tego możemy również porównać wartości przekłamań na
>> bitach(Nonrecoverable Read Errors per Bits Read), których średnio jest
>> 10 razy więcej.
> 
> Nie liczylem sredniej, ale pokazalem chyba dwa dyski z identycznymi
> wartosciami (jeden SCSI, drugi SATA)?

Chciałem jeszcze zawęzić, że dla mnie SATA != SAS i to jest pewnie 
źródłem naszej niezgody. Wtedy patrząc na sheety to mamy 10x różnicę. 
SCSI i SAS faktycznie dają podobny poziom.

-- 
Pozdrawiam
Filip Kata

Filip Kata <filip@filipkata.com> writes:

> Ja nie porównywałem firm, gdzie to przeczytałeś? Ja porównywałem dyski
> z takim interfejsem i z takim.

Pisales ze w jednym worku masz ATA, w drugim SCSI - sila rzeczy
producenci tych z pierwszego worka beda (domyslam sie) inni niz
tych z drugiego, bo wielu producentow dyskow SCSI w ogole nie
produkuje.

> No to widać jednak robi jakąś różnicę(vide mój post z danymi Seagate'a
> na temat MTBF i errorami),

Ale tam nie bylo konkretow, a ja pokazalem dwa dyski - jeden SCSI,
drugi SATA, dla ktorych zarowno stopa bledow jak i MTBFy byly
identyczne.

Nie zeby to bylo jakos bardzo dziwne - te dyski roznia sie tylko
elektronika.

> chyba że producenci używają gorszych części
> do produkcji dysków SATA(gdzieś była taka dyskusja).

Dyskusja, nie watpie.

>> Ale jak sa dwie macierze, z czego jedna SCSI, a druga ATA, to
>> dyski w obu moga byc roznych firm, nie?
>
> W obrębie jednej macierzy raczej nie.

Ale, tak zebysmy na pewno dobrze sie zrozumieli, w jednej macierzy
(tej SCSI) moga byc dyski innego producenta niz dyski w macierzy
SATA?

Np. dyski SATA moga byc producenta, ktory dyskow SCSI nie produkuje
w ogole?

Wtedy porownujesz (takze) producentow, mimo ze nawet o tym nie myslisz.

> Wg każdego producenta jego dysk jest the fastest, the best, the
> najsuperzajebistszy.

No to ktory wedlug jakiego producenta jest szybszy i/lub bardziej
niezawodny? Tylko bez Cheetah 15K.6, bo tych nie ma w handlu,
a przynajmniej ja ich nigdzie nie spotkalem.

(Tzn. nie twierdze, ze sie zaden nie znajdzie, bo jakas tam szansa
jest, ale w kazdym razie tamten dysk jest jednym z najbardziej
wydajnych jakie w ogole istnieja).

>> Nie liczylem sredniej, ale pokazalem chyba dwa dyski z identycznymi
>> wartosciami (jeden SCSI, drugi SATA)?
>
> Chciałem jeszcze zawęzić, że dla mnie SATA != SAS i to jest pewnie
> źródłem naszej niezgody.

Watpliwe, biorac pod uwage ze SATA != SAS takze dla mnie, i w ogole
generalnie :-)

SATA = Serial ATA, taki IDE tyle ze szeregowy.
SAS = Serial Attached SCSI, taki SCSI tyle ze szeregowy.

Aczkolwiek dyski SAS mozna podpiac do SATA.

> Wtedy patrząc na sheety to mamy 10x
> różnicę.

Z tym, ze juz pokazalem, ze to jest prawda "inaczej".

> SCSI i SAS faktycznie dają podobny poziom.

SAS to _jest_ SCSI.
SPI (SCSI Parallel Interface) to tylko jedna (albo raczej kilka)
z odmian SCSI :-)


Moze tak: od dluzszego czasu producenci nie produkowali sensowniejszych
dyskow IDE, bo (slusznie) uwazali, ze IDE to rozwiazanie desktopowe,
i ze nikt normalny nie bedzie robil macierzy z badziewia, ktore nawet
bledu parzystosci na szynie nie potrafi wykryc, a jak ktos chce podpiac
tego wiecej niz 2 sztuki, to musi specjalne karty (kazda na kolejne
w sztuki) kupowac.

Dyski IDE tak naprawde nawet do desktopow sie srednio nadawaly.

To byla prawda.


Ale od kilku lat sytuacja sie zmienila - dzisiejsze dyski desktopowe
(nawet PATA) sa lepsze od nieco starszych serwerowych, pojawilo sie
duzo rozwiazan serwerowych SATA (do ktorych mozna podpinac dyski
lub, jesli potrzebne sa mniejsze czasy dostepu, SAS 15k), nie ma
zadnych problemow z hot swapami (przedtem tylko SCA). Producenci
zaczeli produkowac takie same dyski z interfejsem do wyboru
- SATA, SPI (U320 LVD/SE 68-pin SCSI i SCA), FC, SAS.

Zreszta kiedys tak juz bylo, tyle ze zamiast FC i SAS byly wtedy ESDI.
-- 
Krzysztof Halasa

Krzysztof Halasa pisze:
> Filip Kata <filip@filipkata.com> writes:
> 
>>> Nie liczylem sredniej, ale pokazalem chyba dwa dyski z identycznymi
>>> wartosciami (jeden SCSI, drugi SATA)?
>> Chciałem jeszcze zawęzić, że dla mnie SATA != SAS i to jest pewnie
>> źródłem naszej niezgody.
> 
> Watpliwe, biorac pod uwage ze SATA != SAS takze dla mnie, i w ogole
> generalnie :-)
> 
> SATA = Serial ATA, taki IDE tyle ze szeregowy.
> SAS = Serial Attached SCSI, taki SCSI tyle ze szeregowy.

To generalnie się zgadzamy. Good

> Aczkolwiek dyski SAS mozna podpiac do SATA.
> 
>> Wtedy patrząc na sheety to mamy 10x
>> różnicę.
> 
> Z tym, ze juz pokazalem, ze to jest prawda "inaczej".
> 
>> SCSI i SAS faktycznie dają podobny poziom.
> 
> SAS to _jest_ SCSI.

Standard tak, za to za cholerę ten mały dysk mi nie pasuje do DS4800. To 
jednak jest czy nie tak do końca?

> Ale od kilku lat sytuacja sie zmienila - dzisiejsze dyski desktopowe
> (nawet PATA) sa lepsze od nieco starszych serwerowych, pojawilo sie
> duzo rozwiazan serwerowych SATA (do ktorych mozna podpinac dyski
> lub, jesli potrzebne sa mniejsze czasy dostepu, SAS 15k), nie ma
> zadnych problemow z hot swapami (przedtem tylko SCA). Producenci
> zaczeli produkowac takie same dyski z interfejsem do wyboru
> - SATA, SPI (U320 LVD/SE 68-pin SCSI i SCA), FC, SAS.

Problem właśnie w tym, że ja dokładnie na tym oparłem swoje opinie. Nie 
porównywałem dysków, które są teraz wypuszczone tylko dyski w użyciu 
czyli takie zakupione min. rok temu w przeciwnym wypadku ciężko by mi 
było coś porównywać.

-- 
Pozdrawiam
Filip Kata

Filip Kata <imie@imienazwisko.com> writes:

>> SAS to _jest_ SCSI.
>
> Standard tak, za to za cholerę ten mały dysk mi nie pasuje do
> DS4800. To jednak jest czy nie tak do końca?

A mi U-320 SCA nie pasuje do narrow SCSI "Centronics"
a differential (HVD) do DB-25 w makowce. To tez wszystko SCSI :-)

> Problem właśnie w tym, że ja dokładnie na tym oparłem swoje
> opinie. Nie porównywałem dysków, które są teraz wypuszczone tylko
> dyski w użyciu czyli takie zakupione min. rok temu w przeciwnym
> wypadku ciężko by mi było coś porównywać.

Rok temu tez tak bylo.
Owszem, najszybsze dyski wciaz sa tylko SCSI, ale to raczej kwestia
rpmow i czasow pozycjonowania glowicy, nie MTBFow.

No i oczywiscie pozostaje kwestia roznej jakosci sprzetu roznych
producentow.
-- 
Krzysztof Halasa

Krzysztof Halasa pisze:
> Filip Kata <imie@imienazwisko.com> writes:
> 
> Rok temu tez tak bylo.
> Owszem, najszybsze dyski wciaz sa tylko SCSI, ale to raczej kwestia
> rpmow i czasow pozycjonowania glowicy, nie MTBFow.

Nie mówiłem o wydajności podając MTBFy.

> No i oczywiscie pozostaje kwestia roznej jakosci sprzetu roznych
> producentow.

Dlatego w macierzach głównie wsadzają Seagate'a i Hitachi.

-- 
Pozdrawiam
Filip Kata