2011/3/12 Dan Lukes <[email protected]>: > 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 -- FreeBSD mailing list ([email protected]) http://www.freebsd.cz/listserv/listinfo/users-l
