Je libo 16 GB nul? Jistě, hned to bude...

2.5.2009 07:58 | Přečteno: 2715× | Programování | poslední úprava: 2.5.2009 08:02

V UNIXu existuje hned několik utilit, které umí na požádání vytvořit velký soubor. Hodí se například v situaci, kdy uživatel potřebuje soubor pro loopback zařízení. Já jsem si jen tak ze cviku takovou utilitu napsal a pak jsem trochu experimentoval.

Následuje zdrojový kód té utility. (U mě se jmenuje bigfile.c.) Přeloží se na Linuxu a na OpenSolarisu. Jiné systémy jsem nezkoušel.

#define _LARGEFILE64_SOURCE

#include <unistd.h>
#include <stdio.h>
#include <errno.h>
#include <stdlib.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/stat.h>

static const int BASE = 10;
static const int ERROR = -1;

#define EXIT( shift ) return 1 << ( shift - 1 )
#define CLOSE_AND_UNLINK( descriptor, name ) do { \
	if ( ERROR == close( descriptor ) ) { \
		perror( "Could not close file" ); \
	} \
	if ( ERROR == unlink( name ) ) { \
		perror( "Could not delete file" ); \
	} } while ( 0 )

int main( int argc, char ** argv ) {
	off64_t offset;
	char * end;
	int fd;

	if ( argc != 3 ) {
		fputs( "Usage: bigfile <name> <size in B>\n", stderr );
		EXIT( 1 );
	}

	errno = 0;
	offset = strtoll( argv[ 2 ], &end, BASE );
	if ( errno ) {
		perror( "Invalid number" );
		EXIT( 2 );
	}
	if ( *end ) {
		fputs( "Invalid number: Trailing garbage found.\n", stderr );
		EXIT( 3 );
	}
	if ( offset <= 0LL ) {
		fputs( "Invalid number: Positive value required. Use touch(1) to create zero-length files.\n", stderr );
		EXIT( 4 );
	}

	if ( ERROR == ( fd = open( argv[ 1 ], O_WRONLY | O_CREAT | O_EXCL | O_LARGEFILE, S_IRUSR | S_IWUSR ) ) ) {
		perror( "Failed to create file" );
		EXIT( 5 );
	}

	if ( ERROR == lseek64( fd, offset - 1, SEEK_SET ) ) {
		perror( "Failed to set file offset" );
		CLOSE_AND_UNLINK( fd, argv[ 1 ] );
		EXIT( 6 );
	}

	if ( ERROR == write( fd, end, 1 ) ) {
		perror( "Failed to write" );
		CLOSE_AND_UNLINK( fd, argv[ 1 ] );
		EXIT( 7 );
	}

	if ( ERROR == close( fd ) ) {
		perror( "Failed to close file" );
		EXIT( 8 );
	}

	return EXIT_SUCCESS;
}

#undef EXIT
#undef CLOSE_AND_UNLINK

Použití může vypadat například takto:

./bigfile MyHugeFile $((2**34))

Překvapilo mě, že vytvoření souboru o velikosti 16 GB trvá zlomek sekundy. Nezaznamenal jsem žádný rozdíl ve srovnání s touch. Odezva byla (z lidského pohledu) okamžitá. I následný sync skončil prakticky ihned. (!) Totéž platí pro Linux i pro Solaris.

Nejspíš tam funguje nějaká líná alokace bloků, která je vyhradí teprve v případě potřeby. Přestože ls ukazoval u nového souboru správnou velikost a mkfs.reiser4 (na Linuxu) v něm dokázal (v čase mnohem kratším než sekunda) vytvořit souborový sytém (pro loopback), údaje o obsazenosti celého disku se téměř nezměnily. Teprve když jsem namountoval loopback zařízení a zapsal do něj nějaký ten gigabyte dat, začalo to být na zaplnění disku patrné.

Totéž jsem pozoroval na několika souborových systémech. (Teď je řeč o souborovém systému na samotném disku, nikoliv v tom loopback souboru.) Pod Linuxem jsem obrovský soubor vytvářel na EXT3 a Reiser4. V případě Solarisu šlo o ZFS. Nově vytvářený soubor směl být klidně (mnohem) větší než zbývající místo na disku...

Otázka je, zda se jedná pouze o línou alokaci bloků, nebo zda je v tom něco ještě chytřejšího. Kdybych například načetl obrovský soubor z /dev/urandom a následně ho přepsal nulami, zabíral by pořád stejné místo? Předpokládám, že ano, protože v kernelu asi nesedí nikdo, kdo by kontroloval, co chce psát write(), a dealokoval nulové bloky. Nicméně i samotná líná alokace bloků mi připadá jako dost pozoruhodný jev.

Mnozí o tomhle nejspíš už dávno vědí a teď si klepou na čelo. Google o tom asi ví ještě víc. Ale nemůžu si pomoct, něco takového mě fakt překvapilo a chvliku jsem nad tím žasnul jako malý kluk. Tak jsem to zapsal do blogu.

       

Komentáře

[pht]

Jmenuje se to "sparse files" neboli děravé soubory. Nejde o to, že v něm jsou nuly, ale díry, které vzniknou tím, že se seekujete kdovíkam a tam něco zapíšete. Takové díry pak při čtení vrací nuly a nezabírají žádné místo. Podobného efektu lze dosáhnout s obyčejnou utilitou dd. Obvykle se používají děravé soubory právě na to, abychom vytvořili nějaký "velký" image pro disk, který bude zabírat místo na disku až ve chvíli, kdy se do něj něco napíše. Na děravé soubory musíte většinu utilit předem upozornit (cp, tar, apod.), jinak z té díry udělají opravdový blok nul. Díry patří ke standardním záležitostem v souborových systémech a umí je i NTFS (FAT ne).

[CEST]

Jen bych doplnil, takovy sparse file se tim dd da vytvorit napr. dd if=/dev/zero of=sparse bs=1 count=0 seek=2G. Vysledny soubor je podle ls 2GB veliky, nicmene pozor na to! utilitky df a dd pracujou se skutecnou velikosti, cili du ukaze velikost 0B a pri vypisu df mate porad stejne zabranyho a volnyho mista na disku. A rozhodne bych nerekl, ze se s takovym souborem pracuje stejne jako se souborem upravdu zaplnenym 2GB dat.

Dalsi vec je, a nekdy to muze byt dost velka nevyhoda, ze XEN neumi pracovat s takovymhle souborem jako image diskem (aspon teda XEN 3.1 tusim, kterej bezi na debianu etch, mozna to uz v novym xenu vylepsili). Napr. u VMware si clovek muze vybrat, jestli se ma disk rovnou alokovat nebo postupne vytvaret. Na jednu stranu muze byt pouzivani zvetsujicich se diskimage dobra, pak ale clovek zjisti, ze to muze prines dost velke problemy, pokud neprozirave vytvoril spoustu virtualnich masin s celkovou kapacitou disku vetsi nez je volne misto (ono je super na disku s 50GB vytvorit 5 VM stroju s diskama 100GB:)) a ty masiny pak casem zaplnujou svoje disky.

[pht]

K tomu du:

du -h --apparent-size sparse 
2.0G    sparse

df samozřejmě uvažuje jen zaplněné bloky na disku.

[CEST]

Vida, tuhle volbu jsem neznal.

[joe]

"cili du ukaze velikost 0B a pri vypisu df mate porad stejne"

no a? :) to je snad jasne...

[CEST]

Jasne to mozna je, problem ale nastava, kdyz pak clovek na to zapomene a s tema souborama pracuje a postupne je zaplnuje. Podobne jako u disku vmware hrozi riziko, ze si clovek udelat na 10GB volnyho mista 50 souboru o velikosti 2GB, ze je bude postupne zaplnovat. Ono to k tomu svadi, kdyz to jde. No a pak v jednu chvili dojde misto.

[Michal Kubeček]

VMware umožňuje nechat soubor s virtuálním diskem vytvořit rovnou v plné velikosti.

[Nikola Ciprich]

do seznamu nevyhod bych snad jeste doplnil ze postupne zapisovani do souboru vetsinou zvysuje fragmentaci...

[mkoubik]

Obecně české překlady trechnických pojmů nemám rád, ale tuším, že "sprase files" jsem někde viděl přeloženo jako "řídké soubory", což IMHO líp vystihuje podstatu.

[kotyz]

Jo, taky to znam jako ridky soubory.

[pht]

To je asi totéž... spodky můžou taky být děravý nebo řídký.

[moira]

Je videt, ze jsi necetl http://tldp.org ;)

[Andrej]

To fakt ne, vždyť je to strašná nuda.

No, ale teď vážně, z TLDP jsem se kdysi učil například konfiguraci DNS. Nicméně mám pocit, že o velké spoustě důležitých záležitostí (LVM2, VPN, iptables, ...) tam jsou často hodně staré a neaktuální články. V mnoha případech (konfigurace multi-user VNC serveru s display mangerem) mi víc pomohlo howto z fóra Ubuntu, přestože tuto distribuci nepoužívám.

