Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
RAID 5 na mdadm jaki system wybrać? 32 czy 64 bit
38 views
Skip to first unread message
Servant
Dec 22, 2011, 8:57:02 AM12/22/11
to
No i stanęło na tym że robimy RAID programowo.
Prezes nie chce ryzykować ewentualnego padu dedykowanej karty.
;-)
Mam w tej chwili 2GB RAM. Chcę dokupić jeszcze 8GB.
Co do portów SATA II, to na płycie mam 6 sztuk
(INTEL S5000VSA)
Teraz mam pytamie:
Przeinstalować system na 64 bit, czy zostawic 32?
Na serwerze działa samba, firebird i poczta (postfix, dovecot)
tylko wewnątrz LAN.
Dystrybucja Slackware 13.0
--
Pozdrawiam
Servant
Prezes nie chce ryzykować ewentualnego padu dedykowanej karty.
;-)
Mam w tej chwili 2GB RAM. Chcę dokupić jeszcze 8GB.
Co do portów SATA II, to na płycie mam 6 sztuk
(INTEL S5000VSA)
Teraz mam pytamie:
Przeinstalować system na 64 bit, czy zostawic 32?
Na serwerze działa samba, firebird i poczta (postfix, dovecot)
tylko wewnątrz LAN.
Dystrybucja Slackware 13.0
--
Pozdrawiam
Servant
Sergiusz Rozanski
Dec 22, 2011, 5:49:31 PM12/22/11
to
szybciej się upgradujesz tym mniej roboty w przyszłości - jak dojdzie
usług.
Daniel Podlejski
Dec 23, 2011, 3:25:38 AM12/23/11
to
Sergiusz Rozanski napisał:
> > Przeinstalować system na 64 bit, czy zostawic 32?
> > Na serwerze działa samba, firebird i poczta (postfix, dovecot)
Bo jeśli będą to procesy typu "male a dużo" (dovecot, postfix, samba,
apache) to 64 bity nie mają sensu, a wręcz przeciwnie - różnice
architektoniczne spowodują, że procesów zmieści się w pamięci mniej,
niż na systemie 32 bitowym, w efekcie zostanie mniej RAMu na cache,
i będzie gorzej.
--
Daniel Podlejski
> > Przeinstalować system na 64 bit, czy zostawic 32?
> > Na serwerze działa samba, firebird i poczta (postfix, dovecot)
> No jak 8GB to 64bit - niby jest pae, ale to nie to samo, czym
> szybciej się upgradujesz tym mniej roboty w przyszłości - jak dojdzie
> usług.
A któraś z nich będzie wymagała alokacji > 2GB RAMu?
> szybciej się upgradujesz tym mniej roboty w przyszłości - jak dojdzie
> usług.
Bo jeśli będą to procesy typu "male a dużo" (dovecot, postfix, samba,
apache) to 64 bity nie mają sensu, a wręcz przeciwnie - różnice
architektoniczne spowodują, że procesów zmieści się w pamięci mniej,
niż na systemie 32 bitowym, w efekcie zostanie mniej RAMu na cache,
i będzie gorzej.
--
Daniel Podlejski
Sergiusz Rozanski
Dec 23, 2011, 4:35:55 AM12/23/11
to
głównie) 2x tyle rejestrów, co oznacza że kompilacje 64-bitowe się mniej
zrzucają do ram, a w efekcie mogą chodzić szybciej (w końcu rejestry to
najszybsza pamięć w kompie).
Ale nie prowadźmy dyskusji akademickich o wyrywaniu ze systemu mikrosekund
w tą czy w tamtą - idzie nowe i czym szybciej się na 64-bit przesiądziemy
tym w przyszłości - gdy taka migracja okaże się wymaganą (bo w końcu
poznikają distra 32bitowe lub zechcemy używać softu tylko dla 64 lub
pojawią się płyty chipsety bez pae - rezygnując ze wstecznej kompatybilności
w celu np energooszczędności czy wydajności) - tym będzie łatwiej.
Daniel Podlejski
Dec 23, 2011, 5:55:31 AM12/23/11
to
Sergiusz Rozanski napisał:
> Ale nie prowadźmy dyskusji akademickich o wyrywaniu ze systemu mikrosekund
> w tą czy w tamtą - idzie nowe i czym szybciej się na 64-bit przesiądziemy
> tym w przyszłości - gdy taka migracja okaże się wymaganą (bo w końcu
> poznikają distra 32bitowe lub zechcemy używać softu tylko dla 64 lub
> pojawią się płyty chipsety bez pae - rezygnując ze wstecznej kompatybilności
> w celu np energooszczędności czy wydajności) - tym będzie łatwiej.
Pewnie te płyty będą bez problemu obsługiwać 16 razy więcej RAMu,
który będzie 4 razy tańszy.
Ale póki co nie sensu na siłę pchać systemół 64-bitowych gdzie popadnie,
jeśli nie ma takiej potrzeby i nie przynosi to żadnych realnych zysków.
A już szczególnie nie ma co polecać systemu 64-bitowego komuś, kto ma
2GB RAMu w serwerze, i może za jakiś czas dołoży do tego kolejne 6GB.
--
Daniel Podlejski
> Ale nie prowadźmy dyskusji akademickich o wyrywaniu ze systemu mikrosekund
> w tą czy w tamtą - idzie nowe i czym szybciej się na 64-bit przesiądziemy
> tym w przyszłości - gdy taka migracja okaże się wymaganą (bo w końcu
> poznikają distra 32bitowe lub zechcemy używać softu tylko dla 64 lub
> pojawią się płyty chipsety bez pae - rezygnując ze wstecznej kompatybilności
> w celu np energooszczędności czy wydajności) - tym będzie łatwiej.
który będzie 4 razy tańszy.
Ale póki co nie sensu na siłę pchać systemół 64-bitowych gdzie popadnie,
jeśli nie ma takiej potrzeby i nie przynosi to żadnych realnych zysków.
A już szczególnie nie ma co polecać systemu 64-bitowego komuś, kto ma
2GB RAMu w serwerze, i może za jakiś czas dołoży do tego kolejne 6GB.
--
Daniel Podlejski
Sergiusz Rozanski
Dec 23, 2011, 6:37:49 AM12/23/11
to
Dnia 23.12.2011 Daniel Podlejski <unde...@underley.eu.org> napisał/a:
> Sergiusz Rozanski napisał:
>
>> Ale nie prowadźmy dyskusji akademickich o wyrywaniu ze systemu mikrosekund
>> w tą czy w tamtą - idzie nowe i czym szybciej się na 64-bit przesiądziemy
>> tym w przyszłości - gdy taka migracja okaże się wymaganą (bo w końcu
>> poznikają distra 32bitowe lub zechcemy używać softu tylko dla 64 lub
>> pojawią się płyty chipsety bez pae - rezygnując ze wstecznej kompatybilności
>> w celu np energooszczędności czy wydajności) - tym będzie łatwiej.
>
> Pewnie te płyty będą bez problemu obsługiwać 16 razy więcej RAMu,
> który będzie 4 razy tańszy.
No a 64GB to max dla PAE.
>
>> Ale nie prowadźmy dyskusji akademickich o wyrywaniu ze systemu mikrosekund
>> w tą czy w tamtą - idzie nowe i czym szybciej się na 64-bit przesiądziemy
>> tym w przyszłości - gdy taka migracja okaże się wymaganą (bo w końcu
>> poznikają distra 32bitowe lub zechcemy używać softu tylko dla 64 lub
>> pojawią się płyty chipsety bez pae - rezygnując ze wstecznej kompatybilności
>> w celu np energooszczędności czy wydajności) - tym będzie łatwiej.
>
> Pewnie te płyty będą bez problemu obsługiwać 16 razy więcej RAMu,
> który będzie 4 razy tańszy.
> Ale póki co nie sensu na siłę pchać systemół 64-bitowych gdzie popadnie,
> jeśli nie ma takiej potrzeby i nie przynosi to żadnych realnych zysków.
> A już szczególnie nie ma co polecać systemu 64-bitowego komuś, kto ma
> 2GB RAMu w serwerze, i może za jakiś czas dołoży do tego kolejne 6GB.
zapowiada się mała rewolujca, więc przy okazji taki upgrade nie będzie
wielkim obciążeniem - chodzi o kilka usług i na 100% zaplanowane ich
wylaczenie, a w przyszłości jak bedzie ich naście - będzie trudniej
szczególnie wygospodarować nowy stoptime.
Ja nowe instalacje robie już tylko na 64, biorę pod uwagę przyszłe migracje i
zbędny z tym zmarnowany czas. Nie zapominajmy że te instalacje są raczej
długowieczne, fsy są przenoszone z kompa na komp, z dysku na dysk, mam
instalacje pamiętające instalke z debian-hamm - bez apt :)
Daniel Podlejski
Dec 23, 2011, 7:30:37 AM12/23/11
to
> Ja nowe instalacje robie już tylko na 64, biorę pod uwagę przyszłe migracje i
> zbędny z tym zmarnowany czas. Nie zapominajmy że te instalacje są raczej
> długowieczne, fsy są przenoszone z kompa na komp, z dysku na dysk, mam
> instalacje pamiętające instalke z debian-hamm - bez apt :)
Offtopicując - jeszcze dwa lata temu robiłem/myślałem podobnie.
> zbędny z tym zmarnowany czas. Nie zapominajmy że te instalacje są raczej
> długowieczne, fsy są przenoszone z kompa na komp, z dysku na dysk, mam
> instalacje pamiętające instalke z debian-hamm - bez apt :)
Teraz wolę mieć instalację i konfigurację oskryptowaną w chefowych
cookbookach i martwić się tylko o backup danych krytycznych dla
działania usług. Dzięki temu mogę mieć "kopię" serwera gotową w
kilka(naście) minut. Bardzo przydatne w wielu sytuacjach, nie
tylko awaryjnych.
(z tymi kilkoma minutami to nie ściema - uruchomienie kolejnego
serwera frontendowego na EC2 z chefa rzeczywiście tyle trwa, ale
to już totalny off-topic)
--
Daniel Podlejski
Servant
Dec 23, 2011, 10:06:24 AM12/23/11
to
Sergiusz Rozanski <write-onl...@media-lab.com.pl> napisał(a) w
wiadomosci do grupy dyskusyjnej
> No jak 8GB to 64bit - niby jest pae, ale to nie to samo, czym
> szybciej się upgradujesz tym mniej roboty w przyszłości - jak dojdzie
> usług.
Właściwie, to razem 10GB będzie. Płyta już ma dwa czterordzeniowe
XEONy.
Na razie się nudzą ;-)
--
Pozdrawiam
Servant
wiadomosci do grupy dyskusyjnej
> No jak 8GB to 64bit - niby jest pae, ale to nie to samo, czym
> szybciej się upgradujesz tym mniej roboty w przyszłości - jak dojdzie
> usług.
XEONy.
Na razie się nudzą ;-)
--
Pozdrawiam
Servant
Servant
Dec 23, 2011, 10:08:33 AM12/23/11
to
Daniel Podlejski <unde...@underley.eu.org> napisał(a) w wiadomosci do
grupy dyskusyjnej
> Bo jeśli będą to procesy typu "male a dużo" (dovecot, postfix, samba,
> apache) to 64 bity nie mają sensu,
Właśnie. Moje myślenie też tą ścieżką podążało. Ale Sergiusz R. również
swoje racje ma.
--
Pozdrawiam
Servant
grupy dyskusyjnej
> Bo jeśli będą to procesy typu "male a dużo" (dovecot, postfix, samba,
> apache) to 64 bity nie mają sensu,
swoje racje ma.
--
Pozdrawiam
Servant
Servant
Dec 23, 2011, 10:32:05 AM12/23/11
to
Sergiusz Rozanski <write-onl...@media-lab.com.pl> napisał(a)
mam wersję 3.2.7. Nowsze nie chciały działać. Walczyłem z tym w sunie
kilkanaście godzin, ale poległem. Trzeba by szukać starych źródeł i
kompilować na 64 bit. Paczki slackware_64 są już nowsze.
A na tę "małą rewolucję" musi mi wystarczyć sobota i niedziela gdzieś w
pierwszewj dekadzie stycznia.
--
Pozdrawiam
Servant
w wiadomosci do grupy dyskusyjnej
> ... ten wątek to kontynuacja innego dot. dysków i mirrorów, na tym
> serwerze zapowiada się mała rewolujca, więc przy okazji taki
> upgrade nie będzie wielkim obciążeniem - chodzi o kilka usług i na
> 100% zaplanowane ich wylaczenie, a w przyszłości jak bedzie ich
> naście - będzie trudniej szczególnie wygospodarować nowy stoptime.
>
Teraz jestem w kropce co do 64 bit. Najbardziej obawiam się samby, bo
> serwerze zapowiada się mała rewolujca, więc przy okazji taki
> upgrade nie będzie wielkim obciążeniem - chodzi o kilka usług i na
> 100% zaplanowane ich wylaczenie, a w przyszłości jak bedzie ich
> naście - będzie trudniej szczególnie wygospodarować nowy stoptime.
>
mam wersję 3.2.7. Nowsze nie chciały działać. Walczyłem z tym w sunie
kilkanaście godzin, ale poległem. Trzeba by szukać starych źródeł i
kompilować na 64 bit. Paczki slackware_64 są już nowsze.
A na tę "małą rewolucję" musi mi wystarczyć sobota i niedziela gdzieś w
pierwszewj dekadzie stycznia.
--
Pozdrawiam
Servant
ein
Dec 23, 2011, 10:44:42 AM12/23/11
to
On 12/23/2011 12:37 PM, Sergiusz Rozanski wrote:
> Dnia 23.12.2011 Daniel Podlejski <unde...@underley.eu.org> napisał/a:
>> Sergiusz Rozanski napisał:
>>
>>> Ale nie prowadźmy dyskusji akademickich o wyrywaniu ze systemu mikrosekund
>>> w tą czy w tamtą - idzie nowe i czym szybciej się na 64-bit przesiądziemy
>>> tym w przyszłości - gdy taka migracja okaże się wymaganą (bo w końcu
>>> poznikają distra 32bitowe lub zechcemy używać softu tylko dla 64 lub
>>> pojawią się płyty chipsety bez pae - rezygnując ze wstecznej kompatybilności
>>> w celu np energooszczędności czy wydajności) - tym będzie łatwiej.
>>
>> Pewnie te płyty będą bez problemu obsługiwać 16 razy więcej RAMu,
>> który będzie 4 razy tańszy.
>
> No a 64GB to max dla PAE.
>
>> Ale póki co nie sensu na siłę pchać systemół 64-bitowych gdzie popadnie,
>> jeśli nie ma takiej potrzeby i nie przynosi to żadnych realnych zysków.
>
> Nie na siłę ale ...
OK, a gdzie Wyście wyczytali, że dla 32 bitowego procesora limitem
> Dnia 23.12.2011 Daniel Podlejski <unde...@underley.eu.org> napisał/a:
>> Sergiusz Rozanski napisał:
>>
>>> Ale nie prowadźmy dyskusji akademickich o wyrywaniu ze systemu mikrosekund
>>> w tą czy w tamtą - idzie nowe i czym szybciej się na 64-bit przesiądziemy
>>> tym w przyszłości - gdy taka migracja okaże się wymaganą (bo w końcu
>>> poznikają distra 32bitowe lub zechcemy używać softu tylko dla 64 lub
>>> pojawią się płyty chipsety bez pae - rezygnując ze wstecznej kompatybilności
>>> w celu np energooszczędności czy wydajności) - tym będzie łatwiej.
>>
>> Pewnie te płyty będą bez problemu obsługiwać 16 razy więcej RAMu,
>> który będzie 4 razy tańszy.
>
> No a 64GB to max dla PAE.
>
>> Ale póki co nie sensu na siłę pchać systemół 64-bitowych gdzie popadnie,
>> jeśli nie ma takiej potrzeby i nie przynosi to żadnych realnych zysków.
>
> Nie na siłę ale ...
pamięci jest 2GB...
Daniel Podlejski
Dec 23, 2011, 12:55:53 PM12/23/11
to
ein napisał(a):
> OK, a gdzie Wyście wyczytali, że dla 32 bitowego procesora limitem
> pamięci jest 2GB...
A gdzie ktoś z nas tak twierdzi? Mowa była o limicie alokacji pamięci
przez pojedynczy proces w systemie 32-bitowym (generalnie to jest to
trochę więcej niż 2GB, ale nie jest to 4GB wynikające teoretycznie z
32 bitów adresu).
--
Daniel Podlejski
> OK, a gdzie Wyście wyczytali, że dla 32 bitowego procesora limitem
> pamięci jest 2GB...
przez pojedynczy proces w systemie 32-bitowym (generalnie to jest to
trochę więcej niż 2GB, ale nie jest to 4GB wynikające teoretycznie z
32 bitów adresu).
--
Daniel Podlejski
ein
Dec 23, 2011, 1:23:11 PM12/23/11
to
Sergiusz Rozanski
Dec 23, 2011, 1:42:55 PM12/23/11
to
to PAE aby taki cpu widział do 64GB (ale jako całość) i to wszystko. Limit dla
procesu pozostał. Nie wiem tylko czy pae było w 64bitowcach w tybie 32 czy
również były 32bitowe cpu z pae.
Daniel Podlejski
Dec 23, 2011, 4:17:50 PM12/23/11
to
ein napisał(a):
> No dobra, a skąd bierze się TEN limit dla wątku/procesu?
Z podziału na user-space i kernel-space. AFAIR proces może
zaalokować tylko tą część, która jest przeznaczona na userspace.
--
Daniel Podlejski
> No dobra, a skąd bierze się TEN limit dla wątku/procesu?
zaalokować tylko tą część, która jest przeznaczona na userspace.
--
Daniel Podlejski
panti
Dec 23, 2011, 5:52:06 PM12/23/11
to
Dnia 23.12.2011 Servant <fre...@rcs.cy> napisał/a:
> Teraz jestem w kropce co do 64 bit. Najbardziej obawiam się samby, bo
> mam wersję 3.2.7. Nowsze nie chciały działać. Walczyłem z tym w sunie
Ta wersja samby jest dziurawa. Było uaktualnienie do 3.2.15 lub wyższej
> Teraz jestem w kropce co do 64 bit. Najbardziej obawiam się samby, bo
> mam wersję 3.2.7. Nowsze nie chciały działać. Walczyłem z tym w sunie
w nowszym wydaniu dystrybucji, ale to Twoja maszyna ...
Servant
Dec 24, 2011, 4:49:07 PM12/24/11
to
panti <panti...@zgotu.pl> napisaďż˝(a) w wiadomosci do grupy
dyskusyjnej
> Ta wersja samby jest dziurawa. By�o uaktualnienie do 3.2.15 lub
> wy�szej w nowszym wydaniu dystrybucji, ale to Twoja maszyna ...
Zmobiliozowa�e� mnie.
B��d znalaz�em.
Dzi�ki.
--
Pozdrawiam
Servant
dyskusyjnej
> Ta wersja samby jest dziurawa. By�o uaktualnienie do 3.2.15 lub
> wy�szej w nowszym wydaniu dystrybucji, ale to Twoja maszyna ...
Zmobiliozowa�e� mnie.
B��d znalaz�em.
Dzi�ki.
--
Pozdrawiam
Servant
Krzysztof Halasa
Dec 25, 2011, 10:23:28 AM12/25/11
to
Daniel Podlejski <unde...@underley.eu.org> writes:
> A już szczególnie nie ma co polecać systemu 64-bitowego komuś, kto ma
> 2GB RAMu w serwerze, i może za jakiś czas dołoży do tego kolejne 6GB.
Na tej tylko podstawie, jasne że nie.
> A już szczególnie nie ma co polecać systemu 64-bitowego komuś, kto ma
> 2GB RAMu w serwerze, i może za jakiś czas dołoży do tego kolejne 6GB.
Na podstawie tylko podanych informacji, będzie dokladnie obojętne jaka
wersja systemu będzie używana. Ktoś pisał że będzie "dużo małych
procesów" - ja myślę, że to będzie raczej "mało małych procesów".
Natomiast w ogóle system 64-bitowy może być wymagany przez bardzo
trywialne rzeczy. Np. ja ostatnio będę chyba musiał użyć x86-64 na
maszynce z Core 2 Duo ULV 1200 MHz + 1 GB RAM. Dlaczego? Bo jeden
z plików, taki o długości 35 GB, będzie musiał być mapowany w RAM.
Generalnie w przypadku normalnych, względnie współczesnych maszynek,
system 64-bitowy "nie gryzie" (pomijąc ew. problemy z 32-bitowymi
binariami, które nie mogą być np. bezpośrednio pluginami). System
32-bitowy, mimo że może być minimalnie bardziej (lub mniej) wydajny,
może się w ogóle nie nadawać do konkretnego zastosowania. Wniosek jest
IMHO prosty, należy polecać "w ciemno" wersję x86-64.
Wesołych Swiąt,
--
Krzysztof Halasa
Krzysztof Halasa
Dec 25, 2011, 10:35:29 AM12/25/11
to
Sergiusz Rozanski <write-onl...@media-lab.com.pl> writes:
> Nie wiem tylko czy pae było w 64bitowcach w tybie 32 czy
> również były 32bitowe cpu z pae.
PAE było w 32-bitowych CPU od czasów chyba Pentium Pro.
> Nie wiem tylko czy pae było w 64bitowcach w tybie 32 czy
> również były 32bitowe cpu z pae.
--
Krzysztof Halasa
Krzysztof Halasa
Dec 25, 2011, 10:38:55 AM12/25/11
to
Daniel Podlejski <unde...@underley.eu.org> writes:
> Z podziału na user-space i kernel-space. AFAIR proces może
> zaalokować tylko tą część, która jest przeznaczona na userspace.
Eee tam. Teraz to już nie ma praktycznego znaczenia, ale przez długi
> Z podziału na user-space i kernel-space. AFAIR proces może
> zaalokować tylko tą część, która jest przeznaczona na userspace.
czas dość popularny był split "4G/4G", który cała przestrzeń adresową
oddawał jednoczeście obu "częściom" (kosztem pewnych kombinacji
przy przechodzeniu między trybami user i kernel, oraz podczas np.
transferów z/do pamięci user space w trybie kernela).
--
Krzysztof Halasa
Servant
Dec 25, 2011, 2:59:47 PM12/25/11
to
Krzysztof Halasa <k...@pm.waw.pl> napisał(a) w wiadomosci do grupy
dyskusyjnej
> Wniosek jest
> IMHO prosty, należy polecać "w ciemno" wersję x86-64.
Witam
A w mojej konkretnej sytuacji co byś zastosował?
Ponadto mam jeszcze pytanie w kwestii technicznej.
Mam w tej chwili 3 dyski 1TB podzielone każdy na dwie równe partycje.
System w zasadzie leży na oddzielnym dysku 250GB PATA (katalogi /home i
/opt zlinkowane na partycje dysków terabajtowych)
Kombinuję tak: Kupuję 3 nowe dyski 1TB.
Tamte 3 wypinam, Podłączam nowe, formatuję i tworzę raid.
Następnie podłączam kolejno dyski z danymi, kopiuje dane na macierz.
Po skopiowaniu dysk formatuję i podłączam do macierzy jako kolejny
czwarty i piąty.
Jeden dysk co mi zostanie podłączę oddzielnie i przeznaczę na kopie
Ma to szanse powodzenia?
--
Pozdrawiam
Servant
dyskusyjnej
> Wniosek jest
> IMHO prosty, należy polecać "w ciemno" wersję x86-64.
A w mojej konkretnej sytuacji co byś zastosował?
Ponadto mam jeszcze pytanie w kwestii technicznej.
Mam w tej chwili 3 dyski 1TB podzielone każdy na dwie równe partycje.
System w zasadzie leży na oddzielnym dysku 250GB PATA (katalogi /home i
/opt zlinkowane na partycje dysków terabajtowych)
Kombinuję tak: Kupuję 3 nowe dyski 1TB.
Tamte 3 wypinam, Podłączam nowe, formatuję i tworzę raid.
Następnie podłączam kolejno dyski z danymi, kopiuje dane na macierz.
Po skopiowaniu dysk formatuję i podłączam do macierzy jako kolejny
czwarty i piąty.
Jeden dysk co mi zostanie podłączę oddzielnie i przeznaczę na kopie
Ma to szanse powodzenia?
--
Pozdrawiam
Servant
Krzysztof Halasa
Dec 27, 2011, 1:43:06 PM12/27/11
to
Servant <fre...@rcs.cy> writes:
>> Wniosek jest
>> IMHO prosty, należy polecać "w ciemno" wersję x86-64.
>
> Witam
> A w mojej konkretnej sytuacji co byś zastosował?
To co w każdej innej, tak jak napisałem wyżej. Chyba że są uzasadnione
>> Wniosek jest
>> IMHO prosty, należy polecać "w ciemno" wersję x86-64.
>
> Witam
> A w mojej konkretnej sytuacji co byś zastosował?
argumenty by tego nie robić, ale (względnie) wypasiona maszynka +
niewielkie obciążenie nie są takimi argumentami.
Odwrotnie, maszynka całkowicie obciążona - można się zastanawiać.
> Mam w tej chwili 3 dyski 1TB podzielone każdy na dwie równe partycje.
> System w zasadzie leży na oddzielnym dysku 250GB PATA (katalogi /home i
> /opt zlinkowane na partycje dysków terabajtowych)
> Kombinuję tak: Kupuję 3 nowe dyski 1TB.
> Tamte 3 wypinam, Podłączam nowe, formatuję i tworzę raid.
> Następnie podłączam kolejno dyski z danymi, kopiuje dane na macierz.
> Po skopiowaniu dysk formatuję i podłączam do macierzy jako kolejny
> czwarty i piąty.
> Jeden dysk co mi zostanie podłączę oddzielnie i przeznaczę na kopie
> Ma to szanse powodzenia?
przynajmniej), bo informację na dyskach bardzo łatwo stracić, zarówno
jeśli się w nich ostro grzebie, jak i bez żadnego własnego udziału.
Myślę że to jest do zrobienia, ale najważniejsze jest dobre
zaprojektowanie docelowego rozwiązania.
--
Krzysztof Halasa
Servant
Dec 28, 2011, 4:56:52 AM12/28/11
to
> Jaki dokładnie RAID?
RAID 5.
Trzy dyski ponoć wystarczą na początek.
--
Pozdrawiam
Servant
RAID 5.
Trzy dyski ponoć wystarczą na początek.
--
Pozdrawiam
Servant
Krzysztof Halasa
Dec 28, 2011, 12:49:13 PM12/28/11
to
No tak.
Jedyne co moge dodać, to to, że osobiście nie lubię RAIDów-5, i zamiast
nich stosuję praktycznie wyłącznie RAID-1 i RAID-10 (a czasem także
sam stripping bez redundancji ("RAID-0")).
Tzn. pewnie w przypadku dużych macierzy użyłbym RAID-5 lub 6, ale taka
"duża" macierz musiałaby mieć przynajmniej z 5 dysków (= 8 dysków
w RAID1+0 lub 10), tak na oko obecnie 8 albo np. 12 TB. Przy mniejszych
to się moim zdaniem, przy obecnych relatywnie niedużych cenach dysków,
nie opłaca.
Ale to tylko taka moja subiektywna opinia :-)
--
Krzysztof Halasa
Jedyne co moge dodać, to to, że osobiście nie lubię RAIDów-5, i zamiast
nich stosuję praktycznie wyłącznie RAID-1 i RAID-10 (a czasem także
sam stripping bez redundancji ("RAID-0")).
Tzn. pewnie w przypadku dużych macierzy użyłbym RAID-5 lub 6, ale taka
"duża" macierz musiałaby mieć przynajmniej z 5 dysków (= 8 dysków
w RAID1+0 lub 10), tak na oko obecnie 8 albo np. 12 TB. Przy mniejszych
to się moim zdaniem, przy obecnych relatywnie niedużych cenach dysków,
nie opłaca.
Ale to tylko taka moja subiektywna opinia :-)
--
Krzysztof Halasa
Daniel Podlejski
Dec 28, 2011, 3:49:21 PM12/28/11
to
Krzysztof Halasa napisał:
> Jedyne co moge dodać, to to, że osobiście nie lubię RAIDów-5, i zamiast
+1 ;)
> nich stosuję praktycznie wyłącznie RAID-1 i RAID-10 (a czasem także
> sam stripping bez redundancji ("RAID-0")).
Pomysłem do rozważenia zamiast RAID-5 może być RAID-1E:
http://en.wikipedia.org/wiki/RAID_1E#RAID_1E
Da się zrealizować na bazie linuksowego RAIDu softwareowego.
--
Daniel Podlejski
> Jedyne co moge dodać, to to, że osobiście nie lubię RAIDów-5, i zamiast
> nich stosuję praktycznie wyłącznie RAID-1 i RAID-10 (a czasem także
> sam stripping bez redundancji ("RAID-0")).
http://en.wikipedia.org/wiki/RAID_1E#RAID_1E
Da się zrealizować na bazie linuksowego RAIDu softwareowego.
--
Daniel Podlejski
Servant
Dec 31, 2011, 4:21:08 PM12/31/11
to
Krzysztof Halasa <k...@pm.waw.pl> napisaďż˝(a) w wiadomosci do grupy
dyskusyjnej
> taka
> "du�a" macierz musia�aby mie� przynajmniej z 5 dysk�w
W�a�nie tyle b�dzie mie� docelowo po zrzuceniu wszystkich danych z
dysk�w, kt�re "chodz�" teraz.
--
Pozdrawiam
Servant
dyskusyjnej
> taka
> "du�a" macierz musia�aby mie� przynajmniej z 5 dysk�w
W�a�nie tyle b�dzie mie� docelowo po zrzuceniu wszystkich danych z
dysk�w, kt�re "chodz�" teraz.
--
Pozdrawiam
Servant
Bartosz
Mar 29, 2012, 4:19:02 AM3/29/12
to
> No jak 8GB to 64bit - niby jest pae, ale to nie to samo, czym
> szybciej się upgradujesz tym mniej roboty w przyszłości - jak dojdzie
> usług.
Nie wiem jak na 2GB RAM czy na 8GB ale na:
> szybciej się upgradujesz tym mniej roboty w przyszłości - jak dojdzie
> usług.
Na 64bitach 16GB RAM (bo pamięc tania jak barszcz), RAID-5 programowy 3xSATAII, kernel 3.2.13 śmiga tak że palce lizać.
Pliki do 2GB w 5 sekund zapis (keszuje) a większe 8GB pliki zapisuje z prędkością 160MBs a odczyt ~180MBs przy obciążeniu
maksymalnym chwilowym do 40% rdzenia, średnio ok 15% rdzenia. Rdzeni mam sporo więc pomijalne dla mnie obciążenie.
Nie bardzo tylko rozumiem akąd u ciebie dylemat nad 32 czy 64 bitami ?
Od wielu lat stosuję już 64bit i wszystko hula bezproblemowo i tylko raz się spotkałem z aplikacją (mrtg) która buntowała się z
działaniem na 64bitach. Po aktualizacji działa.
Pamiętaj o tym, że jak zainstalujesz 32bity to zapomnij o dokładaniu pamięci, tylko ok 3GB z hakim i nic ponadto, w zwiazku z czym
jakiekolwiek zastanawianie się dla mnie w 2011 czy 2012r nad wyborem wersji jest dla mnie śmieszny i oczywisty TYLKO 64bit.
Pozdrawiam.
Bartosz Bartczak
Sep 20, 2012, 10:10:23 AM9/20/12
to
Tak si� przys�uchuj� dyskusji i nie rozumiem sk�d te dylematy nad 64bitami ?
U mnie RAID5 dzia�a jak miodzio 3 x SATAII. Transfer 150MB/s RW, 16GB RAM bo
tani by� jak woda wi�c wszystkie porty obsadzone. Wzia�bym 32GB RAM ale nie
by�o kostek na rynku 8GB jak sk�ada�em.
Procesor mocny nudzi si� ca�y czas z tym raidem. Przy pe�nym obci�zeniu max
chyba 30% jednego rdzenia.
Dwa dyski ju� w tym rajdzie pad�y na szcz�cie nie na raz i zosta�y
wymienione (5 letnia gwarancja Seagate).
Troszk� gimnastyki i adrenaliny by�o na poczatku jak pierwszy raz
przywraca�em ale dzia�a super.
Ja bym si� nie zastanawia� i bra� 64bit. Jak by� widzia� 2GB/s osi�gam w
zapisie to koledzy oczy wywalaj� ;)
A on sobie �adnie keszuje i kernel nagrywa w tle (UPS zabezpiecza)
Bierz 64bit bez zastanowienia i jak masz pytania wal.
Naci�gnij tylko szefa na maksimum ramu ile si� da a nie po�a�ujesz w
praktyce ;)
Pozdrawiam
Bartosz Bartczak
U mnie RAID5 dzia�a jak miodzio 3 x SATAII. Transfer 150MB/s RW, 16GB RAM bo
tani by� jak woda wi�c wszystkie porty obsadzone. Wzia�bym 32GB RAM ale nie
by�o kostek na rynku 8GB jak sk�ada�em.
Procesor mocny nudzi si� ca�y czas z tym raidem. Przy pe�nym obci�zeniu max
chyba 30% jednego rdzenia.
Dwa dyski ju� w tym rajdzie pad�y na szcz�cie nie na raz i zosta�y
wymienione (5 letnia gwarancja Seagate).
Troszk� gimnastyki i adrenaliny by�o na poczatku jak pierwszy raz
przywraca�em ale dzia�a super.
Ja bym si� nie zastanawia� i bra� 64bit. Jak by� widzia� 2GB/s osi�gam w
zapisie to koledzy oczy wywalaj� ;)
A on sobie �adnie keszuje i kernel nagrywa w tle (UPS zabezpiecza)
Bierz 64bit bez zastanowienia i jak masz pytania wal.
Naci�gnij tylko szefa na maksimum ramu ile si� da a nie po�a�ujesz w
praktyce ;)
Pozdrawiam
Bartosz Bartczak
0 new messages