Sprzedaj mi partycjonowanie

Często zastanawiałem się, dlaczego jest taka pasja do partycjonowania dysków, szczególnie w systemach Unixy (/ usr, / var, i in.). To nie wydaje się być częstym motywem w instalacjach Windows.

Wydaje się, że partycjonowanie znacznie zwiększa prawdopodobieństwo zapełnienia jednej partycji, podczas gdy inne mają dużo wolnego miejsca. Oczywiście można temu zapobiec poprzez staranne projektowanie i planowanie, ale wszystko może się zmienić. Doświadczyłem tego wiele razy na komputerach, głównie na urządzeniach konfigurowanych przez innych lub przy domyślnych ustawieniach instalacji danego systemu operacyjnego.

Innym argumentem, który słyszałem, jest to, że upraszcza tworzenie kopii zapasowych. Jak upraszcza tworzenie kopii zapasowych? Słyszałem również, że poprawia to niezawodność. Znowu jak?

Prawie 100% problemów, które napotkałem podczas przechowywania dysku, dotyczy fizycznej awarii dysku. Czy można argumentować, że partycjonowanie może potencjalnie przyspieszyć awarię sprzętu z powodu przeładowania dysku podczas przenoszenia lub kopiowania danych z jednej partycji na drugą na tym samym dysku?

Nie próbuję zbyt mocno kołysać łodzią, chciałbym tylko zobaczyć uzasadnienie dla odwiecznej praktyki administracyjnej.

• Szybszy fsck. Powiedzmy, że twój system z jakiegoś powodu nie działa, a kiedy uruchamia się ponownie, musi uruchomić fsck. Z naprawdę dużą partycją, którą fsck może zająć na zawsze i nic w systemie nie będzie działać, dopóki nie zostanie wykonane fsck całego systemu. Jeśli system zostanie podzielony na partycje, aby partycja główna była dość mała, może być możliwe uruchomienie systemu i uruchomienie niektórych podstawowych usług podczas oczekiwania na zakończenie fsck większych woluminów.
  • jeśli twój system ma małe dyski lub w systemie jest tylko jedna usługa, może to nie mieć znaczenia.
  • W przypadku kronikowanych systemów plików może to nie mieć większego znaczenia, ale czasami nawet w przypadku kronikowanego systemu plików konieczne jest uruchomienie pełnego fsck.
• Poprawione bezpieczeństwo, ponieważ możesz zamontować fs tylko do odczytu.
  • Na przykład nikt nie powinien pisać w / usr podczas normalnego użytkowania. Dlaczego więc nie zamontować systemu plików, aby był on tylko do odczytu. Systemy plików tylko do odczytu, gdy nie trzeba ich zapisywać, zapobiegną niektórym atakom typu skrypt-kiddy i mogą zapobiec zniszczeniu rzeczy, gdy nie masz na myśli.
  • Może to utrudnić utrzymanie systemu, ponieważ konieczne będzie ponowne zainstalowanie go jako odczytu i zapisu, gdy trzeba zastosować aktualizacje.
• Poprawiona wydajność, funkcjonalność dla konkretnej usługi / użytkowania.
  • Niektóre systemy plików są bardziej odpowiednie dla określonych usług / aplikacji lub umożliwiają skonfigurowanie systemu plików, aby w niektórych przypadkach działał lepiej. Może masz system plików z dużą ilością małych plików i potrzebujesz więcej i-węzłów. A może musisz przechowywać duże kilka dużych plików, obrazy dysków wirtualnych.

Nie sądzę, aby konfigurowanie wielu partycji było czymś, co powinieneś zrobić dla każdego systemu. Osobiście na większości serwerów z Linuksem konfiguruję tylko jedną dużą partycję. Ponieważ większość moich systemów ma małe dyski i są przeznaczone do jednego celu i pełnią rolę infrastruktury (dns, dhcp, firewall, router itp.). Na moich serwerach plików konfiguruję partycje, aby oddzielić dane od systemu.

Czy można argumentować, że partycjonowanie może potencjalnie przyspieszyć awarię sprzętu z powodu przeładowania dysku podczas przenoszenia lub kopiowania danych z jednej partycji na drugą na tym samym dysku?

Wątpię, czy dobrze podzielony system miałby większe szanse na awarię.

Jednym z powodów, dla których warto zachować / home / osobno, jest to, że możesz ponownie zainstalować system operacyjny i nigdy nie martwić się utratą danych użytkownika. Poza tym istnieje wiele zabezpieczeń przy montażu wszystkiego albo tylko do odczytu, albo noexec. Jeśli użytkownicy nie mogą uruchamiać kodu w dowolnym miejscu, w którym mogliby napisać kod, oznacza to jeden mniej wektora ataku.

Niepokoiłbym się tym tylko na maszynie publicznej, ponieważ wadą jest brak miejsca na dysku na jednej partycji, ale posiadanie go na innej jest poważną irytacją. Istnieją sposoby obejścia tego problemu, takie jak raid programowy lub ZFS, w którym powinieneś być w stanie dynamicznie zmieniać rozmiar partycji, ale nie mam z nimi doświadczenia.

• Uproszczenie kopii zapasowej

Możesz tworzyć kopie zapasowe (przez zrzuty lub podobne) rzeczy, które chcesz, a nie rzeczy, których nie chcesz. dump (1) jest lepszym systemem tworzenia kopii zapasowych niż tar (1).

• Wypełnianie partycji

To także argument za partycjonowaniem. Użytkownicy wypełniający swoje katalogi domowe nie niszczą serwera, nie usuwają serwera WWW, nie rejestrują dzienników, nie logują się do roota itp.

Pozwala także na bardziej przejrzyste przeniesienie części danych (powiedzmy / home) na inny dysk: skopiuj ją, zamontuj. Jeśli używasz czegoś, co pozwala na kopiowanie w tle / migawki / cokolwiek, możesz to zrobić nawet na żywo.

Zawsze uczono mnie, aby przechowywać / var na osobnej partycji, więc jeśli dostaniesz plik dziennika poza kontrolą, zapchasz jedną partycję, a nie cały dysk. Jeśli znajduje się na tym samym miejscu co reszta systemu i wypełniasz cały dysk w 100%, może się on zawiesić i spowodować nieprzyjemne przywracanie.

Wszystkie argumenty przedstawione przez Zoredache są prawidłowe; można trochę spierać się ze szczegółami (szybsze uruchomienie komputera, abyś mógł robić inne rzeczy, podczas gdy fsck'ing innych systemów plików nie robi ci nic dobrego, jeśli powodem istnienia systemu są te inne systemy plików) ; jednak wszystkie są trochę uzasadnieniem po fakcie.

W naprawdę oldschoolowych czasach nie posiadałeś systemów plików na osobnych partycjach - miałeś je na osobnych dyskach, ponieważ dyski były naprawdę małe. Pomyśl o 10 MB. (1) Więc miałeś mały / partycję, dysk / var, dysk / usr, dysk / tmp i dysk / home. Jeśli potrzebujesz więcej miejsca, kupiłeś inny dysk.

Wtedy „duże” dyski 50 MB zaczęły kosztować mniej niż program księżycowy i nagle stało się możliwe umieszczenie całego systemu na jednym dysku z użyteczną ilością miejsca dla użytkownika.

Mimo to, że rozmiary dysków są małe w porównaniu do tego, co komputer mógł wygenerować, izolowanie / var i / opt i / home, aby zapełnienie jednego nie powodowało obniżenia poziomu komputera, nadal było dobrym pomysłem.

Dzisiaj w sytuacji korporacyjnej nie dzielę systemów operacyjnych na partycje. Dane są dzielone na partycje, zwłaszcza jeśli są generowane przez użytkowników; ale często dzieje się tak, ponieważ działa na szybkich i / lub redundantnych macierzach dyskowych. Jednak / var i / usr żyją na tej samej partycji co /.

W środowisku domowym to samo - / home powinien znajdować się prawdopodobnie na osobnym dysku / macierzy, aby można było zainstalować / uaktualnić / złamać / naprawić dowolne pożądane smaki systemu operacyjnego.

Powodem tego jest to, że bez względu na to, jak duże odgadniesz / var lub / usr, czy cokolwiek innego, drzewo może być przezabawne lub zbyt absurdalne. Jeden z moich starych (er) kolegi z klasy przysięga, że ​​podzielił partycje i zawsze odczuwam od niego żal, kiedy kończy przez 180 dni w systemie, który stworzyłem. Ale mogę liczyć na jedną rękę w całej mojej karierze, ile razy coś jest wypełnione / i obniżyć system, podczas gdy w tym roku mogę policzyć jedną rękę tyle razy, że gapiłem się na system, w którym ktoś zdecydowałem / var nigdy nie będzie musiał być większy niż (powiedzmy) 1 GB i pomyliłem się, zostawiając mnie wpatrzonego w pełną wersję / var i '00s wolnego GB w innym miejscu w systemie, z których wszystkie równie dobrze mogły być na Księżycu dla wszystkich dobro, co mi robią.

W dzisiejszym świecie dużych dysków nie widzę żadnego prawdziwego powodu do partycjonowania drzewa systemu operacyjnego. Dane użytkownika, tak. Ale oddzielne partycje dla / var i / usr i / var / spool itp. Itd. Itd? Nie.

(1) = i wiem, że po prostu wybrałem ten rozmiar, chcę, aby ktoś w komentarzach powiedział 10 MB? Luksus. Dlaczego nasze dyski były po prostu ...

W odpowiedzi na :

Wydaje się, że partycjonowanie znacznie zwiększa prawdopodobieństwo zapełnienia jednej partycji, podczas gdy inne mają dużo wolnego miejsca.

Na komputerze z systemem Linux stosuje się LVM (logiczne zarządzanie woluminami), aby temu zapobiec. Większość systemów plików pozwala na zmianę rozmiaru (niektóre nawet online). Tworzę różne partycje dla różnych zastosowań i formatuję je do różnych systemów plików (np. Xfs dla dużych plików do pobrania, które mogę szybko usunąć). Potrzebuje więcej miejsca? Zamontuj nowy dysk, przenieś do niego dane, a następnie zamontuj go tam, gdzie kiedyś był. Jest całkowicie bezproblemowy dla użytkowników i aplikacji.

Za pomocą LVM można dodawać dyski lub partycje do grupy woluminów, a następnie tworzyć woluminy logiczne w tej grupie. Jeśli pozostawisz wolne miejsce w grupie woluminów, możesz powiększać partycje, które się zapełniają. Jeśli system plików go obsługuje (ext3, ext4, reiserfs), możesz zmniejszyć partycję, którą przesadziłeś.

Na przykład: utwórz partycję rozruchową na / dev / sda1 utwórz drugą (niesformatowaną) partycję / dev / sda2

pvcreate /dev/sda2 # add the partition to LVM
vgcreate vg /dev/sda2 # create a volume group with sda2 in it
lvcreate -n root -L5G vg
lvcreate -n home -L10G vg
lvcreate -n downloads -L100G vg

mkfs.ext3 /dev/vg/root
mkfs.ext4 /dev/vg/home
mkfs.xfs /dev/vg/downloads

mount /dev/vg/root /
mount /dev/vg/home /home
mount /dev/vg/downloads /downloads

Gdy potrzebujesz więcej miejsca na pliki do pobrania / (gdy system plików jest zamontowany):

lvresize -L+50G /dev/vg/downloads
xfs_growfs /dev/vg/downloads

A teraz masz partycję pobierania o pojemności 150 GB. Podobne dla domu. W rzeczywistości dzisiaj właśnie zmieniłem rozmiar „partycji” lvm ext4. Z drugiej strony woluminy logiczne nie są tak naprawdę partycjami, a to, co mówisz o partycjach o niewłaściwym rozmiarze, rozwiewa moje osobiste doświadczenia (więcej kłopotów niż są warte).

Tradycyjny schemat partycjonowania w Uniksie jest zdecydowanie staroświecką praktyką, która nie jest tak przydatna, jak kiedyś. W czasach, gdy czas przestoju systemu Unix był mierzony w latach, a ty miałeś dziesiątki setek użytkowników błąkających się z powłokami, montowanie / usr jako tylko do odczytu było przydatnym sposobem ochrony systemu. Teraz ponowne montowanie systemów plików do łatania wydaje się bardziej pracochłonne i mało przydatne.

Na moim uniwersytecie w dawnych dobrych czasach klastry uniksowe miały systemy plików tylko do odczytu ze standardowymi narzędziami unix, a aplikacje dodatkowe były w / usr / local, który był systemem plików NFS, a później AFS. Częściowo była to wygoda ... kto chciał przekompilować oprogramowanie na kilkunastu urządzeniach w klastrze, kiedy można było uruchamiać aplikacje w szybkiej sieci 4 Mb lub 10 Mb? Dzisiaj, z przyzwoitymi menedżerami pakietów i dużą ilością taniego dysku, nie jest to nic wielkiego.

Myślę, że procesy zaczęły się dla mnie zmieniać w Sun Boxach z Veritas Volume Manager około 1999 roku, co znacznie obniżyło próg bólu przy przenoszeniu dysków.

Dzisiaj, kiedy myślę o partycjonowaniu, myślę o ochronie danych i wydajności. Obrazowy przykład:

• Sieć SAN poziomu 1 jest bardzo szybka, bardzo dostępna (5 9-tych), replikowana i bardzo droga. Tam znajdują się bazy danych lub dzienniki transakcji o kluczowym znaczeniu.
• SAN poziomu 2 jest szybki, dostępny (4 9-ty) i drogi. Tutaj znajdują się aplikacje lub dane o niższym priorytecie.
• SAN 3 poziomu jest dostępny (4 9), tani. Żyją tam rzeczy, które nie są wrażliwe na wydajność.

Te uwagi dotyczą również systemu Windows. Mamy serwer SCCM, który zarządza około 40 tys. Klientów. Baza danych i dzienniki znajdują się na dysku IBM DS8000 mega-buck. Pakiety oprogramowania są na EMC Celerra z dużymi, wolnymi dyskami SATA, które kosztują 60% mniej za GB.

Rozumiem, że to pytanie nie jest specyficzne dla systemu operacyjnego, prawda?

W systemie Windows staram się udostępniać wszystkim moim komputerom jak najmniej partycji, ale nie mniej niż dwie - SYSTEM i DANE. Jeśli maszyna ma dwa dyski fizyczne, wówczas jeden (mniejszy) będzie SYSTEM, a pozostałe DANE. Jeśli jest tylko jeden dysk, podzielę go na dwie partycje.

Powód jest tylko jeden - kiedy muszę ponownie zainstalować maszynę (i będzie taki czas), nie muszę się martwić o zawartość partycji SYSTEM - po prostu robię na niej pełny format i czysta instalacja. To oczywiście oznacza, że ​​moje Dokumenty (a najlepiej także Pulpit) muszą zostać zmapowane do folderu w DANYCH, ale jest to łatwe, szczególnie w systemie Vista i nowszych.

Próbowałem też tworzyć więcej partitonów (takich jak GRY, MUZYKA, FILMY, itp.), Ale to tylko spowodowało, że niektóre z nich przelały się w inne, tworząc więcej bałaganu niż porządku.

(Zakładając, że dostępny jest pojedynczy duży dysk). Położyłem homei varna osobnych partycjach, aby kontrolować problem „poza kontrolą [użytkownik | plik dziennika] wypełniający całe miejsce” i umożliwić łatwe uaktualnienia systemu operacyjnego bez dotykania domu, ale zostaw spoczywajcie razem.

Na starszym sprzęcie czasami trzeba było mieć osobną bootpartycję, aby mieć pewność, że obraz jądra będzie dostępny dla programu ładującego.

Wspominasz o zapełnianiu jednego dysku, podczas gdy na drugim jest wolne miejsce - to jeden z powodów, dla których dzielę partycję - ponieważ mogę zapewnić, że niektóre partycje się nie zapełniają. Chociaż sposób, w jaki zarządzano przydziałami, musiałbyś przypisać wszystkim użytkownikom przydział 0 na pozostałych partycjach, aby upewnić się, że nie zaczną ukrywać plików, jeśli uda im się znaleźć katalog, w którym mógłbym napisać do.

Jeśli chodzi o upraszczanie tworzenia kopii zapasowych - jeśli wiem, jaki będzie maksymalny rozmiar każdej partycji, mogę się upewnić, że jest to rozmiar, który idealnie pasuje do pojedynczej taśmy i można ją ukończyć w ustalonym czasie.

Jeśli chodzi o niezawodność, jedyne, co mogę wymyślić, to monitorowanie - łatwiej mogę zobaczyć, kiedy dana partycja rośnie bardziej niż powinna, i dać mi powód, aby się tym przyjrzeć.

... teraz, biorąc to wszystko pod uwagę, jesteśmy daleko od dni, w których każdy użytkownik otrzymuje swój mały limit 20 MB na wspólnej maszynie. Niektóre stare nawyki nie mają sensu - ale kiedy masz proces, zwariuj i wypełnij / var, który z kolei wypełnia /, a rzeczy się zatrzymują, nie jest tak źle chronić maszyny produkcyjne .

W domu mam partycje, ale tylko po to, aby ułatwić zarządzanie zainstalowanymi systemami operacyjnymi.

Osobiście korzystam z partycjonowania tylko na komputerach mojego dziecka. Tworzę dużą partycję dla systemu operacyjnego i małą partycję dla obrazu partycji systemu operacyjnego, dzięki czemu, gdy maszyna zostanie spakowana, mogę szybko przywrócić ją z obrazu.

W środowisku korporacyjnym nigdy nie słyszałem przekonujących argumentów za partycjonowaniem.

Wszystko z umiarem jest dobrą rzeczą - może być dobrym narzędziem do izolowania problemów w przypadku awarii - takich jak zapełnianie dysku lub uszkodzenie systemu plików.

Nie pomieszaj tego z awarią sprzętową - powinny być one obsługiwane przez nadmiarowość sprzętową (RAID)

Powiedziawszy to, systemy plików w dzisiejszych czasach zawodzą rzadziej - niektórzy nawet sprawdzają integralność online (jak ZFS). Więc mam nadzieję, że fsck offline zniknie w pewnym momencie ...

Z drugiej strony, nadmierne wykonanie tej czynności oznacza tylko więcej pracy (dla ciebie i twojego zespołu) na końcu - po prostu rób to z umiarem i kiedy ma to sens ...