/home - Podstawowa czy logiczna?

[kamzor]

Zawsze borykam się z tym pytaniem
Partycję z gałęzią /home tworzyć podstawową (/dev/sda2) czy logiczną (/dev/sda5)?
Co za a co przeciw? Jestem zielony w tym temacie
I czy opłaca się/co daje zamontowanie innych gałęzi systemu plików na osobnych partycjach?

Pozdrawiam!

[mateo86]

Bez różnicy, ważne żeby partycja na której znajduje się katalog /boot była podstawową. A jeśli masz GRUBa to i windows może być nawet na logicznej partycji zainstalowany, też wystartuje (o linuksie nie wspominam, bo ten to z byle czego startuje ;P).
Wszystko zależy od Twoich upodobań i wygody dla Ciebie. Tak żebyś wiedział gdzie co jest na dysku.

Opłaca się zamontować, wad właściwie nie ma, a nawet jak są, to zalet jest dużo więcej. Chociażby to, że jak chcesz zmienić dystrybucję, to możesz zostawić sobie dane, ustawienia, jakieś własne programy itp. No i bezpiecznie jest mieć /var i /tmp na innych partycjach. W przypadku zapełnienia oddzielnej partycji na której jest /var albo /tmp praktycznie nic się nie dzieje, oprócz tego, że nie będziesz miał co najwyżej logów, ale w przypadku kiedy one znajdują się na jednej i tej samej partycji co /, to wtedy cały system staje. Rozwiązanie głównie dla serwerów, rzadko przydatne w domu, ale przydatne

[arctgx]

I czy opłaca się/co daje zamontowanie innych gałęzi systemu plików na osobnych partycjach?

Oczekiwanie na zakończenie operacji dyskowych zjada u mnie kawał czasu (zerknij narzędzie bootchart - nadaje się do podglądania nie tylko startu systemu), dlatego warto wyobrazić sobie to jak biegają głowice podczas odczytu. Zamiast wyobrażać sobie, lepiej byłoby to sprawdzić, ale nie znam narzędzia, które pozwala w łatwy sposób wyciągać wnioski o pracy dysku (próby opanowania narzędzia blktrace porzuciłem jakiś rok temu) i na podstawie tego zaplanować rozkład partycji. Czas dostępu do danych zależy też od systemu plików i zachowania się kolejki wejścia-wyjścia.

[kamzor]

arctgx: Czy możesz rozwinąć?

[arctgx]

Wyobraź sobie, że jądro swoim algorytmem kolejkowania wejścia-wyjścia (I/O scheduler, np. CFQ, patrz /sys/block/nazwa_dysku/queue/scheduler) uporządkowało w miarę optymalnie kolejkę bloków, do których trzeba skoczyć, by odczytać "zamówione" kawałki danych. Idealna sytuacja to taka, gdy wszystko leży po drodze obok siebie i odczyt polega na ciągłym ruchu głowicy w jedną stronę (bez przeskoków i cofania się).

Ze względu na stałą prędkość obrotową dysku, więcej danych w jednym kawałku czasu można zebrać na zewnętrznych cylindrach, a te odpowiadają początkowym blokom.

Jeśli klepię bzdury, niech mnie ktoś zechce poprawić.

Nie wiem czy to miałeś na myśli. Sporo ciekawych rzeczy znajdziesz w archiwach http://lwn.net/

[kamzor]

A jak bardzo negatywnie na to wpłynie umieszczenie /var i /tmp na osobnych partycjach?

[Robert]

Bez różnicy, ważne żeby partycja na której znajduje się katalog /boot była podstawową.

??

Ja mam zainstalowane linuksy na partycjach logicznych i wszystko śmiga jak należy.
suse 10.2 na hda5 i suse 11.0 na hda7.

[flak]

Pozwolę sobie trochę wtrącić.

Nie wiem jaki jest sens cięcia na różne partycje.

/var i /tmp wyrzuca się na oddzielne partycje by założyć qoutę i tyle. Mówiąc krótko mamy serwer albo świrniętego brata/siostrę.

/boot wyrzuca się na oddzielną partycję w niezrozumiałych dla mnie celach. Jeśli ktoś jest w stanie mi wytłumaczyć sens tego postępowania to proszę niech mi powie bo ja widzę same wady.


@arctgx to kwestia logiki i tu sądzę że masz racje po prostu rozbicie na większą liczbę partycji może ale nie musi wymusić częstsze "skoki" głowicy.

[arctgx]

rozbicie na większą liczbę partycji może ale nie musi wymusić częstsze "skoki" głowicy.

Jasne, że nie ma reguły i dlatego warto mieć narzędzie, które pozwalałoby w miarę łatwo i dobrze monitorować te skoki, by wiadomo było co można spróbować poprawić.

Kiedyś miałem partycję /home wielkości kilku gigabajtów i było słychać (oraz widać po wartościach I/O wait) jak dysk pracuje, by dostać się co chwila do różnych podkatalogów. A to Firefox coś potrzebował zapisać lub odczytać, a to Pidgin czy jeszcze jakiś proces zwykłego użytkownika. Sam /home był położony na rozległej w miarę przestrzeni, a przecież od czasu do czasu głowica musiała wybrać się do /var czy innego systemowego katalogu. Zmniejszenie /home do objętości poniżej gigabajta dało odczuwalnie krótsze odgłosy biegania po dysku. Większe podkatalogi, jak tymczasowce Gimpa lub K3B przerobiłem na dowiązania do katalogów na większej partycji. W odróżnieniu od tego co robią niektóre procesy, nie zaglądam do nich co chwila i mogą sobie leżeć gdzieś dalej

Istnieje polecenie iotop pozwalające przynajmniej wyłapać proces najbardziej żrący przerwania na operacje wejścia-wyjścia (znowu proszę kogoś o uściślenie).

Z tego, co pamiętam, katalog /boot należało kiedyś umieścić na osobnej partycji, gdy BIOS nie potrafił odczytać bloków dysku o adresach powyżej jakiejś wartości. Kiedy już jądro przejmowało sterowanie, poradziło sobie z dostępem.

Ostatnio był jeszcze inny powód. Chcąc mieć system EXT4 na głównej partycji, albo trzeba było zamienić starego GRUB-a na nowy (czyli tzw. GRUB-a Legacy na GRUB-a 2), albo właśnie dać /boot na osobnym systemie plików obsługiwanego przez Legacy. Przy okazji, nie dotyczy to LILO. Ma on ponoć (nie chce mi się teraz sprawdzać tego) bezpośrednie adresy jąder, ramdysków itp. (zapisane po wykonaniu polecenia lilo) i "nie interesują go" systemy plików (swoją drogą, jestem przy tej wizji ciekaw jak wygląda odczyt pofragmentowanego pliku z jądrem - być może w jednym ze stworzonych plików znajdują się instrukcje, jak iść ).

[flak]

Z tego, co pamiętam, katalog /boot należało kiedyś umieścić na osobnej partycji, gdy BIOS nie potrafił odczytać bloków dysku o adresach powyżej jakiejś wartości. Kiedy już jądro przejmowało sterowanie, poradziło sobie z dostępem.

Oj to musiały być bardzo stare komputery. Przy okazji pamiętam że takie numery trzeba było robić na platformie Cobalt  (RaQ etc. http://en.wikipedia.org/wiki/Cobalt_RaQ) Tam okrojony BIOS był jednocześnie bootloaderem który potrafił tylko jedno: załadować jądro systemowe Linux z pierwszej partycji podstawowej sformatowanej do ext2. No ale to jest znowu ograniczenie sprzętu.

Ostatnio był jeszcze inny powód. Chcąc mieć system EXT4 na głównej partycji, albo trzeba było zamienić starego GRUB-a na nowy (czyli tzw. GRUB-a Legacy na GRUB-a 2), albo właśnie dać /boot na osobnym systemie plików obsługiwanego przez Legacy. Przy okazji, nie dotyczy to LILO. Ma on ponoć (nie chce mi się teraz sprawdzać tego) bezpośrednie adresy jąder, ramdysków itp. (zapisane po wykonaniu polecenia lilo) i "nie interesują go" systemy plików (swoją drogą, jestem przy tej wizji ciekaw jak wygląda odczyt pofragmentowanego pliku z jądrem - być może w jednym ze stworzonych plików znajdują się instrukcje, jak iść ).

Grubem się nie bawię więc nie mogę się na ten temat wypowiadać ale pamiętam gdy bawiłem się Reiser4 to boot nie wyciągałem na oddzielną partycję, / na Reiser4 a sterownik jako moduł dorzuciłem do initrd. Pamiętam że lilo nie trzeba było modyfikować.