Изпечатай

[runtime]

Някой има ли обяснение за следната ситуация

Код:

Filesystem            Size  Used Avail Use% Mounted on
aufs                   74G    283M   70G   1% /
tmpfs                 499M     0     499M   0% /dev/shm
/dev/sda1            74G   283M   70G   1% /mnt/sda1

И по точно реда
/dev/sda1            74G   283M   70G   1% /mnt/sda1

как точно 74G - 283M правят 70G

Имам някакъв бегъл спомен в който се разискваше точно това, но нещо не откривам темата
И има ли някакъв по-точен начин за изчисление на големината и заетото пространство? 

Както и да го въртя си показва каквото си знае

Код:

df -h -H
Filesystem             Size   Used  Avail Use% Mounted on
aufs                    79G   296M    75G   1% /
tmpfs                  523M      0   523M   0% /dev/shm
/dev/sda1               79G   296M    75G   1% /mnt/sda1

Код:

df
Filesystem           1K-blocks      Used Available Use% Mounted on
aufs                  76920416    288808  72724200   1% /
tmpfs                   510024         0    510024   0% /dev/shm
/dev/sda1             76920416    288808  72724200   1% /mnt/sda1

[neter]

Темата, в която наскоро стана дума, е тази. Причината е размерът на блоковете (block size).
С малко по-житейски пример, блоковете представляват кошници, в които си слагаш данните. Ако имаш 1.2 куб.м ябълки и кошниците ти са с обем 0.5 куб.м, то ще сложиш ябълките в 3 кошници, като третата няма да е пълна. След това трябва да напълниш 2.4 куб.м круши в кошници със същия размер, при което ще използваш 5 кошници, като 5-ата кошница няма да е пълна. И тъй като ябълките и крушите не трябва да се смесват, дотук имаш сумарно не оползотворено пространство от двете непълни кошници в размер на 0.4 куб.м. С нарастване видовете на артикулите ще нараства и не оползотвореното пространство.
И докато df в графата "Used" показва общия размер на артикулите без не оползотворените пространства, то графата "Avail" показва максималния размер на артикулите, които можеш да побереш в оставащите кошници

П.П.: В примера по-горе се приема, че не остават никакви празни места между отделните ябълки и круши, тъй като няма такова при записването на данните в един блок

[runtime]

Ясно
Което обяснява факта защо е добре да си разделяш диска, като например папка etc да бъде монтирана в дял с по-малък размер на блоковете.. Някога, някой ме беше съветвал да си разделям диковете и да си правя блоковете по малки и там да се монтират папки съдържащи файлове с малък размер ама кой да слуша 

[gat3way]

Не е толкова черно на бяло и за всичко си има цена. Гореописания ефект се нарича "вътрешна фрагментация", но има и друг момент - с по-малки блокове от данни, "външната фрагментация", т.е това което добре познаваш от опита си с FAT32 започва да играе по-голяма роля с всичките си прелести заради бавния seek time. Отделно при по-малка големина на блоковете наистина трябва да имаш малки файлове - в противен случай inode таблиците стават по-големи защото описват повече блокове и не се знае колко ще спестиш и колко ще хартисаш.

Изводът е че ако файловата ти система няма 4 (по груби сметки) терабайта и ако имаш предимно малки файлове които често се модифицират и се пишат/трият нови, тогава малкия block size от 1КБ има файда. В противен случай най-добре остави mkfs да се оправя и не ги мисли тези неща.

[neter]

Общо взето твърдият размер на блоковете си е кофти работа - колкото и да го планираш, винаги се губи доста място. Все се надявам в бъдеще да се появят блокове с плаващ размер или inode-и, в които може да се записва миксирана информация, така че части от два файла да могат да влизат в един блок. Не съм чел достатъчно по въпроса, така че нямам идея как точно да се случи или дали има вече някакви пробни разработки по въпроса. Но има нужда сегашната картинка да се промени. А дотогава настройката по подразбиране си е най-доброто решение, ако не са направени наистина дълбоки сметки за конкретната ситуация.

[drag]

Всичко си е наред с df и "проблема" не е от размера на блоковете. По подразбиране файловата система (ext2-3-4) резервира 5% от общия капацитет за т.нар. "privileged  processes"
ето и малко математика:

74GB - 5% = 70.3GB - 283MB = 70GB.

Ако това е дял на който има само данни спокойно можем да махнем тези резервирани 5%, което става с tune2fs.

Ето и част от мана:

tune2fs - adjust tunable filesystem parameters on ext2/ext3/ext4 filesystems

 -m reserved-blocks-percentage
              Set the percentage of the filesystem which may only be  allocated  by  privi‐
              leged  processes.    Reserving  some  number  of filesystem blocks for use by
              privileged processes is done to avoid filesystem fragmentation, and to  allow
              system  daemons,  such as syslogd(, to continue to function correctly after
              non-privileged processes are prevented from writing to the filesystem.   Nor‐
              mally, the default percentage of reserved blocks is 5%.

иначе казано :

Код:

tune2fs -m 0 /dev/sda1

Поздрави!

[neter]

ПО подразбиране файловата система резервира 5% от общия капацитет за т.нар. "privileged  processes"

Правилно, но не и за конкретната ситуация. Запазеното пространство не е видимо с df. Запазеното пространство, за което говориш, е извън тези 74G. Загубеното пространство, което влиза в тези 74G, е точно заради размера на блоковете, и по-точно заради това, че информацията не може да ги запълва постоянно изцяло

[drag]

Не съм сигурен, че те разбрах правилно, но df вижда общия капаците винаги по един начин, с промяна на резервираното пространство се променя само свободното в изхода на df

Код:

tune2fs -m 5 /dev/sdb1

df -h
                                                               Size   Used   Avail   Use%   Mounted on
/dev/sdb1                                                  600G  121G  449G   22%    /store
....

tune2fs -m 0 /dev/sdb1

df -h

 Filesystem                                              Size   Used   Avail   Use%   Mounted on
/dev/sdb1                                               600G  121G  479G   21%   /store

[neter]

Опа, прав си, извинявам се - df в колоната "Size" обхваща и запазеното пространство, а колоната "Used" обхваща и не оползотвореното пространство. Не че проблемът с непопълнените блокове не съществува, но загубеното от него пространство влиза в тези 283M при runtime и в тези 121G при теб. А разликата, за която пита runtime, е от запазеното пространство. Прав си

П.П.: Ей затова се противях в другата тема на разнообразните методи за степенуване и броене на свободни места в различните инструменти. Само до обърквания водят

[drag]

 

[runtime]

А ако е root даля и ги спра с tune2fs това предполагам би оказало проблем ако се напълни някой ден диска и най-вероятно няма да откъне ОС? Или има и друга по-важна причина да заделя тез 5%?

[neter]

Запазеното място се ползва и от алгоритмите за предпазване от фрагментация. При днешните размери на дисковете 5% са много. Надявам се по някое време да се въведат и части от процента (в момента приема само цели стойности), защото 1% от 1TB диск са си 9.3GB - ако машината не генерира някакви огромни логове, това място няма да се оползотвори. Намали го на 1% (760MB са напълно достатъчни). А ако някой дял ще се ползва само за големи файлове, дори можеш да му зададеш 0% - няма да те касае особено фрагментирането в такъв дял.

[runtime]

Ок, мерси за пояснението.