Dotaz: Linux deleni disku

[Lubos]

Dobry den,
resim instalaci Linuxu, uz mam nejake ty znalosti i osobni prakticke zkusenosti,zbytek znalosti jsem si precetl v clancich a diskuzich nebo se doptal.
Je mi skoro vse jasne, chci delit plotnovy 1TB disk pomoci MBR (MSDOS) tabulky na oddily /, swap a /home v tomto poradi, mozna jeste nejake dalsi oddily, ale to asi ne, asi mi staci tady ty.

Fakt jsem pevne rozhodnut, ze se nechci v zadnem pripade poustet do zadnych hloupych problemovych casto nebezpecnych harakiri jako: GPT, UEFI, LVM, LUKS, "vse na 1 oddil", "nechat rozdelit automaticky", "disk bez oddilu", ... a podobne, moc dobre vim proc, tak mi toto prosim ani neradte, to uz se ruzne po celem netu resilo v milionech vlaken ve kterych jsem nekde byl i nekde nebyl aktivne zucastnen, takze toto fakt ne.

Mam tedy jen 2 drobne nejasnosti, 2 drobne otazky k tomu, co jsem tak vycetl ruzne v odbornych clancich po netu i co tak ruzne po netu doporucovali nekteri diskutujici. Potrebuji se zeptat, nekteri totiz doporucovali:

1.) Nechat na zacatku disku prvni 4MB neobsazene-volne a delat oddily az za temito 4MB, ze to ma zpusobit zrychleni vyhledavani dat a prenosu dat z/na HDD vlivem toho, ze vsechna data jsou pak na HDD zarovnana optimalne tak jak je to pro disk prirozene a nativni, cimz je disk pri vyhledavani dat i prenosu dat rychlejsi - HDD ma pak data pekne zarovnana tak jak je pro nej prirozene a nemusi nic prepocitavat, cimz je rychlejsi. Nekdy a nekde jsou k tomu pripojeny i prakticke testy a jejich vysledky dokazujici zrychleni diskovych operaci oproti stejne situaci (stejny system, PC, HDD, referencni data) na HDD bez ponechani prvnich 4MB volnych.
Potrebuji se zeptat, je tomu skutecne tak? Dojde skutecne ke zrychleni HDD a HDD operaci, nebo jde jen o klam, mytus a placebo? Nechat prvni 4MB volne nebo ne?

2.) Udelat samostatny oddil pro /var kvuli tomu, ze se nekdy nektery program muze zblaznit a pak muze zacit generovat obrovske mnozstvi logu, ktere se ukladaji do var a muze zaplnit a zahltit cely / oddil, ale pri samostatnem /var oddilu se zaplni pouze /var oddil, nikoliv cely / , coz je udajne vyhodne pro stabilitu systemu.
Potrebuji se zeptat, vyplati se to opravdu a opravdu delat samostatny /var oddil nebo ne a dat var normalne do / oddilu?

Dekuji moc za odpovedi.

Odpovědi

[Pavel 'TIGER' Růžička]

Pokud budeš stroj používat jako obyčejný desktop, pak můžeš s klidem oba dva body v klidu ignorovat. Kdyby první bod byl pravdou, tak by automatické rozdělení disku nechávalo onen prostor na začátku volný. U žádného OS jsem to neviděl. Nevím, co by se muselo stát, aby se dvojka stala pravdou (něco jiného je to u serveru), avšak pro podobné případy se nechává rezerva na konci disku. I když u desktopu to nepovažuji za nutné.

[k3dAR]

[...]Nevím, co by se muselo stát, aby se dvojka stala pravdou (něco jiného je to u serveru)[...]

napr. tohle

[Pavel 'TIGER' Růžička]

Ale to snad není důvod k oddělenému /var.

[Petr Fiedler]

A tohle?

[Pavel 'TIGER' Růžička]

Promiň, ale kvůli tomu, že se občas něco zblázní oddělovat /var je pitomost. /var je dobré monitorovat a když se něco zblázní, tak systémem být na to upozorněn a pak řešit jádro problému. Na jedné straně se tu řeší, jestli na začátku disku nechat 4MB volného prostoru kvůli lepšímu výkonu a pak si ho necháte žrát zápisy do /var.

[Petr Fiedler]

Na jedné straně se tu řeší, jestli na začátku disku nechat 4MB volného prostoru kvůli lepšímu výkonu a pak si ho necháte žrát zápisy do /var.

A kdyby /var nebyl oddělen a byl součástí /, tak by se do něj nezapisovalo?

[Pavel 'TIGER' Růžička]

Samostatný oddíl pro /var je neefektivní plýtvání prostorem. Může se jednou stát, že ten volný prostor Ti bude chybět jinde. Pokud se do něj zapisuje normálně, pak není nutné ho mít oddělen. Pokud dojde na vámi uváděné příklady, pak je naprosto jedno, jestli je oddělen, nebo ne, protože vznikla situace, která se musí řešit. Předcházení těmto situacím je monitoring systému, který včas upozorní na vzniklou situaci.

[Lubos]

Dobry den, potreboval bych upresnit, kdyz je /var samost. oddil a neco se zblazni a zaplni logy cely /var tak to jen vyhodi chybove hlaseni neco jako: "V oddilu /var je malo mista. [Prozkoumat] [Ignorovat]" a system funguje dal, jen neni mozno nic ukladat do /var zadna data ani zadne jine logy (z cehoz plynou pripadne dalsi chyby a chybove situace a chovani programu snazicich se do /var zapisovat), nez je problem vyresen, ale system jinak jede dal, coz je mozne vyuzit k oprave systemu bez nutnosti LiveCD, ne? Nebo se pletu?

Pokud se stane stejna situace - neco se zblazni a zacne generovat strasne moc logu tak ze zaplni cely oddil, ale var neninsamostatny oddil ale je v oddilu / , tak se stane co, tak system spadne a je treba ho nabootovat z LiveCD, opravit problem a pak zase funguje? Nebo se pletu?

Rikas, ze v obou pripadech - samostatny oddil /var i nesamostatny var v oddilu / - je vhodne problemu preplneni oddilu predchazet monitoringem - je hezke se neco teoretickeho dozvedet, ale co treba neco praktickeho - jak a cim monitorovat, pripadne jestli je mozne problem zablokovat i jeste nez k nemu dojde - nez dojde k uplnemu zaplneni oddilu jestli to muze napr. zobrazit nejake upozorneni a zakazat dalsi logovani? Nejake prakticke reseni, tipy a navrhy by byly lepsi nez jen teoreticky rict: "Predchazej tomu monitoringem.".

Dekuji.

[MP]

Ve /var nejsou jen logy, takze pokud dojde k zaplneni, tak to nejakym zpusobem system/aplikace odnese tak jako tak.

[Pavel 'TIGER' Růžička]

Ano, když se zaplní samostatný oddíl, tak systém bude nějakým způsobem možné provozovat i bez nějakého živého média.

Ano v druhém případě se zaplní i / a bude nutné nápravu řešit jinou cestou.

Oběma situacím lze předcházet monitorováním. Základem monitoringu je sledování obsazenosti prostoru, a to jak celkového /, tak případně jednotlivých oddílů. Na to jsou snad v každém desktopu nějaké utility, někdy nainstalované v základu, jindy třeba doinstalovat. To nebudu rozepisovat. /var se dá monitorovat třeba pomocí aplikace logcheck Pochopitelně způsobů monitoringu je velké množství a je to spíše na samostatný dotaz, proto jsem to zmínil jen okrajově. Také by stálo za to zmínit, že když se nějaká aplikace zblázní, tak může zaplnit i /tmp, možná by měl mít vlastní oddíl, nemyslíte?

[Petr Fiedler]

Nezlob se na mě Pavle, ale něco monitorovat mi přijde jako opruz. I kdybych neoddělil /var, tak bych rozhodně nic nemonitoroval a kdyby se něco zbláznilo, tak bych to pak raději opravil z Live a hotovo. No, a to už je podle mě lepší /var oddělit a kdyby se něco zbláznilo, tak systém půjde spustit a v klidu to půjde opravit. Plýtvání místem to podle mě není. Josef tu psal, že měl aktuálně ve /var 12 GB, takže kdybys měl oddělen /var o velikosti 20 GB, tak bys měl nevyužito 8 GB. Soudím ale, že když je na tom někdo tak špatně, že zoufale otřebuje těch 8 GB, tak už DÁÁÁVNO měl koupit další disk. Třeba 3 TB a místa by bylo dost. A kdyby pak zase potřeboval těch 8 GB, tak už měl zase DÁÁÁVNO kopit další disk. A tak pořád dokola. Ale obtěžovat se nějakým monitoringem, to fakt prostě NE! Jak tu psal Andrej: "Počítač má sloužit lidem a ne lidé počítačům." Tak to vidím já a tak to hodlám dělat.

/tmp mám navedeno na RAM a přidělil jsem mu 8 GB. Pokud by se něco zbláznilo, tak je to zase cajk, nemyslíš?

[Josef Kufner]

Všechna rozumná desktopová prostředí ti ukážou notifikaci, že ti došlo či dochází místo na disku. Nemusíš se o nic starat, prostě vyskočí bublina, když je to aktuální.

V noteboocích je běžně 256GB SSD, neboť ty větší disky nejsou zrovna levné (i když to teď už bude spíš 512 GB) a není možnost přidat další. Prostě to není kam dát. Při takové velikosti může být 8GB velmi znát.

[Pavel 'TIGER' Růžička]

Pokud počítač má sloužit uživateli a ne uživatel počítači, pak nemá cenu se o tom rozdělení bavit, nechme to na tom počítači, ať to rozdělí sám a slouží. Pak je naprosto jasné, že /var nebude oddělen a /tmp přesměrován. Mimochodem, je pěkné /tmp přesměrovávat do ramky, ale kolik lidí si tak nabušené počítače kupuje? Lidé koukají převážně na cenu a ne na parametry. Pak logo výrobce přelepí nakousnutím jablkem a jsou plně spokojeni. Jak si jinak vysvětlit tolik levných (podle parametrů tedy předražených) notebooků je na trhu? Buď diskutujme odborně k věci, nebo to považujme za opruz a hoďme na to bobek. Mne monitoring nikterak neopruzuje, řeším ho vlastní cestou, stejně jako desktop.

[k3dAR]

to ti nestacilo predchozi vlakno?

1) tam mas odpoved(i)
+ zopakuju, HDD ma velikost bloku 512B nebo 4096B z jakeho duvodu myslis ze 4194304B je lepe zarovnane na blok nez beznych 1048576B? oboje je nasobek 512B i 4096B...

2) vyplati pokud chces predejit zaplneni rootfs kdyz nejaky program zacne zbesile logovat, coz je mnohem pravdepodobnejsi nez ze by zacal zbesila zapisovat nejam mimo /var...

[Andrej]

…na oddily /, swap a /home v tomto poradi, mozna jeste nejake dalsi oddily, ale to asi ne, asi mi staci tady ty.

Klasická chyba, pořád a dokola. Tohle už tu bylo stokrát. Prosím, pěkně prosím, mohli by tazatelé před položením dotazu zalistovat v historii poradny?

K tématu snad jen doplním, že máme rok 2019. A v roce 2019 …

• … je swap soubor, ne oddíl. Dá se měnit a rušit a znovu vytvářet dynamicky dle potřeby.
• … se disky nedělí, protože dělení je naprosto zbytečné a vždy je pro alespoň jedno budoucí použití naprosto špatné [dlouholetá osobní zkušenost].
• … slouží počítače lidem, ne lidé počítačům; proto lidé nemusí přemýšlet, který „oddíl“ se zaplní. Členění souborového systému — je li vůbec potřeba — se zajistí pomocí subvolume a k nim příslušných kvót. Pak se dá členění kdykoliv změnit bez přesunů dat.
• … se zpravidla volí takové souborové systémy, které umožňují například pozdější přidání dalšího 1 TB disku a vytvoření RAID1 — samozřejmě za běhu, na namountovaném disku a bez explicitního kopírování souborů.
• … se velmi důrazně nedoporučuje používat MBR; EFI GPT je mnohem lepší nápad a dá se tam (je-li to naprosto nezbytné) přidat i MBR na podporu ultra-starých zařízení. V roce 2009 bych řekl, že se záložní MBR hodí; v roce 2019 říkám, že ne.

[regine]

Doma i v práci se mi klasické rozdělení disku na dvě partitions (systém a programy + uživatelská data) osvědčilo.

Důvodem je, že zálohuji 1. partition (mezi 50 až 100GB) jako celek pomocí Clonezilla během 10 až 20 minut a v případě průseru obnovím během 5 minut.

Uživatelská data na druhé partition (zbytek disku) zálohuji podle potřebných metod (přírůstkově, rozdílově, synchronně ,...).

[Petr Fiedler]

Já mám na pc zvlášť EFI, /, /var a /home a zvlášť partyšnu na data. První 4 partyšny zálohuji Clonezillou (pár desítek GiB) a data jsou oddělená na konci disku na zvláštní partyšně, takže v bezpeči. Když pak obnovuji, tak jen systémové partyšny a data zůstávají nedotčená. Samozřejmě je mám zálohovaná copy/paste na další disk a ktomu ještě synchronizovaná na síťový disk a nb. Teď to nejde, ale do budoucna bude rozdělen stejně i nb a IMO je to takhle super. A kvůli SSD mám /tmp navedeno na RAM, takže úplná pohoda.

[Gilhad]

Pokud vím, tak v roce 2019 stále platí (a ještě nějakou tu dobu platit bude), že

• swap je prostor, kam jádro může odkládat pamět, pokud ji potřebuje dočasně kus uvolnit.

• Co jsem naposled kontroloval (začátkem tohoto týdne), tak swap i na novém počítači byl stále oddíl ačkoli by šel vytvořit i jako soubor, (stejně jako to šlo před 10 lety i dříve).
• Stejně tak se dá připojit více swapů, s definovanou prioritou, pak se doporučuje dát jako prioritní oddíl, soubory až s nižší prioritou, protože přímý zápis/čtení na (z principu nefragmentovaný) oddíl je stále ryhlejší, než když se zápis/čtení uskutečňuje přez několik dalších nepřímých vrstev do něčeho, co pravděpodobně fragmentované nakonec bude. (Dobře toto se týká HDD, SSD s fragmentací a přesunem hlaviček nemají takové problémy)
• Co se možnosti přidávání disků (za cenu zvýšené režie) týče, je také vhodné zvážit, zda vůbec dotyčný počítač takovou věc umožňuje (mnohé NB nikoli, druhý disk se tam fyzicky nevejde a používat to s USB externím diskem (přičemž USB portů také stále ubývá) je nejen výkonostní problém, ale zejména nebetyčné hazardování s daty - obzvláště pokud by na tom USB disku skončil soubor zrovna vydatně používaný jako swap )
• GPT má tu nesmírnou výhodu, že snadno umožňuje disky větší než 2TB s tabulkou pro 128 primárních oddílů alokovanou v základu - což je naprosto klíčová výhoda při použití disku o velikosti 1TB, kde uživatel váhá mezi 3 a 4 oddíly, tedy něčím, co MBR v pohodě zvládá. Na druhou stranu tím uživateli odpadá nutnost volby mezi grub1 (který jde konfogurovat na pár řádků v libovolném texťáku) a grub2 (kde se konfugurační soubor kompiluje řadou skriptů) - a to se vyplatí.

Co se /var týče - při alokování jako samostatný oddíl je problém odhadnout správně velikost - buď bude příliš velký a většina bude ležet ladem, nebo s postupem času a instalací stále více logujících programů bude malý a zahltí se běžnými logy. Nemluvě o tom, že pokud se náhodně staneš terčem nějakého bota/botnetu, co bude příliš aktivní, tak ti snadno zaseká auth.log svými nesčetnými neúspěšnými pokusy se přihlásit na neexistující účty (co náhodně posbíral po windowsích strojích) s totálně pitomými hesly (sebranými tamtéž)

jo, tohle jsem řešil na mnoha starších strojích s celkem plnými disky, kde to /var bylo v / a stějně ti šmejdi zaplnili všechen prostor - tam nepomůže než nějaké lepší řešení, třeba fail2ban, či cokoli jiného. (Ono docela pomohlo i v iptables zabanovat většinu Asie a USA (ty velké bloky), ačkoli to jako řešení není ani ideální, ani vždy možné, tak to aspoň šlo rychle)

[Gilhad]

viz též: https://cs.wikipedia.org/wiki/Virtu%C3%A1ln%C3%AD_pam%C4%9B%C5%A5

Odkládání lze provádět:

• do souboru proměnné délky (nejpomalejší varianta),
• do souboru pevné délky (o něco rychlejší, neboť nedochází k fragmentaci v souborovém systému, ale dochází k plýtvání místem; na druhé straně může dojít k nedostatku virtuální paměti),
• přímo do vyhrazeného oddílu na pevném disku (nejvýkonnější varianta, diskový oddíl neobsahuje souborový systém, stránkovací registry obsahují přímé adresy na disku),
• kombinovaně (vyhrazený oddíl na pevném disku lze v případě potřeby doplnit swapovacím souborem pevné, resp. proměnné délky).

[Jendа]

Na druhou stranu tím uživateli odpadá nutnost volby mezi grub1 (který jde konfogurovat na pár řádků v libovolném texťáku) a grub2 (kde se konfugurační soubor kompiluje řadou skriptů)

WTF, GRUB1 i GRUB2 se konfigurují úplně stejně, rozdíl je jenom drobný v syntaxi.

Příklad: GRUB1:

timeout=5

title CentOS (2.6.18-419.el5)
	root (hd0,0)
	kernel /vmlinuz-2.6.18-419.el5 ro root=/dev/vda clocksource=acpi_pm
	initrd /initrd-2.6.18-419.el5.img

GRUB2:

set timeout=5

menuentry 'Debian GNU/Linux' {
	set root='hd0,msdos1'
	linux	/boot/vmlinuz-4.9.0-2-amd64 root=UUID=0a6dd446-b329-4a2c-a162-0d9bae873000 ro  
	initrd	/boot/initrd.img-4.9.0-2-amd64
}

[Gilhad]

Tak to jsem holt měl smůlu, kdykoli jsem něco instaloval, tak pro grub1 tam vyběhlo cosi dle první ukázky, pro grub2 tam vyběhnul hrůzinec zvíci mnoha kilobytů, na začátku velké tlusté varování DO NOT EDIT THIS FILE, a jednotlivé požky měly desítky řádek. A žádný návod, jak to dělat lépe a jednodušeji. Alespoň jsem ho tehdy nenašel snadno a rychle. Ale doufám, že jich na internetu bude přibývat a půjdou na vyšší místa ve vyhledávání.

Nicméně zatím mým potřebám grub1 stačil, takže jsem nebyl donucen to hledat příliš intenzivně

Ale věřím, že máš pravdu a jde to i jednoduše a logicky, takže tento svůj bod považuji za vyvrácený.

Tím spíš, že jsem v mezičase narazil na článek, jak někdo jedničku vnutil do čistě GPT (pravda s použitím binárního editoru a podobných triků, nicméně prý uspěl takže nutnost/možnost volby nadále zůstává, ač silně nakloněna k jedné straně).

[Jendа]

Tak to jsem holt měl smůlu, kdykoli jsem něco instaloval, tak pro grub1 tam vyběhlo cosi dle první ukázky, pro grub2 tam vyběhnul hrůzinec zvíci mnoha kilobytů, na začátku velké tlusté varování DO NOT EDIT THIS FILE, a jednotlivé požky měly desítky řádek.

To záleží na distribuci, nicméně všude by mělo být možno automatické generování vypnout (u GRUBu 1 i 2) a psát si grub.cfg (menu.lst) ručně. Například na Debianu pak není automatická aktualizace vůbec potřeba, protože symlinky /vmlinuz a /initrd.img vždy ukazují na aktuální kernel -- ani po upgrade jádra, které pak má jiné číslo, tak není potřeba nic přepisovat a stačí stále bootovat zmíněné soubory. (abych pravdu řekl nevím jak se tyhle symlinky používají když máš /boot na zvláštní partition, zatím jsem je vždy potřeboval použít jenom na strojích kde jsem /boot zvlášť neměl)

A jinak osobně jsem tedy ještě nikdy nenarazil na potřebu psát si grub.cfg ručně, zatím jsem všechno co bylo potřeba nastavil v /etc/default/grub.

[Gilhad]

