Układ partycji dla dysków SSD + 3 HDD

Wczoraj dostałem nową stację roboczą z:

• 120 GB - OCZ Vertex3 MAX IOPS
• 300 GB - Western Digital Velociraptor (10 000 obr./min, średnio 4 ms średnio)
• 2x2 TB Samsung Ecogreen F4

System będzie uruchamiał Ubuntu, którego głównym celem będzie dużo rozwoju Java. Czasami muszę opracować Javę w Windows VM; do tego potrzebuję szybkich maszyn wirtualnych. Czytałem dużo o zużyciu dysków SSD i może złym pomysłem jest umieszczenie przestrzeni roboczej Eclipse na dysku SSD, ze względu na wszystkie małe zapisy, które kompilują. Być może obszar roboczy (a więc / dom) może znaleźć lepsze miejsce na Velociraptorze, który jest naprawdę szybki.

Jak powinienem podzielić całą rzecz, aby jak najlepiej ją wykorzystać? Jestem otwarty na wszelkie sugestie. LVM może być również opcją. Może umieszczenie trzeciej partycji na dysku SSD dla jednego obrazu VirtualBox byłoby dobrym pomysłem.

Obecnie myślę:

• SSD: 2 GB / boot, pozostałe miejsce na /
• Velociraptor: LVM obejmujący cały dysk.
  • 150 GB / dom
  • Pozostałe miejsce na / virtualMachines lub coś takiego
• Dyski Samsung (LVM nad każdą lub jedną Grupą Wolumenową dla każdego? - Ostatnie byłoby lepsze pod względem bezpieczeństwa danych, ponieważ jeśli jeden dysk w grupie dużych wolumenów zawiedzie, wszystko zostanie stracone)
  • Partycje dla danych, archiwum itp

Istnieje inna opcja, jeśli niezawodność, niwelowanie zużycia i różnica między prędkością zapisu a prędkością odczytu ma znaczenie:

mam Acard 9010 Napęd RAM z podtrzymaniem bateryjnym, z którego uruchamiam Linuksa. Będzie kosztować więcej niż koszt przeciętnego dysku SSD, ale masz pewne zalety:

• Szybkie prędkości odczytu i duża szybkość zapisu. Dyski SSD mają naprawdę dużą szybkość odczytu i nieco mniejszą szybkość zapisu.
• Nie jest wymagane wyrównywanie zużycia.
• Nie ma obaw o pisanie pełnych dysków wolniej niż pustych dysków w dyskach SSD
• Pociski zasilania są pokrywane przez wewnętrzną baterię przez około dzień, a także można użyć zewnętrznej ścianki do zasilania napędu ram (oprócz wewnętrznej baterii zapasowej).
• Dłuższy czas przechowywania danych na akumulatorze rozwiązuje karta SD wbudowana w urządzenie: gdy zasilanie zostanie wyłączone, a napięcie akumulatora osiągnie pewien niski poziom, RAM-Drive tworzy kopię zapasową zawartości pamięci na 64 GB pamięci flash karta, która jest wbudowana z przodu napędu RAM, po włączeniu zasilania kopiuje dane karty SD z powrotem do pamięci RAM w napędzie RAM.

Aby bezpośrednio odpowiedzieć na część pytania, jak zorganizować partycje na dysku SSD (lub dysku RAM):

Umieściłem wszystko z wyjątkiem /home na dysku barana. /home idzie na dysk twardy. Zajmuje około 5 GB na Slackware64, więc z 32 GB pamięci RAM mam dużo dodatkowej przestrzeni do rozwoju.

Nie musisz wykonywać swojej pracy /home, chociaż jest to normalny „sposób linuxowy”, zamiast tego pomyśl o utworzeniu katalogu w drzewie Linux /java lub /projects który byłby na twoim napędzie RAM, ustawiając uprawnienia i własność, aby twój użytkownik mógł korzystać z tego katalogu i umieścić swoje projekty na dysku SSD / RAM dla prędkości. Umieść swój system operacyjny / narzędzia / kod źródłowy na dysku RAM, pracuj tam, a następnie skopiuj skrypt, który skopiuje twoją codzienną pracę na dysk twardy.

Jako miarę pasów i szelek napisałem kilka prostych skryptów, które wykonują kopie zapasowe ważnych plików utworzonych przez użytkownika, które są na dysku RAM (lub SSD) w razie problemów. Pliki takie jak twój /etc/fstab i /etc/X11/xorg.conf to może być kłopotliwe, aby uzyskać dokładną szybko (szczególnie jeśli masz kilka odtwarzaczy mp3 w fstab lub skomplikowaną konfigurację monitora w xorg.conf itp. w tych plikach), jeśli miałeś problemy z szyfrowaniem SSD / RAM w którymkolwiek momencie.

Mam też parę skryptów do tworzenia kopii zapasowych / przywracania każdego pojedynczego pliku na dysku RAM do katalogu na dysku twardym, na wszelki wypadek. Wspominam o tych skryptach, ponieważ inna odpowiedź wspomniała o problemach z niezawodnością dysków SSD (lub napędów RAM). Skrypty dają mi dodatkową miarę tworzenia kopii zapasowych i łatwego odzyskiwania, jeśli w pewnym momencie coś pójdzie nie tak. Jeśli chcesz, skonfiguruj zadanie chroniące, aby utworzyć kopię zapasową kilka razy dziennie, ale nie jest to zły pomysł.

Więc co robię:

• / na dysku SSD
• /work ( /java lub /projects lub inne) dla obszaru roboczego, na dysku SSD
• /home na dysku twardym
• /usr/scripts (stworzony dla skryptów użytkownika)
• skrypty do tworzenia kopii zapasowych plików konfiguracyjnych użytkownika z dysku SSD na dysk twardy
• skrypty do całkowitego skopiowania dysku RAM na dysk twardy.

Napęd RAM ma czas dostępu 0,01 ms zgodnie z ich stroną internetową. Jest znacznie szybszy niż HD, ale nie podwójny (jak ktoś powiedział wcześniej).

Dysk SSD nie jest niezawodny jako dysk twardy, lepiej używać go jako plików temp / page / scratch zamiast bootowania. Ponieważ masz Velociraptor, SSD nie jest konieczne.

W biurze używam dysku SSD dla mojego podstawowego dysku i tworzę aplikacje C # w systemie Windows XP, Visual Studio szybko buduje i uruchamia debugowanie moich projektów. Używam także dysku SSD w środowisku Hyper-V jako plików stronicowania / wymiany / tymczasowych, aby oddychać HDD. Jeśli potrzebujesz wyższej wydajności, użyj eBoostr aby buforować najczęściej używane pliki, zmniejsza to również zużycie dysku twardego, zwłaszcza na serwerze WWW.