abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 17:11 | Pozvánky

Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 170. brněnský sraz, který proběhne v pátek 15. listopadu od 18:00 v restauraci Vegalité (Slovákova 10).

Ladislav Hagara | Komentářů: 0
dnes 11:55 | Nová verze

Po půl roce vývoje od vydání verze 5.2 byla vydána nová verze 5.3 svobodného open source redakčního systému WordPress. Kódové označení Kirk bylo vybráno na počest amerického jazzového multiinstrumentalisty Rahsaana Rolanda Kirka.

Ladislav Hagara | Komentářů: 6
včera 22:44 | Nová verze

Intel dnes zveřejnil hned 18 upozornění na bezpečnostní chyby ve svých produktech. Řada z nich se týká procesorů. V upstream Linuxu se již objevují příslušné patche: TAA - TSX Asynchronous Abort (CVE-2019-11135), iTLB multihit (CVE-2018-12207), … K dispozici je také nová verze 20191112 mikrokódů.

Ladislav Hagara | Komentářů: 20
včera 19:00 | IT novinky

Příspěvek na blogu Mozilla Hacks představuje alianci s názvem Bytecode Alliance založenou společnostmi Mozilla, Fastly, Intel a Red Hat. Cílem aliance je dostat aplikace ve WebAssembly i mimo webový prohlížeč.

Ladislav Hagara | Komentářů: 2
včera 18:11 | Nová verze

Byla vydána nová major verze 1.4.0 webového poštovního klienta Roundcube (Wikipedie). Podrobný přehled novinek na GitHubu. Roundcube je nově responzivní, tj. podporuje také tablety a chytré telefony, viz náhledy.

Ladislav Hagara | Komentářů: 0
včera 17:11 | Nová verze

Byla vydána nová stabilní verze 18.06.5 linuxové distribuce primárně určené pro routery a vestavěné systémy OpenWrt (Wikipedie). Přehled změn v Changelogu. Jedná se o opravné vydání OpenWrt 18.06.0 vydaného v červenci 2018. Pro zájemce o testování je k dispozici první RC verze OpenWrt 19.07.0.

Ladislav Hagara | Komentářů: 3
včera 16:55 | Nová verze

Byla vydána verze 2.0 svobodné federalizované platformy pro sledování a sdílení videí, alternativy YouTube s podporou P2P, PeerTube (Wikipedie). Přehled novinek v příspěvku na Framablogu. Za vývojem PeerTube stojí nezisková organizace Framasoft snažící se mimo jiné nahradit svými svobodnými Frama službami služby společnosti Google (De-google-ify Internet). Bohužel ale musí některé své služby omezit.

Ladislav Hagara | Komentářů: 2
včera 10:11 | Komunita

Na přelomu října a listopadu proběhla v Lyonu GStreamer Conference 2019, tj. konference vývojářů multimediálního frameworku GStreamer. Videozáznamy přednášek byly zveřejněny na portálu UbiCast.

Ladislav Hagara | Komentářů: 0
11.11. 13:33 | Zajímavý článek

Christian Ude, bývalý dlouholetý starosta Mnichova, v rozhovoru pro německý Linux Magazin vzpomíná na projekt LiMux, kdy město přešlo na vlastní linuxovou infrastrukturu a OpenOffice.org (posléze LibreOffice), ale příští vládnoucí koalice se rozhodla vrátit se k produktům Microsoftu.

Fluttershy, yay! | Komentářů: 86
11.11. 13:22 | Komunita

Uživatelé Linuxu ve VirtualBoxu obvykle instalují Přídavky pro hosta (Guest Additions) pro lepší podporu emulovaného hardwaru. Brzy už ale nebudou přídavky potřebné. Ovladač vboxguest se dostal již do Linuxu 4.16 v dubnu loňského roku. Včera vydal Linus Torvalds Linux 5.4-rc7 (LKML). Přidán byl ovladač vboxsf (VirtualBox Shared Folder) pro sdílené složky.

Ladislav Hagara | Komentářů: 3
Jaké hodinky nosíte (nejčastěji)?
 (25%)
 (7%)
 (14%)
 (54%)
Celkem 122 hlasů
 Komentářů: 5, poslední dnes 13:28
Rozcestník

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

2.5.2009 07:58 | Přečteno: 2417× | 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.

       

Hodnocení: 53 %

        špatnédobré        

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

Komentáře

Vložit další komentář

2.5.2009 08:33 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Je libo 16 GB nul? Jistě, hned to bude...
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).
In Ada the typical infinite loop would normally be terminated by detonation.
2.5.2009 09:24 CEST
Rozbalit Rozbalit vše Re: Je libo 16 GB nul? Jistě, hned to bude...

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.

2.5.2009 09:39 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Je libo 16 GB nul? Jistě, hned to bude...
K tomu du:
du -h --apparent-size sparse 
2.0G    sparse
df samozřejmě uvažuje jen zaplněné bloky na disku.

In Ada the typical infinite loop would normally be terminated by detonation.
2.5.2009 10:23 CEST
Rozbalit Rozbalit vše Re: Je libo 16 GB nul? Jistě, hned to bude...

Vida, tuhle volbu jsem neznal.

2.5.2009 15:37 joe
Rozbalit Rozbalit vše Re: Je libo 16 GB nul? Jistě, hned to bude...
"cili du ukaze velikost 0B a pri vypisu df mate porad stejne"

no a? :) to je snad jasne...
2.5.2009 19:49 CEST
Rozbalit Rozbalit vše Re: Je libo 16 GB nul? Jistě, hned to bude...

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.

4.5.2009 13:46 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Je libo 16 GB nul? Jistě, hned to bude...
VMware umožňuje nechat soubor s virtuálním diskem vytvořit rovnou v plné velikosti.
Nikola Ciprich avatar 3.5.2009 12:46 Nikola Ciprich | skóre: 23 | blog: NiX_blog | Palkovice
Rozbalit Rozbalit vše Re: Je libo 16 GB nul? Jistě, hned to bude...
do seznamu nevyhod bych snad jeste doplnil ze postupne zapisovani do souboru vetsinou zvysuje fragmentaci...
Did you ever touch the starlight ? Dream for a thousand years? Have you ever seen the beauty Of a newborn century?
mkoubik avatar 3.5.2009 20:21 mkoubik | skóre: 5 | blog: lorem_ipsum | Praha 8 - Bohnice
Rozbalit Rozbalit vše Re: Je libo 16 GB nul? Jistě, hned to bude...
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 avatar 3.5.2009 20:41 kotyz | skóre: 25 | blog: kotyzblog | Radnice
Rozbalit Rozbalit vše Re: Je libo 16 GB nul? Jistě, hned to bude...
Jo, taky to znam jako ridky soubory.
Mul-ti-pass! | Hrdý člen KERNEL ULTRAS. | Furry/Brony/Otaku | Nemám čas ztrácet čas. | In 'pacman -Syu' we trust!
4.5.2009 08:31 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Je libo 16 GB nul? Jistě, hned to bude...
To je asi totéž... spodky můžou taky být děravý nebo řídký.
In Ada the typical infinite loop would normally be terminated by detonation.
2.5.2009 11:18 moira | skóre: 30 | blog: nesmysly
Rozbalit Rozbalit vše Re: Je libo 16 GB nul? Jistě, hned to bude...
Je videt, ze jsi necetl http://tldp.org ;)
Překladač ti nikdy neřekne: "budeme kamarádi"
2.5.2009 16:16 Andrej | skóre: 47 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: Je libo 16 GB nul? Jistě, hned to bude...

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

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.)

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
2.5.2009 11:40 Abraxis
Rozbalit Rozbalit vše Re: Je libo 16 GB nul? Jistě, hned to bude...

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

2.5.2009 13:18 ^([0-9a-fA-F]{2}([:-]?|$)){6}$
Rozbalit Rozbalit vše Re: Je libo 16 GB nul? Jistě, hned to bude...
Ale no tak, autor si procvicil programovani na ruznych platformach a treba se neco noveho i naucil...
2.5.2009 16:05 Andrej | skóre: 47 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: Je libo 16 GB nul? Jistě, hned to bude...

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í.

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
2.5.2009 16:26 Andrej | skóre: 47 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: Je libo 16 GB nul? Jistě, hned to bude...

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.

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
2.5.2009 15:41 joe
Rozbalit Rozbalit vše Re: Je libo 16 GB nul? Jistě, hned to bude...
Ten kod vypada zajimave :) Jak dlouho programujes?
2.5.2009 16:01 Andrej | skóre: 47 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: Je libo 16 GB nul? Jistě, hned to bude...

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 avatar 2.5.2009 19:48 alblaho | skóre: 17 | blog: alblog
Rozbalit Rozbalit vše Re: Je libo 16 GB nul? Jistě, hned to bude...
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:-).
2.5.2009 23:06 Andrej | skóre: 47 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: Je libo 16 GB nul? Jistě, hned to bude...

Ú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 avatar 2.5.2009 23:20 alblaho | skóre: 17 | blog: alblog
Rozbalit Rozbalit vše Re: Je libo 16 GB nul? Jistě, hned to bude...
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 avatar 2.5.2009 16:18 Jardík | skóre: 40 | blog: jarda_bloguje
Rozbalit Rozbalit vše Re: Je libo 16 GB nul? Jistě, hned to bude...
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.
Věřím v jednoho Boha.
2.5.2009 16:41 Andrej | skóre: 47 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: Je libo 16 GB nul? Jistě, hned to bude...

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 avatar 2.5.2009 22:08 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Je libo 16 GB nul? Jistě, hned to bude...

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

Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
2.5.2009 23:13 Andrej | skóre: 47 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: Je libo 16 GB nul? Jistě, hned to bude...

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

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
Grunt avatar 3.5.2009 17:16 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Je libo 16 GB nul? Jistě, hned to bude...

 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.

Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
3.5.2009 13:01 maertien | skóre: 29 | blog: martinek
Rozbalit Rozbalit vše Re: Je libo 16 GB nul? Jistě, hned to bude...
Proc na to psat takoveto harakiri? Nebylo by lepsi vystacit si s pouzitim klasickeho dd?
4.5.2009 01:25 Andrej | skóre: 47 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: Je libo 16 GB nul? Jistě, hned to bude...

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

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
3.5.2009 23:05 Dundee5 | skóre: 17 | blog: Dundee5 | Praha
Rozbalit Rozbalit vše Re: Je libo 16 GB nul? Jistě, hned to bude...
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.
Kdo se vzdá svobody, aby získal jistotu, ztratí nakonec obojí. --Benjamin Franklin
4.5.2009 01:33 Andrej | skóre: 47 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: Je libo 16 GB nul? Jistě, hned to bude...

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é.

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
4.5.2009 08:42 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Je libo 16 GB nul? Jistě, hned to bude...
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.
In Ada the typical infinite loop would normally be terminated by detonation.

Založit nové vláknoNahoru

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.