Terje Fåberg schrieb:

Alexander Veit skrev:

...

Vielleicht geht's ja damit:

dd if=/dev/null of=thefile bs=1M count=1 seek=1023

Das Ergebnis ist durchaus interessant: Die Datei wird erstellt, hat die gewünschte Größe, aber nimmt keinen Platz auf der Platte ein:

phoenix:/home # l total 8 drwxr-xr-x 2 root root 4096 Sep 23 20:02 ./ drwxr-xr-x 19 root root 4096 Dec 30 10:33 ../ phoenix:/home # dd if=/dev/zero of=terje.img bs=1M count=1 seek=1000 1+0 records in 1+0 records out phoenix:/home # l -h total 1.1M drwxr-xr-x 2 root root 4.0K Dec 30 18:17 ./ drwxr-xr-x 19 root root 4.0K Dec 30 10:33 ../ -rw-r--r-- 1 root root 1001M Dec 30 18:17 terje.img phoenix:/home # du -h 1.1M .

Ja, das ist ein sparse file (Datei mit Löchern drin). Geht nicht mit jedem Dateisystem. -- Gruß, Alex

Kristian Köhntopp skrev:

Das nennt man eine dünn besetzte Datei (sparse file). Die Blöcke werden beim Lesen als Blöcke gelesen, die mit Nullbytes gefüllt sind, und belegen beim ersten Schreiben Platz auf der Platte (auch dann, wenn sie als Blöcke mit Nullbytes geschrieben werden).

Das ist ein dokumentiertes und garantiertes Feature von Unix-Dateisystemen (und eines, das beim Backup mächtig Ärger machen kann).

Danke fuer die Erklaerung. Mit "kleinen" Sparse Files funktioniert alles recht gut, so wie ueblich. Wenn ich auf diesen Sparse files ein Datei system anlege, wachsen sie nach und nach. Aber was wuerde geschehen, als meine Sparse files groesser werden wie das Dateisystem das diese enthaelt? Kann das innere Dateisystem darauf sauber reagieren? Da sind mir zu viel offene Fragen, als dass ich dies an- wenden wuerde, glaube ich. Ausserdem: Grosse Sparse files koennen meinen Rechner mit SuSE 9.0 reproduzierbar zu einem Absturz bringen. Ist dies ein Bug, das man an SuSE melden soll? ----snip---- phoenix:/home # dd if=/dev/zero of=terje.img bs=1M count=1 seek=1000000 1+0 records in 1+0 records out phoenix:/home # l -h total 193M drwxr-xr-x 2 root root 4.0K Dec 30 20:31 ./ drwxr-xr-x 19 root root 4.0K Dec 30 10:33 ../ -rw-r--r-- 1 root root 977G Dec 30 20:35 terje.img phoenix:/home # losetup /dev/loop0 terje.img phoenix:/home # mkfs.ext3 /dev/loop0 mke2fs 1.34 (25-Jul-2003) Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) 128008192 inodes, 256000256 blocks 12800012 blocks (5.00%) reserved for the super user First data block=0 7813 block groups 32768 blocks per group, 32768 fragments per group 16384 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 102400000, 214990848 Writing inode tables: 285/7813 ----snip---- Anschließend hilft nurnoch ein Druck auf den Resetknopf. Der Recher bleibt immer haengen, wenn ich ein Dateisystem auf diesem grossen Loop-Device erstelle. Reiserfs, ext2/3, xfs ist egal. Gruss, Terje ______________________________________________________ Få den nye Yahoo! Messenger på http://no.messenger.yahoo.com/ Nye ikoner og bakgrunner, webkamera med superkvalitet og dobbelt så morsom

On Tuesday 30 December 2003 20:52, Terje Fåberg wrote:

Wenn ich auf diesen Sparse files ein Datei system anlege, wachsen sie nach und nach. Aber was wuerde geschehen, als meine Sparse files groesser werden wie das Dateisystem das diese enthaelt?

Bumm. Die genaue Klangfarbe kann ich Dir nicht nennen, aber der loop-Treiber wird dann versuchen Blöcke zu allozieren, die ihm das physikalische Dateisystem nicht mehr geben kann. Das muß knallen.

phoenix:/home # dd if=/dev/zero of=terje.img bs=1M count=1 seek=1000000 1+0 records in 1+0 records out

Das ergibt ein Dateisystem von einer Million Megabytes, also 10E12 Bytes. (1E3 = Kilo, 1E6 = Mega, 1E9 = Giga, 1E12 = Tera). Das ist ein Terabyte-Dateisystem. Wenn das physikalische Dateisystem drunter kleiner ist, kann das nicht funktionieren. Das sollte loop sauber abfangen. Bleibt stattdessen die Kiste stehen, ist das Kernelbug, der auf die Kernelmailingliste und an Suse gemeldet werden sollte, allerdings kein kritischer Fehler. Kristian