Partíció kell?

Sziasztok,

Részemről sok helyen nem nagyon használok már partíciót. Ext4-es raid tükörnél sem mindig, habár ott néha hasznos hogy kisebbre tegyük kicsivel a méretet, így új diszknél nem lesz gond ha kisebb a fizikai méret, mert ugye kisebbre nem lehet sync-elni ha diszket kell cserélni.

Viszont BtrFS munkaállomáson sem igen használok már. Simán formázom az sdb-t.

Milyen esetekben lehet vajon hátrány a hiányzó partíció Linux alatt (például ha nem kell swap) ?

Hozzászólások

Szerintem nem kell. Gondolj csak az LVM-re! Akár több fizikai eszközön is áthúzódhat egy filerendszer.

Partíció csak akkor kell, ha egy konténerrel ki akarod jelölni a folerendszer helyét, s nem használsz LVM-et vagy btrfs-t. Én általában csinálok partíciót, hiszen vékony réteg, de már magam sem tudom, miért. Ja, mert úgy tudtam, a Grub LVM-ről nem tud boot-olni. Aztán most meg úgy látom, hogy tud.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ez a gondolkodásmód részben az ősi vindózos alapelv (diszk==C:), az ismeretek hiánya - és ennek okaként a tervezés hiányának szüleménye.

Körültekintőbb megvalósítás esetén még néhány szempontot figyelembe kell venni!
A diszk általában 2..12 (vagy tán több) zónára oszlik, amit a gyártó meg is ad. Az egyes zónák sebessége eltérő, a külső zónák gyorsabbak és megbízhatóbbak. Komolyabb rendszereknél , ha nem az utolsó bit kifacsarása a cél, a belső zónákat nem szokták kiosztani. Persze a kommersz diszkeknél esetleg hozzá sem jutsz ilyen információkhoz.
A partíció és filesystem kialakításának további céljai és előnyei lehetnek.
- Az egyes "diszk darabok" megbízhatóságát, sebességét, rendelkezésreállását különböző módon hangolva optimalizálható a rendszer.
- Lényeges szempont a felhasználás célja. Ha van egy /data szegmensed, akkor ahhoz tudsz hozzáadni további diszkeket, és nem a rootfs-t kell bővíteni még 5 diszkkel. Ha a /var külön van, elkerülheted az "elszaladt" logok miatt a rootfs megtelését - így az oprendszer megállását.

Ezeket az apróságokat a végtelenségig lehetne sorolni, de egy rendszer kialakításákor némi ész alkalmazása még 1db diszk esetén sem hátrányos! ;)

Érdekes a téma!

Tehát diszk==C:==partíció?

Soha nem akartam partíció nélküli tárhelyre adatot tenni (ja de, mikor kezdő linux-os voltam...).

++1 a témának, nagyon érdekel, a végkifejlet!

“- És ha… fizetést ajánlanék, hogy dolgozzon?
– Engem nem lehet megvesztegetni.”
Rejtő Jenő

Nem a partíció a lehetséges egyetlen konténer. Ott az LVM, amelyet nem raksz feltétlen partícióba, de attól még a VG-be különböző PV-ket tehetsz, így aztán pontosan tudhatod, hogy a rootfs melyik disk-en van, s az adat melyikeken.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Gratulálok! Ez egy frappáns meglátás!
Bár nem tudni mivel hozható összefüggésbe. ;)

Amit írsz, én így fogalmaznám: A linux lvm az egyes entitások meghatározásakor két, míg az AIX lvm csak egy körüljárást biztosít. Ennek ellenére az első szart se ér. ;)
Pontosan ezért írtam szegmenst, hogy ne kötődjünk konténer fajtához. Egyszerű patícióhoz egyébként sem könnyű hozzáadni 5 diszket. :-D (Tán más konténer is lehetséges??)

A topic meg arról szól, hogy szegmetáljunk, vagy sem. Méghozzá egy olyan környezetben, ahol a raid, az lvm és a diszk monitorozás is egy-egy szoftver, amelyeket évtizedek alatt sem sikerült rendszerré gányolni. És ez nagyon szomorú.

Nem, a topicnyitó partícióról szólt, nem általában bármiféle filerendszert tartalmazó konténerről.

A diszk monitorozást - bármit is jelentsen ez - szerintem nem is kell egy software-ben megvalósítani. Lehet ugyan mindent egységesíteni, de az elvesz a választás szabadságából, definiálja a használandó rétegeket. Most tehetsz filerendszert diszkre, diszken ülő partícióba, lvm-ben lv-re, ahol a vg alatt lehet fizikai lemez, de akár partíció is, használhatsz btrfs-t, amelynek van saját megoldása.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A diszk monitorozást - bármit is jelentsen ez - szerintem nem is kell egy software-ben megvalósítani.

Igaz, a diszk-manók sokkal hatékonyabbak lennének. ;)
A diszk fizikai eszköz. Hiába húzol rá bárminemű szoftver konténert, ezen a tényen nem tudsz változtatni.

Kb. egy hónappal korábbi (megtörtént eseményeken alapuló :)) eset, amikor a hős linux kivágta a raid1-ből a 2TB kapacitású diszket. Vélhetően 1..3 szektor hiba miatt, amit az ujjacskáidon kiszámolva elég alacsony százaléknak találhatsz. Kíváncsi voltam a logokra - mert abban "oda van írva" a hibás LBA.
Az üzemeltető szerint: "Nem teljesen értelek titeket. Rossz a diszk. Nem lehet olvasni legalább egy szektort. Nem lehet tudni, hogy több szektor hibás-e, hiszen a self test is elszáll 60%-on."
Ez, ugye mély hozzáértésről tanúskodik. ;) Az ATA diszkeknek meg "az a foglalkozása", hogy a hibás szektorokat kihelyettesítse. A selftest meg kilép az első hibás LBA-nál, tehát nincs ebben semmi csoda!
Elárulom, még ezeket a diszkeket is lehet kezelni a selftesten kívül mással is. Pl. ATA parancskészlettel. Van is rá linux tool, ami a kernel megkerülésével kezelgeti a diszket. Ennyit a választás szabadságáról. :-D
Ugyanez a hiba AIX alatt naplózva valahogy így néz ki (pongyolán):
- Hibás LBA-t találtam.
- Parancsot adtam a firmware kihelyettesítésre.
- A firmware kihelyettesítés nem sikerült. (Ti. az IBM által nem támogatott, olcsó diszket használtunk.)
- Kihelyettesítettem szoftverből.
- Sikerült.
...hasítunk tovább.
Ugyanitt a tükrözés teszteléséhez mondjuk le kell húzni a tápot az egyik diszkről. Ekkor az írt/olvasott partíciók másolata hibás jelölést kap. (AIX partition==linux phisical extent!!)
A táp visszadugásakor a hibás partíciókat újra lehet szinkronizálni.

Lehet ugyan mindent egységesíteni....
No, akkor lássunk 1db - akár nem egységes, akár operációs rendszerbe nem épített - megoldást a diszk hibák kezelésére! Ha nincs linuxos, vindózos is jó. :-D
Ha nem létezne ilyen, akkor van indoka az 1 szektor hibával rendelkező 2TB-os diszk kukába rakásának vagy garanciális cseréjének. Ezzel szemben választhatsz bármilyen konténer formátumot, néha a fizikai diszk lesz a legkisebb kezelhető egység. Minden bizonnyal a btrfs egy lehetséges csodafegyver, bár kérdés, hogy mennyire működik együtt az oprendszerrel. Mert ha nem nagyon, akkor az is csak egy szoftver, ammi alatt maradhat egy kezeletlen fizikai réteg.

Hogy pontosan értsd miről beszélek, az idézett AIX-es hiba több mint 20 éves.

ahol a raid, az lvm ... is egy-egy szoftver

LVM supports RAID0/1/4/5/6/10.

An LVM RAID volume has the following characteristics:
- RAID logical volumes created and managed by means of LVM leverage the MD kernel drivers.
- RAID1 images can be temporarily split from the array and merged back into the array later.
- LVM RAID volumes support snapshots.

A topic meg arról szól, hogy szegmetáljunk, vagy sem

Ez nem egyertelmu, legalabbis szamomra nem volt az. En ugy ertettem, a topcinyito szeretne megtudni, okozhat-e barmilyen problemat, ha a rendszerben hasznalt diszkeken nem hoz letre particios tablat es particiokat. A szegmentalas mar teljesen mas.

--
L

Így van. Egyben odaadom BtrFS-nek, vagy mdraid-nek és utána formázom ext4-re. Konkrétan több helyen használok így diszkeket.

Mivel régi hagyománya van a partíciók létrehozásának Linux-on is, ezért kíváncsi vagyok hogy kernel vagy épp userspace szintjén épült-e erre a logikára olyan kialakítás, mely borul hogy ha nincs partíció.

Ha valaha is tervezed, hogy a vinyot mas gepben is hasznalod, akkor nem art.

Amugy mennyi helyet is visz el? 1000 sector, az .5-4 mega. Tehat igazabol hatranya sincs, ellenben kesobb jol johet, hogy non-destruktiv modon tudsz particiot atmeretezni es csinalni egy masikat, ha kell.

Ja, es bootolashoz is kell egy. En pl. egy raid5 tomb minden vinyojara raktam 1G-s raid1-t (/boot), es grub-install-t is tettem mindre. Igy akarmelyik vinyo kiesik, tud bootolni gond nelkul a gep.

Egyetértek. Elfér, nem árt particionálni. Sok helyet nem foglal. Jobb szegmentálni, egy partíció az OS-nek, egy az adatoknak. Esetleg ha több OS is van fent, akkor sem lehet megúszni. Plusz pl. bootolni nem lehet particionálatlan lemezről tudomásom szerint. Vagy ha igen, nem értem hogyan. Hová megy a GRUB vagy más bootmanager? EFI stub boot hogy indítja róla a kernelt?

Igaz nem volt téma, de ha már particionáljuk a lemezt, érdemes ma már GPT-s partíciós táblára rámenni. Ha meg MBR-nél kell maradni (olyan OS kell, amely csak MBR-t, támogat, vagy nem UEFI-s a gép), akkor meg lehetőleg érdemes kerülni az extended-logical partíciózást.

[i]„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum[/i[

(Szerintem bootolni tudna egy gép partícionálatlan lemezről is: pont ugyanúgy, ahogy betölti az MBR elején levő loader-t, ami ez *után* majd feldolgozza a partíciós táblát, ugyanúgy a loader töltheti natívan az OS kernelét is. Speciel a FreeBSD telepítő tud(ott?) egy ott Dangerous Dedicated-nek nevezett diszkhasználatot, és az pont az volt, hogy nem partícionálta (már MBR-szerűen, mert ugye a BSD saját slice-jait azért elkészítette akkor is).

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?