Dotaz: Jaky zvolit filesystem na ext. HDD abych "neprisel" o zadne misto

[polo23]

Cau, potrebuju radu ohledne volby filesystemu. Koupil jsem si novy 1TB externi disk. GParted spravne ukazuje kapacitu 931GB. Naformatoval jsme ho na ext3 a GParted najednou ukazuje ze je 14GB zabranych. Predpokladam ze je to pro roota. Ja ten disk budu pouzivat pouze na zalohy a na skladovani virtualnich stroju takze onech 14GB bych rad uvolnil. Nevim ale jak je "dealokovat". Nevite nekdo jak na to?

P.S. Napada me jen...myslite ze resenim by bylo znova vytvorit fdiskem partition(je tam jen jedna) ale tak aby byl disk "85 Linux extended" misto "83 Linux"?

Odpovědi

[Heron]

tune2fs -m0 /dev/partitionnatomdisku

Více poradí man tune2fs.

[luta]

patrně s právy root spustit :

tune2fs -m 0 /dev/sdXy

rezervuje 0% bloku pro roota viz manual tune2fs

[luta]

hm nez jsem to dopsal uz tu byla najednou odpoved :) jen dodam ze nemusis formatovat znova..tohle staci provest hned i s daty na disku..v podstate to jen zmeni ty rezervovane bloky..filesystem se nezmeni

[polo23]

...tak nevim co delam spatne, ale nejak se nedari. Jak GParted tak df -h porad ukazuji ze onech 14GB je alokovanych.

sudo tune2fs -m 0 /dev/sdb1
tune2fs 1.41.3 (12-Oct-2008)
Nastavuji procento rezervovaných bloků na 0 % (0 bloků)

df -h
Souborový systém Velikost Užito Volno Uži% Připojeno do
/dev/sdb1 917G 200M 917G 1% /media/disk

Ma tam byt 931GB volnych (zadna data tam nemam.)

[luta]

no podle tohoto vypada ze ma ten filesystem skutecne velikost "jen" 917GiB z toho 200M pouzito.. nejde v gparted zvetsit ? v prostoru uz neni zadne volne misto za ci pred oddilem ? treba fdisk by mohl byt napomocny pokud gparted zlobi..

fdisk -l /dev/sdb

[polo23]

Přílohy:

• Obrazovka-2.png (99671 bytů)
• Obrazovka-1.png (66575 bytů)

V GParted nejde zvetsit neni kam... viz prilozene screeny.

sudo fdisk -l /dev/sdb
Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x372c0fdb
Device Boot Start End Blocks Id System
/dev/sdb1 1 121601 976760001 83 Linux

[Petr]

Myslím, že uvažuješ špatně. Gparted a jakákoliv partišnová utilita ukazuje holou velikost partišny bez filesystému. prostě počet sektorů které partišně na disku odpovídají krát 512 bytů na sektor. to co píše df je výsledek který máš pro vlastní data. Rozdíl ti zabirá filový systém. Hlavní část toho prostoru tovří nutná informace, které sektory jsou volné, a jak je soubor rozprostřen mezi sektory, tedy ke každému souboru musím mít někde napsánu posloupnost sektorů v nichž je uložen a jak na sebe navazují. Jinak bys měl lineární posloupnost sektorů jako kdysi na páskách u mainframů.

A 2% režie na je málo.

[polo23]

Hlavní část toho prostoru tovří nutná informace, které sektory jsou volné, a jak je soubor rozprostřen

Nemyslis ze 14GB pro tyto informace je nejak moc?

[happy barney]

ext3 generuje fixný počet i-node pre celý disk, tie nejaké to miesto zaberajú. Ak ti na tom tak moc záleží, použi fs s dynamickou alokáciou

[polo23]

OK az tak mi na tom nezalezi...pokud to nejde nejak jednoduse dealokovat necham to tak. Diky za vysvetleni

[polo23]

Jeste bych teda dodal... Chapu to tedy spravne ze at je tech alokovanych 14GB pro cokoliv tak to urcite neni pro roota?

[Heron]

14GB z 931GB je 1.5%. Ano, je to overhead FS. ext3 používá staticky alokované inody, u ostatních FS by tato velikost byla také, ale až po zaplnění daty. Takže, ještě jednou, metadata zabírají pouhé 1.5%. Což je v porovnání s některými protokoly naprosto směšná hodnota.

Pokud vidíš ve výpise tune2fs -l: Reserved block count: 0, tak je pro roota rezervováno právě tolik bloků.

[polo23]

Pokud vidíš ve výpise tune2fs -l: Reserved block count: 0, tak je pro roota rezervováno právě tolik bloků.

Jo presne tolik vidim... Akorat jsem se pred pouzitim samotneho programu tune2fs nepodival kolik tam bylo predtim, ale jelikoz se po prikazu sudo tune2fs -m 0 /dev/sdb1 neuvolnilo zadne misto tak predpokladam ze Reserved block count: 0
tam bylo uz pred pouzitim tune2fs jinak si to vysvetlit neumim.
Diky za vysvetleni.

[pht]

u ostatních FS by tato velikost byla také, ale až po zaplnění daty

Byla nebyla. Záleží co za data. Pokud tam bude několik málo obrovských souborů, tak ext3 bude mít ještě další overhead jak prase, protože neumí extenty.

PS. ještě tady nepadlo že část z těch 14GB je journal.

[Heron]

Velikost žurnálu píše mkfs.ext3 při vytváření většinou je to 32k bloků, tedy 128MiB.

[lertimir]

ještě poslední poznámka, jakou má spotřebu na inode zjistíš pomocí tune2fs -l /dev/sdb. Např já mám pro jeden svůj malý oddíl část výpisu

Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1022
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8208
Inode blocks per group:   513

Z toho je vidět, že mám 4K bloky,takže po 8 sektorech, jsou seskupeny do skupin každá má 32K bloků (tedy 128M na skupinu), pro každou skupinu je 8k inode a inode zabirají 513 bloků, Takže 513/32768 je ztráta v alokační struktuře, tedy asi 1,8%. Ještě brutálnější výpis se dostane pomoci dumpe2fs /dev/sdb kdy to jde přímo na alokované bloky.

A to se zeptám ještě jestli tomu někdo rozumí. dumpe2fs mi v některých skupinách ukáže, že mám 0 volných inode a nějaké volné bloky. Znamená to, že se k těm volným blokům už nejsem schopen dostat, protože skupina už nemá volné inode a pak je není schopna přidělit k souboru? Nebo je mohou přidělit souborům i inode z jiných skupin?

Group 148: (Blocks 4849664-4882431) [ITABLE_ZEROED]
  Checksum 0xc153, unused inodes 0
  Block bitmap at 4718596, Inode bitmap at 4718612
  Inode table at 4720676-4721188
  3757 free blocks, 0 free inodes, 642 directories
  Free blocks: 4862077-4862101, 4862194-4862975, 4863066-4863076, 4872938-4873215, 4873307-4873330, 4873597-4873727, 4873903-4873983, 4874129-4874164, 4874203-4874751, 4874936-4874990, 4880094-4881056, 4881261-4882082
  Free inodes: