Apple představil nový MacBook Pro s čipy M4, M4 Pro a M4 Max.
Na GOG.com běží Halloween Sale 2024. Při té příležitosti lze získat zdarma počítačovou hru Return of the Phantom.
Společnost OpenAI spustila internetový vyhledávač ChatGPT search.
Konference OpenAlt 2024 proběhne již tento víkend 2. a 3. listopadu v prostorách FIT VUT v Brně. Začíná ale už v pátek na warm-up party ve Studentském klubu u Kachničky v 17:00. Pokud jste ještě areál FITu nenavštívili, k dispozici jsou pokyny k orientaci. Na programu je 54 přednášek a workshopů. Témata jsou od silně technických témat jako je třeba GCC nebo PostgreSQL po méně technické témata jako eGovernment, nebo třeba detailní analýzu … více »
Byla vydána nová verze 6.9 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 14.0.1. Tor client na verzi 0.4.8.13. Thunderbird na verzi 115.16.0.
Vývojáři free a open source synchronizačního nástroje (a p2p náhrady Dropboxu) Syncthing oznámili, že z důvodu odporu ze strany Google Play ukončují podporu OS Android. Bohužel v rámci toho zmizí i vydání Syncthing na F-Droid, který má slabší uživatelskou základnu. Syncthing je na Androidu implementován formou wrapper aplikace, která spustí Syncthing démon, vyžádá potřebná oprávnění a zpřístupní webové rozhraní démona. Ve srovnání se
… více »V červnu 2022 bylo oznámeno, že z K-9 Mailu se stane Thunderbird pro Android. Trvalo to poněkud déle, než vývojáři předpokládali, ale včera byl první stabilní Thunderbird pro Android 8.0 vydán.
Projekt microDMG Racer na Kickstarteru nevyšel, tak se autor rozhodl uvolnit na ESP32 postavené autíčko i ovladač jako open source.
Byl vydán TrueNAS SCALE 24.10 „Electric Eel“. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Byla vydána nová verze 24.10.29 svobodného multiplatformního video editoru Shotcut (Wikipedie) postaveného nad multimediálním frameworkem MLT. Nově s podporou AI (whisper.cpp) pro generování titulků. Nejnovější Shotcut je již vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
[...]Nevím, co by se muselo stát, aby se dvojka stala pravdou (něco jiného je to u serveru)[...]napr. tohle
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?
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?
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íš?
…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 …
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ě ,...).
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.
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.imgGRUB2:
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 }
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
.
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 }
lilo
, které udělalo to, že seznam nových bloků napsalo do MBR.
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ástrojiNo 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íratJo, 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.
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)
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í
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é.
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.
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...@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??
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?
Tak to je pro mě novinka. Do teď jsem žil v domění, že bloky se skládají ze sektorů.
Jinak dík za odkaz.
Zkusím, ale až zítra.
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.
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?
Nechápu. Myslíš to ve vztahu k /tmp?
Zakomentoval jsem tmpfs v /etc/fstab, ale stejně mi pak ten příkaz pro vyčištění nefungoval (po rebootu samozřejmě).
Když v /etc/fstab nachám zakomentován tmpfs, stačí pak killall -u?
Tak sudo killall -u mi pořád jen zobrazuje nápovědu.
Tak jsem zkusil oba ty příkazy a i s 3 a vždy to napsalo: "operace zamítnuta" (jako root).
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ě?
sysctl -q -w vm.drop_caches=3pri zapisu myslim nema vliv, ale i tak sem radeji doporucil misto /dev/zero (coz jsou same nuly) pouzit /dev/urandom(coz generuje "nahodne" data)
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.
Každopádně všechny časy jsou horší, než když byl vstup /dev/zero.
Tak to je jasné.
Tak tobě jo, ale mě to jasné nebylo. Čím je to způsobeno?
@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é.
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íš.
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:
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 ...
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 predponamiPro úč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.
Tiskni Sdílej: