Zalety systemu plików bez partycji

39

Kilka tygodni temu natknąłem się na coś, czego nigdy wcześniej nie widziałem: system plików (jak sądzę, ext3) zainstalowany na urządzeniu pamięci masowej bez partycji. Zasadniczo /dev/sdb był to cały system plików. Wiem, że wiele systemów plików można rozszerzyć na pustą przestrzeń, więc zrobienie tego pozwala na rozszerzenie bez zajmowania się LVM lub innym rodzajem menedżera woluminów, ale czy są jakieś inne zalety konfigurowania pamięci w ten sposób?

Szczególnym przypadkiem, który widziałem, był efemeryczny wolumen danych dla serwera do kruszenia liczb, woluminy rozruchowe i root były tradycyjnymi partycjami na innym urządzeniu pamięci masowej całkowicie. -

filesystems partition lvm

— sysadmin1138
źródło

Oracle VM również to robi - w przypadku „lokalnego magazynu”.

— Nils

3

Brakowało mi tego pytania i założyłem nowe, które obejmuje ten sam grunt: unix.stackexchange.com/q/52389/4801 . To pytanie zostało już zamknięte, ale niektóre odpowiedzi mogą być przydatne dla czytelników tego Q i mogą zostać tutaj włączone.

— dubiousjim

1

... i jeszcze jeden na unix.stackexchange.com/questions/206141/...

— derobert

Działa, ale prowadzi do problemów, które kończą się marnowaniem czasu, jak pokazano tutaj - access.redhat.com/documentation/en-us/red_hat_enterprise_linux/… .

— slm

24

Pro: nie marnujesz jednego sektora dysku na tablicy partycji. (Tak.)

Pro: dysk może być używany w systemie operacyjnym, który nie obsługuje partycji typu PC. (Jak chcesz użyć jednego).

Con: jest to niezwykłe i może mylić współ-administratorów. (Widzieć?)

Przeciw: jeśli zainstalujesz inny system operacyjny, może pomyśleć, że dysk zawiera śmieci i ułatwi przypadkowe zastąpienie go przez wybranie niewłaściwego dysku - podczas gdy systemy operacyjne zwykle pozostawiają same partycje, których typu nie rozumieją.

Nie ma znaczenia: rozszerzenie systemu plików nie jest łatwiejsze, jeśli znajduje się bezpośrednio na dysku niż w partycji, i odwrotnie. (Posiadanie LVM ułatwiłoby to.)

Wniosek: działa, ale nie jest to dobry pomysł.

— Gilles „SO- przestań być zły”
źródło

2

Zamieszanie, ahoy! Mój wewnętrzny miernik skłania się obecnie ku „nieudanej próbie optymalizacji”.

— sysadmin1138

6

inny minus: utrudnia późniejsze podzielenie partycji na dwie części.

— Kim

3

Spotkałem się z tym superużytkownikiem Pytania i odpowiedzi, na których użyto dobrych przykładów hexdumpi odktóre bardzo konkretnie pokazują, co się dzieje z konfiguracją /dev/sdavs .. /dev/sda1

— slm

4

Rozbudowanie woluminu na całym dysku jest nieco prostsze, ponieważ nie musisz najpierw rozszerzać partycji.

— psusi

2

W środowisku niekomercyjnym instalacja innego systemu operacyjnego może być istotna - ale kto korzysta z wielu systemów operacyjnych w środowisku komercyjnym? Niepokoi mnie, że to kanoniczna odpowiedź. Nie ma w tym nic złego, poza tym, że jest to opinia. Mam wątpliwości co do użycia dysku bez partycji, ale kilka dobrych powodów podano poniżej.

— Graham Nicholls,

18

Nie jestem pewien, jak to by się odnosiło do Linuksa, ale z rodzimym ZFS, jednym z powodów, dla których zaleca się tworzenie pul na całych dyskach, a nie na partycjach, jest w tym pierwszym przypadku pamięć podręczna zapisu dysku.

Wymieniono tu także kilka innych powodów:

http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide#Storage_Pools

Wniosek: działa, i może być dobrym pomysłem w zależności od systemu plików.

— jlliagre
źródło

Dobrze wiedzieć. W tym konkretnym przypadku było to w chmurze! więc pamięć masowa jest dość mocno wyabstrahowana przez czas potrzebny do konfiguracji systemu.

— sysadmin1138

1

Co do cholery ma pamięć podręczna zapisu na dysku, czy tablica partycji jest używana, czy nie?

— psusi

3

Pamięć podręczna zapisu nie może być włączona na poziomie partycji. Po włączeniu wpływa na dysk jako całość. Jeśli system plików używa całego dysku, „jest właścicielem” tego dysku, dzięki czemu może włączać i wyłączać tę pamięć podręczną bez ryzyka związanego z zabezpieczeniami. W przeciwnym razie może to wpłynąć na innego konsumenta dysku wymagającego wyłączenia tej pamięci podręcznej z własnych powodów.

— jlliagre

4

Oczywiście, ale włączenie systemu operacyjnego w oślepiający sposób pamięci podręcznej bez znajomości wymagań systemu plików lub surowego urządzenia nie jest niezawodnym podejściem. Istnieją aplikacje takie jak bazy danych, które muszą upewnić się, że zatwierdzona transakcja odbywa się na dysku, a nie tylko w pamięci.

— jlliagre

1

@psusi To, czy fsync opróżni pamięć podręczną dysku, czy nie, zależy od systemu plików.

— jlliagre

16

Widzę prawdziwą korzyść, gdy odbywa się to w środowisku wirtualnym. Ponieważ nasze VMDK są przechowywane na naszym serwerze NAS, możemy je dynamicznie rozwijać.

Jeśli używamy partycji, musimy użyć LVM (i związane z nim koszty ogólne) i połączyć ze sobą partycje, lub musimy zdjąć host (lub system plików, jeśli nie jest używany), aby użyć czegoś takiego jak gparted.

Jeśli jednak użyjesz całego dysku zamiast partycji, możesz wymusić ponowne skanowanie na dyskach SCSI i użyć resize2fs do rozbudowy systemu plików, gdy jest on online (i jest w użyciu!).

— Nick Gasparowicz
źródło

Słuszna uwaga! W przypadku dysków wirtualnych (ponieważ można je tworzyć, usuwać i zmieniać ich rozmiar w razie potrzeby) partycje wydają się bezużyteczną warstwą.

— pabouk

11

Umieszczenie systemu plików na dysku bez tworzenia partycji nie jest niczym niezwykłym.

Zalety:

kiedy i tak chcesz wykorzystać całą przestrzeń, nie musisz tracić czasu na jakieś narzędzie do partycjonowania
nie musisz się martwić o niezgodność „standardowego” formatu partycji (btw, jaki format partycji jest standardowy, DOS, BSD?), np. format partycji DOS dopuszcza tylko partycje do 2 TB 512 bajtów sektorów logicznych!
nie musisz się martwić o problemy z wyrównaniem partycji na dyskach z (obecnie) nietypowymi rozmiarami sektorów (np. 4 k) - oczywiście, obecne dystrybucje powinny dostarczać narzędzia do partycjonowania, które poprawiają wyrównanie z różnymi rozmiarami sektorów

Możliwość zmiany rozmiaru systemu plików na surowym urządzeniu nie jest dobrym powodem. Miejsce, które oszczędzasz w ten sposób, nie możesz wykorzystać na inne rzeczy. W ten sposób możesz bezpośrednio utworzyć system plików na całym urządzeniu.

— maxschlepzig
źródło

2

Odpowiedź, której nie wymieniono, brzmi: jeśli nie utworzysz partycji, nie musisz czekać, aż jądro ją wykryje, co może nastąpić dopiero po ponownym uruchomieniu.

Jednym z przypadków użycia może być wolumin EBS EC2, który dodajesz do węzła i chcesz zainicjować przy pierwszym uruchomieniu.

Jeśli proces inicjowania tworzy partycję, istnieje ryzyko ponownego uruchomienia jądra, aby zobaczyć nowo utworzoną partycję. Zwykle pojawia się komunikat:

Błąd: Błąd informujący jądro o modyfikacjach partycji / dev / xvde1 - Urządzenie lub zasób zajęte. Oznacza to, że Linux nie będzie wiedział o żadnych zmianach wprowadzonych w / dev / xvde1, dopóki nie uruchomisz ponownie komputera - więc nie powinieneś go montować ani używać w jakikolwiek sposób przed ponownym uruchomieniem komputera.

W takim przypadku proces inicjalizacji musiałby wykonać restart, a następnie kontynuować dodawanie systemu plików do nowo utworzonej partycji.

Jeśli wiesz, że będziesz potrzebować tylko jednej partycji, równie dobrze możesz ją pominąć, nie ryzykując ponownego uruchomienia.

— Lloesche
źródło