Linux využití disku

[eva46]

Zdravím, přešla jsem kvůli konci podpory mého notebooku na Linux a řeším problém s množstvím místa na datovém disku. 1TB disk by měl mít z výroby 931GB. Tolik místa bylo i využitelné pod NTSF. Tento disk /dev/sdb1 jsem přidala do fstab, aby se mountoval automaticky po startu. Jeho maximální velikost např. v Thunaru, nebo df utilitě je však jen 916GB. Formátováno bylo pomocí gparted, kde to i ukazovalo správně velikost 931GB, ale ihned po naformátování, kdy měl být disk úplně prázdný, to ukazovalo využitých 15GB. Dokázal by mi někdo vysvětlit, co to má být a jak nejlépe docílit využití maxima? Může to být swap? Ten je nastaven do souboru, ale čekala bych, že bude jen na /dev/sda1.

Už se mi povedlo i najít, že Linux by default rezervuje 5% místa pro roota. To už je pořešeno. Ono to taky dělalo skoro 50GB.

[Reklama]

[_Jenda]

df defaultně ukazuje v debilních jednotkách (tvrdí že v GB, ale přitom jsou to GiB). Na GB se to přepne -H.

Dále dej fdisk -l, případně otisk obrazovky cfdisk /dev/sdx, jestli je třeba jako partition přes celý disk, a výpis df -H, a taky si to zkus proklikat v ncdu.

[eva46]

Pošlu odpoledne, až se dostanu k PC, ale df bylo s -h přepínačem. Už úplně z hlavy nevím, které všechny utility byly vyzkoušeny, ale snad vše, mimo ten gparted, hlásilo 916GB. Jakoby to snad bylo blbě naformátované na max velikost 916. Pro jistotu to odpoledne ověřím a pošlu případně screeny. cfdisk jsem nezkoušela, třeba ten to rozlouskne. Díky.

[_Jenda]

ale df bylo s -h přepínačem.

No právě.

[vcunat]

df defaultně ukazuje v debilních jednotkách (tvrdí že v GB, ale přitom jsou to GiB). Na GB se to přepne -H.

1 TB = 931 GiB.  Tehle předpoklad tedy byl zahrnut už zpočátku dotazu.

O tomhle se hádat rozhodně nechci, ale za debilní to nepovažuji.  Místo na disku se stále alokuje po blocích velikosti nějaké mocniny dvojky (4096 aj.)

[Reklama]

[_Jenda]

Místo na disku se stále alokuje po blocích velikosti nějaké mocniny dvojky (4096 aj.)

Na některých vrstvách (například na SSD které ukládá 3 bity do buňky ne, a navíc tam jsou různé úrovně error correction) a nevím proč by mě to jako uživatele mělo zajímat.

Jinak u toho df je například taky potřeba zjistit, jestli to ukazuje 916 GB kapacitu nebo free (třeba když má root rezervované místo, tak to IIRC vypadá tak, že to ukazuje kapacitu plnou, ale uživateli méně free, takže used + free < kapacita).

No a pak by se ještě možná dalo koukat do dumpe2fs v krajní nouzi.

[František Ryšánek]

Wikipedia má ohledně binárních a desítkových mega/giga/tera docela obsáhlé heslo - odkaz je na názornou tabulku.

Pro rozpitvání mohu doporučit:

Kód: [Vybrat]

### Celé blokové zařízení

# v bajtech:
blockdev --getsize64 /dev/sdb

# v sektorech o velikosti 512B:
blockdev --getsz /dev/sda

# viz též
blockdev --help

smartctl -a /dev/sdb

### Rozdělení disku na oddíly (nástrojů typu fdisk je spousta)

# human readable
sfdisk -l /dev/sdb

# machine readable
sfdisk -d /dev/sdb

### Jaký je na kýženém oddílu souborový systém?
dumpe2fs -h /dev/sdb1
ntfsinfo /dev/sdb1

### Volné a obsazené místo v souborových systémech / stromech adresářů

# volné místo v blocích o velikosti 1k (nevím jestli binární nebo dekadické) per mountpoint
df

# místo zabrané soubory a adresáři, stromově, neomezená hloubka
du

# omezit hloubku na jedno patro
du -d 1

# soubory s tečkou na začátku jména jsou skryté.
ls -a
ls -al


Zmíněné programy jsou z následujících balíčků:
blockdev : util-linux
smartctl : smartmontools
sfdisk : util-linux
dumpe2fs : e2fsprogs
ntfsinfo : ntfs-3g

[František Ryšánek]

Ještě mě napadá, že takový GParted má hezké GUI, kde jsou všechny informace v kostce, včetně volného místa za koncem posledního oddílu a volného místa per oddíl (tzn. uvnitř filesystémů).