Kromě toho, teď už vím, že Solaris (resp. ZFS) má taky sparse files. To na TLDP určitě nepíšou.

(Škoda, že se (už zase) nemůžu naSSHčkovat na školní Mac OS X, že už nemám virtuální stroj s FreeBSD a že SGI Octane s IRIXem už v škole zrušili... Moc rád bych si zaexperimentoval i tam.)

[Abraxis]

Proc to delat jednoduse, kdyz to jde slozite - co takhle pouzit obycejne dd?

dd if=/dev/zero of=16GB bs=1K count=1 seek=16777215

Jinak pokud te zajima skutecne vyuzite misto, tak pouzij:

du 16GB

[^([0-9a-fA-F]{2}([:-]?|$)){6}$]

Ale no tak, autor si procvicil programovani na ruznych platformach a treba se neco noveho i naucil...

[Andrej]

Jenže pak bych nevěděl, jak přesně to funguje.

Teprve teď chápu, že jde o sparse files. Já jsem si vždycky myslel, že sparse files se musí (zaprvé) v souborovém systému explicitně zapnout a (zadruhé) nějak ovládat přes ioctl(), podobně jako zařízení. Teprve teď si uvědomuju, jak jsem se mýlil. Sparse files můžou vznikat tak nějak implicitně, bez velkého úsilí.

[Andrej]

Protože dd není obyčejné. Je to velký kus kódu, ze kterého se dá těžko vytušit, co přesně dělá. Přesněji, nechce se mi to číst. Na GNU to má skoro 2000 řádků. Na Solarisu rovněžtak.

[joe]

Ten kod vypada zajimave :) Jak dlouho programujes?

[Andrej]

No, na VŠ už jsem pátým rokem, takže nějakou dobu jo. Je ten kód zajímavý v negativním nebo pozitivním slova smyslu?

[alblaho]

V negativním. Ta makra jsou zbytečná a nepřehledná.

Nehledě k tomu, že jsi objevoval kolo, ale aspoň ses něco naučil.

[Andrej]

Údajná zbytečnost nebo nepřehlednost maker je čistě věc názoru. Podle mého názoru se v tomto případě hodí víc než dobře. V podstatě jsem se nikoho neprosil, aby hodnotil nástřel, fragment kódu, který prostě není součástí žádného projektu a byl vytvořen vcelku rychle, jen za účelem nějakého experimentu.

Že jsem se něco naučil, o tom není sporu. UNIXové API může člověk používat hodně dlouho a stejně ho tu a tam nějaký detail překvapí.

[alblaho]

Ok, uznávám, že hodnotit tento kousek kódu je bezpředmětné. Svůj účel ten program plní, to je pravda.

K makrům obecně: měla by se používat jen tam, kde se to bez nich neobejde. Tam kde nahrazují volání obyčejné funkce vede jejich použití na méně přehledný kód plný záludností, znemožníš tím překladači typovou kontrolu a já nevím co ještě. Dřív se taková makra používala kvůli výkonu (odpadne režie volání funkce), ale to není tento případ a navíc už i plain C dnes umí "inline".

[Jardík]

Proč off64_t? Když definuješ _LARGEFILE64_SOURCE a _FILE_OFFSET_BITS=64 při překladu, tak bude off_t mít 8B. Ve FreeBSD tuším off64_t kdysi nebývalo (je tam teď?) a nemohl jsem tam kvůli tomu přeložit svou utilitku.

[Andrej]

Ano, je to v podstatě pravda:

       O_LARGEFILE
              (LFS)  Allow  files  whose  sizes cannot be represented in an off_t (but can be represented in an
              off64_t) to be opened.  The _LARGEFILE64_SOURCE macro must be defined in  order  to  obtain  this
              definition.   Setting  the _FILE_OFFSET_BITS feature test macro to 64 (rather than using O_LARGE‐
              FILE) is the preferred method of obtaining method of accessing large files on 32-bit systems (see
              feature_test_macros(7)).

Bez _FILE_OFFSET_BITS dává

printf( "%d %d\n", sizeof( off_t ), sizeof( off64_t ) );

tohle:

4 8

Nicméně manuálová stránka rozhodně netvrdí, že by snad použití off64_t bylo nějak špatné, nestandardní nebo nepřenositelné. Je to prostě jedna z možností. Umožňuje u každého otvíraného souboru zvlášť určit, jestli bude mít 64-bitové offsety nebo ne. To ale asi nepřinese ani praktické výhody, ani zlepšení efektivity. Příště možná zkusím _FILE_OFFSET_BITS.

[Grunt]

Podle nadpisu to vypadalo, jako by měla být řeč o GCC.

[Andrej]

No, já většinou používám icc.

[Grunt]

 A, tady očividně někdo neví o čem je řeč:

MINGW32:
$ cd /usr/src/gcc
$ make
…
./genmodes.exe -h > tmp-modes.h
/bin/sh ../../gcc-3.4.2-20040916-1/gcc/move-if-change tmp-modes.h insn-modes.h
insn-modes.h is unchanged
./genmodes.exe -m > tmp-min-modes.c
/bin/sh ../../gcc-3.4.2-20040916-1/gcc/move-if-change tmp-min-modes.c min-insn-m
odes.c
./genmodes.exe > tmp-modes.c
make[1]: *** [s-modes] Interrupt
make: *** [all-gcc] Interrupt

tmp-modes.c:
0000000: 2f2a 2047 656e 6572 6174 6564 2061 7574  /* Generated aut
0000010: 6f6d 6174 6963 616c 6c79 2066 726f 6d20  omatically from
0000020: 6d61 6368 6d6f 6465 2e64 6566 2061 6e64  machmode.def and
0000030: 2063 6f6e 6669 672f 6933 3836 2f69 3338   config/i386/i38
0000040: 362d 6d6f 6465 732e 6465 660d 0a20 2020  6-modes.def..
0000050: 6279 2067 656e 6d6f 6465 732e 2020 2a2f  by genmodes.  */
0000060: 0d0a 0d0a 2369 6e63 6c75 6465 2022 636f  ....#include "co
0000070: 6e66 6967 2e68 220d 0a23 696e 636c 7564  nfig.h"..#includ
0000080: 6520 2273 7973 7465 6d2e 6822 0d0a 2369  e "system.h"..#i
0000090: 6e63 6c75 6465 2022 636f 7265 7479 7065  nclude "coretype
00000a0: 732e 6822 0d0a 2369 6e63 6c75 6465 2022  s.h"..#include "
00000b0: 746d 2e68 220d 0a23 696e 636c 7564 6520  tm.h"..#include
00000c0: 226d 6163 686d 6f64 652e 6822 0d0a 2369  "machmode.h"..#i
00000d0: 6e63 6c75 6465 2022 7265 616c 2e68 220d  nclude "real.h".
00000e0: 0a0d 0a63 6f6e 7374 2063 6861 7220 2a63  ...const char *c
00000f0: 6f6e 7374 206d 6f64 655f 6e61 6d65 5b4e  onst mode_name[N
0000100: 554d 5f4d 4143 4849 4e45 5f4d 4f44 4553  UM_MACHINE_MODES
0000110: 5d20 3d0d 0a7b 0d0a 2020 2256 4f49 4422  ] =..{..  "VOID"
0000120: 2c0d 0a20 2022 424c 4b22 2c0d 0a20 2022  ,..  "BLK",..  "
0000130: 4343 222c 0d0a 2020 2243 4347 4322 2c0d  CC",..  "CCGC",.
0000140: 0a20 2022 4343 474f 4322 2c0d 0a20 2022  .  "CCGOC",..  "
0000150: 4343 4e4f 222c 0d0a 2020 2243 435a 222c  CCNO",..  "CCZ",
0000160: 0d0a 2020 2243 4346 5022 2c0d 0a20 2022  ..  "CCFP",..  "
0000170: 4343 4650 5522 2c0d 0a20 2022 4249 222c  CCFPU",..  "BI",
0000180: 0d0a 2020 2251 4922 2c0d 0a20 2022 4849  ..  "QI",..  "HI
0000190: 222c 0d0a 2020 2253 4922 2c0d 0a20 2022  ",..  "SI",..  "
00001a0: 4449 222c 0d0a 2020 2254 4922 2c0d 0a20  DI",..  "TI",..
00001b0: 2022 5346 222c 0d0a 2020 2244 4622 2c0d   "SF",..  "DF",.
00001c0: 0a20 2022 5846 222c 0d0a 2020 2254 4622  .  "XF",..  "TF"
00001d0: 2c0d 0a20 2022 4351 4922 2c0d 0a20 2022  ,..  "CQI",..  "
00001e0: 4348 4922 2c0d 0a20 2022 4353 4922 2c0d  CHI",..  "CSI",.
00001f0: 0a20 2022 4344 4922 2c0d 0a20 2022 4354  .  "CDI",..  "CT
0000200: 4922 2c0d 0a20 2022 5343 222c 0d0a 2020  I",..  "SC",..
0000210: 2244 4322 2c0d 0a20 2022 5843 222c 0d0a  "DC",..  "XC",..
0000220: 2020 2254 4322 2c0d 0a20 2022 5632 5149    "TC",..  "V2QI
0000230: 222c 0d0a 2020 2256 3451 4922 2c0d 0a20  ",..  "V4QI",..
0000240: 2022 5632 4849 222c 0d0a 2020 2256 3851   "V2HI",..  "V8Q
0000250: 4922 2c0d 0a20 2022 5634 4849 222c 0d0a  I",..  "V4HI",..
0000260: 2020 2256 3253 4922 2c0d 0a20 2022 5631    "V2SI",..  "V1
0000270: 4449 222c 0d0a 2020 2256 3136 5149 222c  DI",..  "V16QI",
0000280: 0d0a 2020 2256 3848 4922 2c0d 0a20 2022  ..  "V8HI",..  "
0000290: 5634 5349 222c 0d0a 2020 2256 3244 4922  V4SI",..  "V2DI"
00002a0: 2c0d 0a20 2022 5638 5349 222c 0d0a 2020  ,..  "V8SI",..
00002b0: 2256 3444 4922 2c0d 0a20 2022 5638 4449  "V4DI",..  "V8DI
00002c0: 222c 0d0a 2020 2256 3253 4622 2c0d 0a20  ",..  "V2SF",..
00002d0: 2022 5634 5346 222c 0d0a 2020 2256 3244   "V4SF",..  "V2D
00002e0: 4622 2c0d 0a20 2022 5638 5346 222c 0d0a  F",..  "V8SF",..
00002f0: 2020 2256 3444 4622 2c0d 0a20 2022 5631    "V4DF",..  "V1
0000300: 3653 4622 2c0d 0a20 2022 5638 4446 222c  6SF",..  "V8DF",
0000310: 0d0a 7d3b 0d0a 0d0a 636f 6e73 7420 756e  ..};....const un
0000320: 7369 676e 6564 2063 6861 7220 6d6f 6465  signed char mode
0000330: 5f63 6c61 7373 5b4e 554d 5f4d 4143 4849  _class[NUM_MACHI
0000340: 4e45 5f4d 4f44 4553 5d20 3d0d 0a7b 0d0a  NE_MODES] =..{..
0000350: 2020 4d4f 4445 5f52 414e 444f 4d2c 2020    MODE_RANDOM,
0000360: 2020 2020 2020 2020 2020 2020 2020 2020
0000370: 2020 2020 2020 2020 2020 2020 2020 2020
0000380: 2020 2020 2020 2020 2020 2020 2020 2020
0000390: 2020 2020 2020 2020 2020 2020 2020 2020
…
413482115: 2020 2020 2020 2020 2020 2020 2020 2020

Samozřejmě se to zastaví až to spotřebuje veškeré místo na disku.

[YYY]

Proc na to psat takoveto harakiri? Nebylo by lepsi vystacit si s pouzitim klasickeho dd?

[Andrej]

Ne, to by rozhodně nebylo lepší. Pak ať mi někdo vykládá o harakiri!

[Dundee5]

Stejně to funguje i s alokací operační paměti. Příkazem malloc si můžeš zabrat téměř cokoliv, kernel tě nijak omezovat nebude (pokud se vejdeš do velikost integeru). Fyzické stránky se ale začnou zabírat až když začneš do té paměti opravdu něco zapisovat.

[Andrej]

Tohle je mnohem méně překvapivé než sparse files. Chová se tak spousta programů, třeba JVM, a v ps nebo top je to hned vidět.

Jak už jsem psal výše, myslel jsem si, že sparse files se musí napřed nějak explicitně zapnout a že se ovládají přes ioctl(). Netušil jsem, že vznikají pouhým seekováním za konec (a následným zápisem). Proto mi to celé přišlo neobvyklé.

[pht]

Memory overcommit v jádře linuxu je něco trochu jiného. To bych spíš přirovnal k té líné alokaci. Důvody jsou totiž lepší využití paměti, navíc to lze vypnout.

Alokace pomocí malloc nijak neinteraguje s jádrem, to dělá až následný syscall brk nebo mmap.