Nojo, když já začínal s Linuxem, tak ještě žádné /etc/defaul/grub nebylo (a ještě tu mám instalačky RedHat 6.1CZ i s příručkou koupené koncem minulého milénia, (což byl první linux, který jsem si osobně koupil, předím jsem používal co dotáhnul zaměstnavatel ...). Takže jsem nejdřív lavíroval mezi několika distribucemi a LILO vs. GRUB mi rychle vyznělo jako jasná volba, protože u grubu se to po překonfigurování nemuselo přeinstalovat (LILO muselo, protože se měnilo něco přímo v tom zavaděči mimo filesystém).

A veškeré nastavení bylo v /boot/grub/grub.conf a bylo lepší do konfigurace sahat ručně, než tehdy dostupnými nástroji, protože jinak spousta věcí ani udělat nešla. No a protože grub stále funguju i na nových počítačích a terabytových discích, tak jsem neměl důvod přecházet na grub2, který nedával nic potřebného navíc a dostupné popisy všechny braly jako hotovou věc, že se musí spouštět konfigurační skripty pokaždé, když se něco změní - čili to znělo jako zpátky k problémům s LILO.

Jo, automatické generování se určitě vypnout dá, ale ten výsledný konfigurák byl natolik složitý, že jsem neviděl žádnou přidanou hodnotu v tom učit se jeho syntaxi a rozebírat (spíš metodou metodou pokus omyl, než že by někde byl jednoduchý návod), co vlastně dělá, co z toho je vůbec potřeba a co všechno se dá bez problémů vypustit (jak teď vidím, tak prakticky všechno, ale tehdy jsem to nikde nenašel).

Takže složitý konfigurák, nebo složité skripty, žádná přidaná hodnota pro mě, zkrátka dodnes používám grub 0.97 a všechno funguje snadno a rychle. A dokud to tak bude, tak ho klidně budu používat i nadále a uvidím, jestli se to všechno nepřežene a co bude k dispozici v době, kdy grub stačit přestane. (Ono se toho už kolem mě přehnalo tolik, co bylo nejdřív prostě nové, pak to musel mít každý, pak to byl opruz a pak to ke všeobecné úlevě totálně chcíplo. Takže když se objeví cosi nového, tk to třeba zkusím, ale když mě to neosloví, tak klidně počkám až to chcípne a přijde něco lepšího - pokud je vůbec danou věc potřeba vylepšovat.)

Jo a jasně, že jsou scénáře, kde asi ten grub2 dobrý význam má, jinak by se s tím nejspíš nikdo nepsal, jen to asi nejsou scénáře, které se týkají věcí v mém okolí. (Tomu grubu2 to celkem i věřím, na rozdíl od třeba systemd a jiných.)

[k3dAR]

GRUB2 umoznuje napr.:
- start z LVM
- start z MDADM
- start z LUKS
- vcetne kombinaci, treba start z sifrovaneho LV /boot nad LUKS
- start z ISO (idealni na USB_Flash pro vytvoreni menu pro ruzne ulozene ISO)
- definovat zarizeni dle UUID
- nezobrazovat menu pri startu
- zobrazit menu (nastavene jako schovane) kdyz predchozi boot nebyl uspesny
- automaticke pridavani dalsich OS(jak GNU/Linux, tak Windows) do menu (diky os-prober)
- rucni definovani "custom" menu polozek ktere se maji pridavat pri generovani

pokud nekdo nechce automaticky generovany grub.cfg, muze jak uz Jenda znazornil pouzit podobnou syntax pri rucnim vytvareni...

napr. start z ISO Debianu:

menuentry "debian-live-9.3.0-amd64-xfce+nonfree.iso(live)" {
    set isofile="/boot/iso/debian-live-9.3.0-amd64-xfce+nonfree.iso"
    loopback loop $isofile
    linux (loop)/live/vmlinuz-4.9.0-4-amd64 live-media-timeout=3 fromiso=$device/$isofile boot=live config components quiet splash
    initrd (loop)/live/initrd.img-4.9.0-4-amd64 
}

[Gilhad]

Nepochybně to dokáže. Některé věci z toho seznamu dokáže i grub1 a část z stejně nepoužívám.

(čili ten seznam nezpochybňuji, akorát neobsahuje nic, co bych potřeboval a neměl a tedy není důvodem k přechodu. Stejně jako kdyby tam byla lokalizace do egyptštiny, čínštiny, kligonštiny a jazyka Zulu - někomu se to může hodit a být důvodem k přechodu, někdo to holt nevyužije)

[pavele]

U lilo se ti nemohlo stát, že když jsi smázl linux v dualboot win/linux, tak by ti win nenaběhl. U grubu ti grub nebo grub2 nenaběhne, protože kousek je v mbr a kousek na linuxovém oddílu, protože je natolik komplexní a veliký, že se kvůli němu doporučuje nechat první 4 MB na disku volné. Nevidím důvod zatracovat lilo.

A co se týče aktualizace, napsat lilo snad zvládne každý - a konfigurace je v jednom textovém souboru.

Grub si můžeš samozřejmě nainstalovat tak, aby byl uložený na samostatném oddíle. Takže pak můžeš mazat linuxové i windowsové oddíly podle libosti.

[Gilhad]

Ani u LILO se mi nemuze stat, ze by windows nabehly, kdyz na tom disku nejenze nejsou, ale nikdy nebyly, takze s tim problem fakt nemam :)

[Jendа]

To se mi moc nezdá, Lilo podle mě fungovalo tak, že se z MBR načetly bloky z nahardcodovaných adres (tvořící soubor v /boot) a spustily se. Tj. pokud jsi smazal linuxový oddíl a vytvořil/rozšířil tam jiný FS, tak to mohlo fungovat do té doby, dokud ten nový FS nepřepsal to místo kde byl payload lila. A to byl přesně ten důvod proč když se obraz lila na souborovém systému změnil a tedy FS změnil jeho fyzické umístění, bylo potřeba spustit lilo, které udělalo to, že seznam nových bloků napsalo do MBR.

[Jendа]

A veškeré nastavení bylo v /boot/grub/grub.conf

/boot/grub/menu.lst

a bylo lepší do konfigurace sahat ručně, než tehdy dostupnými nástroji

No minimálně na Debianu se seznam jader a detekce dalších OS generovaly i v GRUB1 a konfigurovalo se to pomocí komentářů přímo v tom menu.lst. Byla tam sekce ohraničená komentáři ### automatically generated, do not edit a v ní se to přepisovalo.

Jo, automatické generování se určitě vypnout dá, ale ten výsledný konfigurák byl natolik složitý, že jsem neviděl žádnou přidanou hodnotu v tom učit se jeho syntaxi a rozebírat

Jo, to co generuje ten defaultní generátor má spoustu věcí, protože to řeší (aktuální Debian, v tomto pořadí): automatický fallback na starší jádro když se to aktuální nepodaří nabootovat, grafický mód, unicode fonty, Xen… a to je vlastně všechno. A tohle tam prostě nedáš když si to píšeš ručně - a pak je to skoro stejné. Ale jak už jsem říkal: ještě se mi ani jednou nestalo, že bych musel grub.cfg upravovat ručně, ani jsem nenarazil na žádnou chybu v těch automatických skriptech co do generování toho konfiguráku. Zajímal by mě use-case kdy jsi tohle potřeboval.

[Gilhad]

Asi jo, asi je to symlinkovany az od nejake pozdejsi verze, na pricipu to nic nemeni.

Ten prvni use-case byl, ze grub-mkconfig proste nebyl a ze jsem potreboval pridavat jadrum zkusmo parametry a nektere kombinace mi chodily lip doma a jine v praci a tak jsem tam mel spoustu jader a spoustely se se spoustou prepinacu a abych v tom mel poradek, tak jsem to mel taky v ruznych adresarich, protoze jsem mel na jednom disku klidne 5 linuxu, kazdy s nekolika jadry a nektera byla sdilena a jina ne.

Takze jsem podle manualu nainstaloval grub, podle info grub nastavil konfig rucne a fungovalo to

A pri prechodu na dalsi pocitac/disk jsem to uz je zkopiroval, doupravil detaily a jelo to na prvni dobrou a nevidel jsem uz duvod, proc to delat nejak jinak sloziteji.

upřímě řečeno, v čem by mi nějaký skript mohl výrazně usnadnit práci, když moje současná konfigurace vypadá takto (zrovna mám na disku docela pořádek ...):

default 0
timeout 10
splashimage=(hd0,0)/boot/grub/splash.xpm.gz

title MainGentoo
root (hd0,0)
kernel /boot/main/bzImage raid=noautodetect net.ifnames=0 root=/dev/sda3 

title ALTsys
root (hd0,0)
kernel /boot/alt/bzImage raid=noautodetect net.ifnames=0 root=/dev/sda7 

title Gentoo old SYS
root (hd0,0)
kernel /boot/sys/bzImage rootwait raid=noautodetect net.ifnames=0 root=/dev/sda2

Pokud bych chtěl přidat další experimentální systém tak někde udělám partišnu/nebo použiju nějakou už nepotřebnou, v texťáku zkopíruju tři řádky (4 s tím prázdným), upravím jmeno adresáře (alt->pokus), číslo partišny (7->13) a název (ALTsys->pokus), uložím a mám nakonfigurováno

Pokud bych chtěl jen otestovat nastavení kernelu, tak odpadá změna partišny - a když se osvědčí, tak prostě smáznu pár řádků.

Fallback na hlavní systém je automatický (pokusný nedávám default), víc grafiky, než tam je takhle nepotřebuju a nemusím (kromě editoru) spouštet nic.

Naopak systémy, které jsem zkusil a asi se neosvědčily a nejspíš je zruším, tak ty tu prostě žádné řádky nemají (nebo je mají zakomentované) a nemusím řešit autodetekci.

Pokud se rozhodnu přehodit nějaký systém na jinou partišnu, tak jednoduše nabootuju z jiného, překopíruju ho a v /etc/fstab a konfiguráku přepíšu jedno krátké číslo, nic víc.

Boot je v prvni partition, záchranný kruh SYS ve druhé (a ten se nemění a používá pouze k nanažování ostatních), main ve třetí - to se už léta nemění - a pořadí pokusných systémů, swapů, datových úložišť a jiných exotik v extended už není zdale tak kritické, používají se většinou dočasně, nebo na speciální účely (konfigurace na míru konktrétní hře, kdy to chtělo jiný kernel a grafický driver, které oba byly zastaralé, ale ta hra na nich šla mnohem lépe, než na těch tehdy aktuálních a tak podobně), takže nezapomenout při přesunu přepsat ta dvě čísla je ten nejmenší krok při jejich nastavování.

Takže spíš nevidím use=case pro to dělat takhle jednoduché změny pomocí sady nějakých skriptů, které nějak vygenerují cosi, přičemž jim stejně prakticky musím nějak říct to, co jsem tady napsal rovnou. (a /main/ pro hlavní systém a /alt/ pro alternativní a /oolite/ pro dotyčnou hru mi přijde přehlednějsí, než čísla verzí kernelu, nebo uuid disku.

S label je potíž, když člověk zálohuje disky z ruzných počítačů, ale všechny mají label BOOT, ROOT, DATA a SWAP ...

S uuid zase když přenese starý disk 1:1 na disk novější.

Perzistentní jména rozhraní potěší, když má každý domácí počítač právé jedno síťové rozhraní, ale to se jmenuje pokaždé nějak jinak a to jméno si samozřejmě nepodrží, když ta karta je nahrazena novější ať už kvůli tomu, že odešla, nebo že nová je rychlejší.

Takhle je ethernet všude neperzistentně furt stejně pojmenovaný eth0 a výměna karty, motherboardu, boot v jiném počítači, furt je to všechno jedno a furt je to eth0.

(a ano, plakal jsem, když vyhynuli dinosauři, bylo mi jich líto)

[Petr Fiedler]

Zdarec,

ohledně odděleného /var: To jsem ti radil já na základě tohoto vlákna. Blaazen v něm zde uvedl, že když nastanou problémy s množením se logů, s odděleným /var se to snáze opraví. Jak tomu tedy já rozumím, opravit to jde, ať /var máš, nebo nemáš oddělen. Takže pokud máš málo místa na disku pro svoje data, tak to neodděluj. Pokud by to bylo v budoucnu nutné, opravíš případný problém z Live, nebo třeba z flešky, na kterou si pro tyto případy můžeš Linux nainstalovat. Pokud máš místa dost, tak to klidně odděl. Pravděpodobnost, že se to bude hodit velká není, ale pokud je dost místa na disku, tak proč ne?

Ohledně 4 volných MiB na začátku disku: Za mě ROZHODNĚ ano! Před nedávnem mi to zde poradil Josef Kufner a mě to prostě funguje. I když někteří tu tvrdí, že jde o placebo, já jsem to dnes důkladně otestoval a když ponechám na začátku disku první 4 MiB volné, zvedne se prostě výkon disku a také by to mělo být šetrnější k disku.
Test jsem prováděl tak, že jsem zformátoval externí disk tak, že jsem nechal první 4 MiB volné a na zbytek disku jsem udělal 1 partyšnu ext4, vypnul pc, odpojil disk, nastartoval pc, chvíli počkal až se vše načte a spustí, připojil disk a v terminálu jsem dal:

dd if=/dev/zero of=/media/user/ext_hdd/testovaci_soubor bs=4M count=1000 conv=fdatasync status=progress

Tady jsou výsledky:

~$ dd if=/dev/zero of=/media/user/ext_hdd/testovaci_soubor bs=4M count=1000 conv=fdatasync status=progress
4190109696 bajtů (4,2 GB, 3,9 GiB) zkopírováno, 17 s, 246 MB/s
1000+0 záznamů přečteno
1000+0 záznamů zapsáno
4194304000 bajtů (4,2 GB, 3,9 GiB) zkopírováno, 45,6535 s, 91,9 MB/s

~$ dd if=/dev/zero of=/media/user/ext_hdd/testovaci_soubor bs=4M count=1000 conv=fdatasync status=progress
4194304000 bajtů (4,2 GB, 3,9 GiB) zkopírováno, 17 s, 246 MB/s
1000+0 záznamů přečteno
1000+0 záznamů zapsáno
4194304000 bajtů (4,2 GB, 3,9 GiB) zkopírováno, 45,6555 s, 91,9 MB/s

~$ dd if=/dev/zero of=/media/user/ext_hdd/testovaci_soubor bs=4M count=1000 conv=fdatasync status=progress
4127195136 bajtů (4,1 GB, 3,8 GiB) zkopírováno, 16 s, 257 MB/s
1000+0 záznamů přečteno
1000+0 záznamů zapsáno
4194304000 bajtů (4,2 GB, 3,9 GiB) zkopírováno, 45,4578 s, 92,3 MB/s

Pak jsem to samé opakoval s tím, že jsem na začátku ponechal volný pouze 1 MiB. Dopadlo to takto:

~$ dd if=/dev/zero of=/media/user/ext_hdd/testovaci_soubor bs=4M count=1000 conv=fdatasync status=progress
4173332480 bajtů (4,2 GB, 3,9 GiB) zkopírováno, 24 s, 174 MB/s
1000+0 záznamů přečteno
1000+0 záznamů zapsáno
4194304000 bajtů (4,2 GB, 3,9 GiB) zkopírováno, 69,4999 s, 60,3 MB/s

~$ dd if=/dev/zero of=/media/user/ext_hdd/testovaci_soubor bs=4M count=1000 conv=fdatasync status=progress
4164943872 bajtů (4,2 GB, 3,9 GiB) zkopírováno, 34 s, 122 MB/s
1000+0 záznamů přečteno
1000+0 záznamů zapsáno
4194304000 bajtů (4,2 GB, 3,9 GiB) zkopírováno, 59,9956 s, 69,9 MB/s

~$ dd if=/dev/zero of=/media/user/ext_hdd/testovaci_soubor bs=4M count=1000 conv=fdatasync status=progress
4143972352 bajtů (4,1 GB, 3,9 GiB) zkopírováno, 30 s, 138 MB/s
1000+0 záznamů přečteno
1000+0 záznamů zapsáno
4194304000 bajtů (4,2 GB, 3,9 GiB) zkopírováno, 56,2005 s, 74,6 MB/s

Výsledky mluví jasně. Ponechat tedy první 4 MiB volné je u mého externího disku rozhodně lepší. A i u druhého pozoruji znatelně lepší výkon, ale test jsem neprováděl. Nechce se mi na něm vše mazat kvůli testu. Ale opravdu je viditelně rychlejší. A co se týče testu, nejde o náhodu. U obou variant jsem to opakoval 3x. Takže žádné placebo. Si to zkus.

@k3dAR&lertimir: Skutečně se nejedná o placebo. Ponechat první 4 MiB volné je prostě (alespoň u mých dvou 2,5" disků) lepší. Je to výkonnější a pravděpodobně i šetrnější. Kdo nevěří, ať to zkusí

[Petr Fiedler]

Ještě jsem zapomněl uvést, že po zkopírování souboru na ext_hdd jsem před vypnutím pc soubor vždy smazal, aby byly s ohledem na stopu podmínky vždy stejné.

[Pavel 'TIGER' Růžička]

... a vyčistil si před každým testem ramku?

[Petr Fiedler]

Ne, ale vzhledem k tomu, že jsem test prováděl vždy přibližně 1 minutu po naběhnutí systému, tak by podmínky měly být vždy identické, ne? Spouští se vždy to samé a RAM mám dost. Že by to bylo RAM se mi nechce věřit. Byla by to dost náhoda 3x ve prospěch 4 volných MiB a před tím (pár dní zpátky) mi to taky kopírovalo vždy rychleji se 4 volnými MiB. Klidně to ale ještě zkusím s uvolněnou RAM.

[theseuszn]

Naprostej souhlas a výsledky sou výsledky, takže díky, žes to ukázal! Pak už je to na podmínkách a situaci každého uživatele, co mu dovolují a co si z diskem (ky) udělá. To sou ty nesčetné variabilní možnosti v linuxech...

[k3dAR]

@k3dAR&lertimir: Skutečně se nejedná o placebo. Ponechat první 4 MiB volné je prostě (alespoň u mých dvou 2,5" disků) lepší. Je to výkonnější a pravděpodobně i šetrnější.

muzes mi rict z jakeho duvodu by to melo byt setrnejsi?? velikost bloku disku je 512B nebo 4096B, to kdyz ti tuhle vec prvne nekdo zdelil bylo PRO SSD ktere MUZE (ale NEmusi) MIT velikost BLOKU 4MiB, volne misto a/nebo zarovani oddilu POUZE ma byt NASOBKEM velikosti bloku, u HDD tedy nasobkem 512B a/nebo 4096B, u SSD je to diskutabilni protoze tam fyzicka velikost bloku neni umlne snadno zjistitelna...

k testu rychlost, uz sem ti o placebo rekl minule vse, u testu nevim proc mas jine vysledky, mozna se projevuje nejakej bug, zkusim nekdy provest test a uvidim...

[Petr Fiedler]

muzes mi rict z jakeho duvodu by to melo byt setrnejsi??

Psal jsem pravděpodobně. Já tomu jako ty nerozumím, ale říkal jsem si, jak to, že to kopíruje rychleji se 4 volnými MiB na začátku? No a jediné co mě napadá je, že by byl blok větší než píšeš a pak by to (kdyby to tak bylo) "přeskakovalo" přes bloky. Proto jsem napsal, že je to pravděpodobně šetrnější.

O bug jít může a nedivil bych se. Přemýšlel jsem o tom a jak jsem minule popisoval ty časy, za které se to dokopírovalo, tak jsou vidět i v těchto výpisech. S tím rozdílem, že GUI se tváří, že kopírování skončilo, ale v terminálu je poznat, že se ještě na pozadí něco děje, protože není vidět ~$ a blikající kurzor. A pak se objeví druhá půlka výpisu a "skutečný" čas, ktetý byl třeba ke zkopírování. Tak uvidíme, každopádně je to zajímavé. Jestli to taky zkusíš, budu rád. Pokud jde o bug, zajímalo by mě, jestli je to problém jen Mintu?

[k3dAR]

Sektor (blok) je nejmenší adresovatelnou jednotkou disku s pevnou délkou (původně 512 byte na sektor, v současné době typicky 4 KB na sektor).
viz: https://cs.wikipedia.org/wiki/Pevný_disk#Organizace_dat

[Petr Fiedler]

Tak to je pro mě novinka. Do teď jsem žil v domění, že bloky se skládají ze sektorů.

[Petr Fiedler]

Jinak dík za odkaz.

[k3dAR]

jeste mozna na vstup misto /dev/zero zkus dat /dev/urandom ?

[Petr Fiedler]

Zkusím, ale až zítra.

[Petr Fiedler]

Můžeš mi sem prosím tě dát příkaz, kterým uvolním RAM, jak psal Pavel. Něco jsem vygooglil, ale nejsem si tím jistý. Koukal jsem do man free, ale tam nic na uvolnění nevidím.

[pavele]

Na tu ram:

echo 1 >/proc/sys/vm/drop_caches

(echo 2 >/proc/sys/vm/drop_caches)

Ovšem měl by snad stačit ten parametr v dd conv=fdatasync, který tu cache vyloučí, můžeš taky zkusit oflag=dsync.

[Petr Fiedler]

Díky.

Mohl bys mi prosím tě ještě vysvětlit, proč je tam "1", nebo "2" za tím "echo"? Já jsem právě našel na netu stejný příkaz, ale byla tam pro změnu "3". A nebyl jsem si jistý, jestli to číslo platí i pro můj případ/stroj a tak jsem se raději zeptal.

Ještě pro jistotu uvedu, že mám /tmp naveden na RAM. Mění to něco?

[Pavel 'TIGER' Růžička]

To znamená, že používáš RamDisk, běží ti procesy, proto nelze paměť vyčistit.

[Petr Fiedler]

Nechápu. Myslíš to ve vztahu k /tmp?

[Pavel 'TIGER' Růžička]

Jistě, pokud Ti běží uzamčené procesy, tak se většinou musí zabít. Nehledě na to, že máš připojenej tmpfs (či jinou variantu), která je usazená v paměti, musel bys to před vyčištěním nejdříve odpojit.

[Petr Fiedler]

Zakomentoval jsem tmpfs v /etc/fstab, ale stejně mi pak ten příkaz pro vyčištění nefungoval (po rebootu samozřejmě).

[Petr Fiedler]

Když v /etc/fstab nachám zakomentován tmpfs, stačí pak killall -u?

[Petr Fiedler]

Tak sudo killall -u mi pořád jen zobrazuje nápovědu.

[Petr Fiedler]

Tak jsem zkusil oba ty příkazy a i s 3 a vždy to napsalo: "operace zamítnuta" (jako root).

[Petr Fiedler]

V tom návodu, co jsem našel já je navíc mezera:

echo 1 >/proc/sys/vm/drop_caches
echo 1 > /proc/sys/vm/drop_caches

Jak je to správně?

[Pavel 'TIGER' Růžička]

echo 1 > /proc/sys/vm/drop_caches

[k3dAR]

nejsem si jistej co mysleno uvolnenim RAM, pravdepodobne vymazani cache, to podle me ale ma vliv jen pri cteni, kdy by se z cache cetlo pokud by ctenej soubor v ni jeste byl, pak by to bylo:

sysctl -q -w vm.drop_caches=3

pri zapisu myslim nema vliv, ale i tak sem radeji doporucil misto /dev/zero (coz jsou same nuly) pouzit /dev/urandom(coz generuje "nahodne" data)

[Petr Fiedler]

4 MiB:

~$ dd if=/dev/urandom of=/media/user/ext_hdd/testovaci_soubor bs=4M count=1000 conv=fdatasync status=progress
4194304000 bajtů (4,2 GB, 3,9 GiB) zkopírováno, 29 s, 144 MB/s
1000+0 záznamů přečteno
1000+0 záznamů zapsáno
4194304000 bajtů (4,2 GB, 3,9 GiB) zkopírováno, 56,636 s, 74,1 MB/s

~$ dd if=/dev/urandom of=/media/user/ext_hdd/testovaci_soubor bs=4M count=1000 conv=fdatasync status=progress
4143972352 bajtů (4,1 GB, 3,9 GiB) zkopírováno, 31 s, 134 MB/s
1000+0 záznamů přečteno
1000+0 záznamů zapsáno
4194304000 bajtů (4,2 GB, 3,9 GiB) zkopírováno, 57,9202 s, 72,4 MB/s

~$ dd if=/dev/urandom of=/media/user/ext_hdd/testovaci_soubor bs=4M count=1000 conv=fdatasync status=progress
4156555264 bajtů (4,2 GB, 3,9 GiB) zkopírováno, 29 s, 143 MB/s
1000+0 záznamů přečteno
1000+0 záznamů zapsáno
4194304000 bajtů (4,2 GB, 3,9 GiB) zkopírováno, 57,0691 s, 73,5 MB/s

Default 1 MiB:

~$ dd if=/dev/urandom of=/media/user/ext_hdd/testovaci_soubor bs=4M count=1000 conv=fdatasync status=progress
4181721088 bajtů (4,2 GB, 3,9 GiB) zkopírováno, 35 s, 119 MB/s
1000+0 záznamů přečteno
1000+0 záznamů zapsáno
4194304000 bajtů (4,2 GB, 3,9 GiB) zkopírováno, 79,2112 s, 53,0 MB/s

~$ dd if=/dev/urandom of=/media/user/ext_hdd/testovaci_soubor bs=4M count=1000 conv=fdatasync status=progress
4164943872 bajtů (4,2 GB, 3,9 GiB) zkopírováno, 44 s, 94,6 MB/s
1000+0 záznamů přečteno
1000+0 záznamů zapsáno
4194304000 bajtů (4,2 GB, 3,9 GiB) zkopírováno, 102,091 s, 41,1 MB/s

~$ dd if=/dev/urandom of=/media/user/ext_hdd/testovaci_soubor bs=4M count=1000 conv=fdatasync status=progress
4148166656 bajtů (4,1 GB, 3,9 GiB) zkopírováno, 34 s, 122 MB/s
1000+0 záznamů přečteno
1000+0 záznamů zapsáno
4194304000 bajtů (4,2 GB, 3,9 GiB) zkopírováno, 64,9896 s, 64,5 MB/s

Každopádně všechny časy jsou horší, než když byl vstup /dev/zero.

[Pavel 'TIGER' Růžička]

Každopádně všechny časy jsou horší, než když byl vstup /dev/zero.

Tak to je jasné.

[Petr Fiedler]

Tak tobě jo, ale mě to jasné nebylo. Čím je to způsobeno?

[Pavel 'TIGER' Růžička]

Musí navíc vygenerovat, co zapíše.

[Petr Fiedler]

@Lubos: Tak zkušenější k3dAR si stojí za tím, že ty volné 4 MiB nemají žádný význam a že jde asi o bug, což je možné.

[Petr Fiedler]

Zkusil jsem tedy vstup /dev/urandom, ale zase to bylo lepší se 4 volnýmy MiB na začátku disku. Samozřejmě může jít o bug. Teď je otázka, jestli to jen špatně ukazuje časy, nebo to skutečně z nějakého důvodu (bug) kopíruje pomaleji. A taky je otázka, jestli to není bug jen v mém distru. Já používám Linux Mint 19 s prostředím Cinnamon. Pokud by se tedy skutečně jednalo o bug, který by z nějakého důvodu zpomaloval při 1 volném MiB kopírování, tak si budeš muset na nečisto nainstalovat distro, které chceš a vyzkoušet si to, jak se to chová ve tvém distru. Každopádně i pokud by šlo o bug a se 4 volnými MiB by to kopírovalo rychleji, tak by bylo pak lepší je na začátku disku nechat volné. Pokud by to jen špatně ukazovalo, tak by to bylo jedno a pokud je to bug jen v mém distru a ty bys instloval jiné, v kterém by ten bug nebyl a časy by byly stejné, tak je to taky jedno a osobně bych nechal default 1 MiB. Nejlepší bude, když si to zkusíš a uvidíš, jak se ti to bude chovat a podle toho se zařídíš.

[Lubos]

Dekuji.

1.) Musim se ale zeptat, co jsi k testu pouzil za disk, magneticky plotnovy HDD nebo SSD? Pripadne jakeho vyrobce a typ?

2.) A pokud je standardni velikost sektoru u magnetickych HDD (mam magneticky disk, chcinse nadale bavit jen o magnetickych HDD) 512B nebo 4kB, tak proc je nutno delat na zacatku disku neobsazene misto 4MB nebo 1MB? Proc by u magnetickeho HDD nestacilo pro optimalni zarovnani oddilu volne misto na zacatku disku jen 4kB? Logicky mi to moc nedava smysl a moc nepasuje prpc nestaci volne misto 4kB a proc je nutno primo 1MB nebo 4MB, proc tedy?

3.) Delici nastroje instalacich programu linuxovych dister pri instalaci nechavajo standardne na zacatku disku mezi zacatkem disku a 1. oddilem kolik mista? A kolik mista nechava mezi zacatkem disku a 1. oddilem Gparted?

4.) A jak tyto programy - instalacni delici programy pri instalaci dister a Gparted - nastavit aby nechavaly na zacatku mezi zacatkem HDD a 1. oddilem nastavenou velikost volneho mista? Nebo aby vsechny oddily primo pri vytvareni zarovnavaly optimalne a nativne pro nejvyssi vykony a rychlosti?

Dekuji.

[Lubos]

1.) Pokud budu disk delit instalacnim nastrojem dane distribuce pri instalaci nebo pres Gparted úred instalaci a rozhodl bych se 1. oddil dat hned na zacatek a zadne volne misto pred nim, tak kolik presne volneho mista mi mezi zacatkem disku a zacatkem 1. oddilu necha instalacni nastroj a kolik Gparted?

2.) Jeste me napada, pri nastavovani kB, MB, GB, ... pri deleni disku mam pocitat s binarnimi predponami (1kB = 2^10B = 1024B, 1MB = 2^10kB = 1024kB, ...) nebo s dekadickymi predponami (1kB = 10^3B = 1000B, 1MB = 10^3kB = 1000kB, ...), pripadne nejakym binarne-dekadickym hybridem (divne, neuveritelne, obskurni, ale taky jsem se setkal)? Vim, ze vsichni, prevazne vyrobci HW a ulozist, ale i ruzne OS, aby usetrili penize a oklamali zakaznika prodejem "vetsiho" uloziste, v tom radi zamerne delaji zmatek, tak bych se rad orientoval, abych pri snaze zarovnat si disk optimalne a nativne, abych si zarovnani disku nakonec nerozhodil jeste vice uplne mimo do horsich parametru vlivem v dobre vire pouzivani spatnych jednotek.

3.) Dale, prestoze testy a jejich vysledky hovori jasne, presto mi neni jasne, proc zrovna 4MB? Pokud necham volnych 4kB, coz je nejvetsi velikost sektoru, melo by to taky stacit, ne? Proc to nestaci? Proc nestaci 1MB? A pokud dam vic nez 4MB, bude mi to asi k nicemu a vyssi vykon stejne neziskam, ne? Kolik nechavaji instalacni nebo delici programy standardne mezi zacatkem disku a zacatkem 1. oddilu? A tyka se doporucwni 4MB jak MSDOS tabulky tak i GPT nebo jsou doporuce i ruzna?

4.) Jak vlozim volne misto pred 1.oddil - mezi zacatek disku a 1. oddil? Je nutno vytvorit 4MB oddil, za nej 1. oddil ktery realne chci a pak ten 4MB oddil smazat nebo to lze i jednoduseji?

5.) A je mozne nejak nastavit instalacni delici program nebo Gparted, aby pri deleni disku rovnou zarovnaval oddily nativne a optimalne tak jak je dobre pro nejvyssi vykon a rychlost?

Dekuji moc.

[theseuszn]

Nemá cenu to už pitvat. Všechny návrhy co padly, ať byly jakékoliv, byly samozřejmě relevantní včetně toho placeba. Že z toho někdo dělá furt bramboračku nevím, ale na druhou stranu uznávám, že tabulkově jsou parametry dané, v tom su s oponentama zajedno. Jen si hold neuměj připustit, že to i s rádoby placebem, co není placebo, může chodit i jinak, než jsou zvyklý. Dávám odkaz, zkus si to přelouskat (doporučuji i ten španělsky mluvící odkaz, je to tam i nasnímkováno). Odkaz:

[theseuszn]

Jen jsem zapoměl dodat, že odkaz je z r.2016, takže s tím swapem už je to u současných distrech v podstatě pasé, jak už bylo v předchozích vláknech napsáno, protože swap už není oddíl, ale soubor...

[Gilhad]

jak už bylo v předchozích vláknech napsáno,

Doplnil bych nesprávně, protože swap může být jak oddíl, tak i (za cenu snížení výkonu) soubor, nebo kombinace obojího ...

[Jendа]

1.) Pokud budu disk delit instalacnim nastrojem dane distribuce pri instalaci nebo pres Gparted úred instalaci a rozhodl bych se 1. oddil dat hned na zacatek a zadne volne misto pred nim, tak kolik presne volneho mista mi mezi zacatkem disku a zacatkem 1. oddilu necha instalacni nastroj a kolik Gparted?

Do roku ~2012 se většinou nechávalo 32 KiB, od té doby se většinou nechává 1 MiB. Nicméně to záleží na instalátoru té které distribuce. Rozhodně bych doporučil nechat 1 MiB, protože už jsem řešil že se do 32 KiB nevešel GRUB s některými moduly které byly potřeba (nějaký RAID a nevím co ještě).

2.) Jeste me napada, pri nastavovani kB, MB, GB, ... pri deleni disku mam pocitat s binarnimi predponami

Pro účely zarovnání jednoznačně s binárními, neboť sektory jsou 512 B nebo 4 KiB.

3.)

To mi také není jasné, ale netrápí mě to zas tolik abych to nějak zkoumal .

4.) Jak vlozim volne misto pred 1.oddil - mezi zacatek disku a 1. oddil? Je nutno vytvorit 4MB oddil, za nej 1. oddil ktery realne chci a pak ten 4MB oddil smazat nebo to lze i jednoduseji?

V cfdisku jsem to musel dělat zmíněnou složitou cestou. V některých jiných nástrojích (parted, fdisk, gparted) jde při vytváření oddílu přímo zadat začátek.

[Josef Kufner]

Ad 4: Pokud chceš oddíl, který nezačíná na začátku, tak tam prostě napíšeš něco jiného než nulu, když se to ptá na začátek.

[Jendа]

Mě se cfdisk vždycky ptal jenom na velikost, ne na začátek.

[k3dAR]

btw:parted pri zadani zacatku 0% zacne spravne na 1MiB

[Gilhad]

Také lze na začátek disku dát nějaký oddíl jako /boot či tak něco podobného (který se nečte často a zapisuje ještě méně) a udělat jeho konec správně zarovnaný na nějaký násobek té 4M hranice, aby další, hodně používaný, začínal na správném zarovnání. Tak využiješ i ten kousek vepředu, ale číst se bude z čehosi zarovnaného :)