EDIT aha, tazatelka GParted použila jako první...

[František Ryšánek]

...našel jsem dost podrobnou analýzu ze které plyne, že v případě Ext2/3/4 jde o úhrn několika druhů režijních bloků využívaných filesystémem pro vlastní potřebu. "Reserved block count" ve výstupu dumpe2fs. Namátkou koukám na jeden zaplněný filesystém o velikosti 1.5 TB a tahle režie je asi 70 GB (snad to interpretuju správně).

[RDa]

Muzu potvrdit, ze sezrane misto na ext je relativne velke (radove desitky GB na nekolikaterovem zarizeni), a zavisi od poctu inodes pri mkfs. Defaultne je tam nesmyslne velke cislo, a rucne to upravit lze jenom na mensi ale porad nesmyslne cislo - v podstate je pocet inodu na grupu ma fixni minimum (grupa obsahuje bitmapu+inody), a pocet grup zavisi od kapacity.

Takze je tam procentualne nejake misto rezervovano pro struktury FS.
Dalsi misto sezerou treba adresare, ale to je rekneme zanedbatelne v pomeru k realnym datum.

With the default options, every 128mb of disk gets 2 mb ( 8192 x 256 bytes each ) of inodes, or 1.6% overhead.
https://serverfault.com/questions/282317/disk-space-overhead-in-ext4

Problemem je to, 128MB pro grupu je maximum na 4K clusterech (blocich) a reseni by bylo prejit na 64K bloky jedine, viz:
https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Blocks

[František Ryšánek]

@RDa právě jsem po létech pochopil, proč mkfs.ext3 vždycky tak trvá a generuje tolik IOps na disky :-) Pokud se nepletu, mkfs.ext4 se vrátí v shellu rychleji, ale inicializace metadat pokračuje na pozadí (tipnu si, že ji dotáhne nějaký kthread).

[RDa]

@RDa právě jsem po létech pochopil, proč mkfs.ext3 vždycky tak trvá a generuje tolik IOps na disky :-) Pokud se nepletu, mkfs.ext4 se vrátí v shellu rychleji, ale inicializace metadat pokračuje na pozadí (tipnu si, že ji dotáhne nějaký kthread).

Ano, na ext4 se to jmenuje: lazy_itable_init[= <0 to disable, 1 to enable>]

If  enabled  and the uninit_bg feature is enabled, the inode table will not be fully initialized by mke2fs.  This speeds up file system  initialization noticeably, but it requires the kernel to finish initializing the file system in the background when the file system is first mounted.  If the option value is omitted, it defaults to 1 to enable lazy inode table zeroing.

Objevil jsem to taky nahodou - kdyz jsem se divil proc blika namounteny prazdny disk - prvni bylo tedy leknuti, ze me nekdo vycucava data :-)

[eva46]

Díky všem za tipy. Zde jsou výpisy z konzole:

Kód: [Vybrat]

df -H
Souborový systém Velikost Užito Volno Uži% Připojeno do
/dev/sdb1            984G  938G   47G  96% /media/data


Kód: [Vybrat]

df
Souborový systém Velikost Užito Volno Uži% Připojeno do
/dev/sdb1            916G  873G   44G  96% /media/data


Kód: [Vybrat]

sudo fdisk -l /dev/sdb1
Disk /dev/sdb1: 931,51 GiB, 1 000 203 091 968 bajtů, 1 953 521 664 sektorů
Jednotky: sektorů po 1 * 512 = 512 bajtech
Velikost sektoru (logického/fyzického): 512 bajtů / 4096 bajtů
Velikost I/O (minimální/optimální): 4096 bajtů / 4096 bajtů

Podle příspěvků, co tu padly, to tedy vypadá jen na tu režii filesystému? df -H ukazuje 984, místo 1000, ale fdisk už správně v GiB.

[František Ryšánek]

Podle příspěvků, co tu padly, to tedy vypadá jen na tu režii filesystému?

Kód: [Vybrat]

dumpe2fs -h /dev/sdb1 | grep 'Reserved block count'

[eva46]

To vrací 0. Ale to už jsem psala, že defaultní reservaci 5% místa pro roota jsem vypnula. Můj problém se vlastně projevil tak, že disk, původně zformátovaný NTFS obsahoval nějaká data. To se přepláclo ext4 a data zpět kopírovala z externího disku. No posledních pár souborů už se nevlezlo, i když původně bylo cca 50GB volných. Tak jsem to začala řešit. 5% pro roota je pořešených, pořád ale nechápu to 916 vs 931, když každá utilita hlásí něco jiného