Re: změna velikosti UFS partition

[David Pasek]

2011/3/12 Dan Lukes <dan at obluda.cz>:
> To vypada na modifikaci popsaneho algoritmu a to "pokud by se mel zapsat
> blok plny nul, misto toho se uvolni".
>
> To je takove trochu "automagicke" reseni. Muze to vyrabet "derave" soubory
> za situace, kdy si to neprejes.
>
> Ale bez podpory TRIM na hostujicim i hostovanem systemu to asi lepe nejde.
>
> Dan
>

Ano. Je to v podstate modifikovane reseni puvodniho problemu.

Jelikoz se ukazalo, ze neexistuje nastroj na zmensovani UFS partition
jelikoz je to celkem malo casto pozadovana operace administratora OS
(napriklad ja za svou minimalne 15 letou praxi jsem nikdy nepotreboval
zmenosvat disk/slice/partition.. vetsinou potrebuju zvetsovat). Psal
si, ze evoluce sla jinam a ja jen potvrdil tvoje slova, ze sla, nebot
dnes je trend, aby byl flexibilni nejen OS a filesystem, ale i
hardware, na kterem OS/filesystem bezi.

Puvodni dotaz se ptal, jak zmenit velikost UFS partition. Pouze
puvodni tazatel zna duvod proc to potrebuje, nicmene hlavnim duvodem
asi bude usetrit fyzicky prostor na disku a vyuzit ho k necemu
smysluplejsimu nez diram v souborech na filesystemu. Toto modifikovane
reseni to presne resi, nicmene jen pri pouziti v urcitem prostredi,
ktere se podle meho nazoru dnes stava de-facto standardem pro provoz
serveru. Uz dlouho jsem nevidel server, ktery je schopny vyuzit vykon
desnich modernich x86 serveru. A to projizdim a casto monitoruju
datova centra po cele stredni a vychodni Evrope, Rusku i blizkem
vychodu. I kdyz samozrejme takove servery existuji ;-), ale
procentualne vyjadreno je to dnes urcite mene jak 5%. A casem to podle
Moorova zakona bude jeste mene.

Jestlize na systemu data postupne pomalou rostou (typicky databaze) a
nikdo nevi, jaka kapacita bude potreba, pak ten thin-provisioning disk
dava smysl. V pripade casteho mazani uz je to opravdu sporne, protoze
automaticke uvolnovani opravdu na vetsine filesystemu nefunguje
transparentne. Nicmene jsou-li v OS nainstalovany napr. VMware tools
(agent v OS), tak ty umoznuji tzv. disk shrinking (
http://www.vmware.com/support/ws5/doc/ws_disk_shrink.html ) coz je
podle me "userland" nahrada podpory TRIMU ve filesystemu.

Nedalo mi to a udelal jsem si par testu ...

Test na freebsd bez VMware tools a s pouzitim manualniho disk shrinku
pomoci dd if=/dev/zero ... :

1/ VM s 8GB thin-provisioning diskem
2/ instalace cisteho freebsd
    => vmware disk usage=1.4GB, freebsd file system usage=935MB
3/ dd if=/dev/random of=test.dat bs=1m count=1000
   => vmware disk usage=2.39GB, freebsd file system usage=1.9GB
4/ rm test.dat
   => vmware disk usage=2.39GB, freebsd file system usage=935MB
5/ dd if=/dev/zero of=shrink.dat bs=1m count=10000
   => vmware disk usage=8.12GB, freebsd file system usage=full
6/rm shrink.dat
   => vmware disk usage=8.12GB, freebsd file system usage=935MB
7/VMware Storage vMotion
   => vmware disk usage=2GB, freebsd file system usage=935MB

Bohuzel se to z pohledu vmwaru nedostalo zpet na mnou predpokladanych 1.4GB.
Zkusim tedy jeste jeden stejny pokus na tomto systemu.

8/ dd if=/dev/random of=test.dat bs=1m count=1000
   => vmware disk usage=2.93GB, freebsd file system usage=1.9GB
9/ rm test.dat
   => vmware disk usage=2.93GB, freebsd file system usage=935MB
10/ dd if=/dev/zero of=shrink.dat bs=1m count=10000
   => vmware disk usage=8.19GB, freebsd file system usage=full
11/ rm shrink.dat
   => vmware disk usage=8.19GB, freebsd file system usage=935MB
12/ VMware Storage vMotion
   => vmware disk usage=1.64GB, freebsd file system usage=935MB

Hmm ... zajimave

Tak zkusim vytvorit 4 GB soubor, ktery smazu a zajima me jaka bude
finalni vyuzita kapacita disku.
13/ dd if=/dev/random of=test.dat bs=1m count=4000
   => vmware disk usage=5.38GB, freebsd file system usage=4.8GB
14/ rm test.dat
   => vmware disk usage=5.38GB, freebsd file system usage=935MB
15/ dd if=/dev/zero of=shrink.dat bs=1m count=10000
   => vmware disk usage=8.12GB, freebsd file system usage=full
16/ rm shrink.dat
   => vmware disk usage=8.12GB, freebsd file system usage=935MB
17/ VMware Storage vMotion
   => vmware disk usage=2.03GB, freebsd file system usage=935MB

ZAVER:
VMware thin provisioned disk se po manualni shrink procedure umi
dostat zpatky na zhruba 2GB, coz muze byt nejaka interni zalezitost
(low threshold) VMwaru, ale principialne to funguje.

V pripade pouziti VMware tools by to asi bylo castecne zautomatizovano
- kdyby mel nekdo zajem, tak to muzu otestovat, ale natolik me to
osobne nezajima.

Vim, ze je to trosku neco jineho nez zmensit partition, ale kdyz jsme
zabrousili do evoluce, tak mi nedalo nezminit tuto techniku, ktera je
dustupna v nekterych virtualizacnich resenich a storage systemech.

David.
-- 
David