A message from our CEO about the future of Stack Overflow and Stack Exchange. Read now.
4 added 626 characters in body
source | link

The easiest way to do this is to create your backing file as a sparse file; that is, make it 1GB with truncate -s 1G disk.img instead of dd if=/dev/zero bs=1048576 count=1024 of=disk.img (or whatever). Nicely, truncate is also far faster.

If you do an ls -l on the file, it'll show as 1GB—but that's only its apparent size. du disk.img will give the actual size.

(Note—you'll need to have your image on a filesystem that supports sparse files. All the common Unix ones do. Ext2/3/4 all do. FAT32 does not. HFS+ doesn't, either.)

NOTE: Sparse files still are, logically, the full size. Just the never-written sections aren't physically stored on disk. For the most part, the not-actually-stored part is hidden from programs. A few utilities have support for it, though. (E.g., dd conv=sparse, cp --sparse=auto/always, etc.). An actual USB stick can't be sparse. And if you use dd conv=sparse to write it, it'll probably be much faster, but you'll leave whatever data was there before, instead of the blocks full of NULs (0x00) expected. Should work fine (as its free space), but will leave old data on the USB stick—possibly a security concern.

The easiest way to do this is to create your backing file as a sparse file; that is, make it 1GB with truncate -s 1G disk.img instead of dd if=/dev/zero bs=1048576 count=1024 of=disk.img (or whatever). Nicely, truncate is also far faster.

If you do an ls -l on the file, it'll show as 1GB—but that's only its apparent size. du disk.img will give the actual size.

(Note—you'll need to have your image on a filesystem that supports sparse files. All the common Unix ones do. Ext2/3/4 all do. FAT32 does not. HFS+ doesn't, either.)

The easiest way to do this is to create your backing file as a sparse file; that is, make it 1GB with truncate -s 1G disk.img instead of dd if=/dev/zero bs=1048576 count=1024 of=disk.img (or whatever). Nicely, truncate is also far faster.

If you do an ls -l on the file, it'll show as 1GB—but that's only its apparent size. du disk.img will give the actual size.

(Note—you'll need to have your image on a filesystem that supports sparse files. All the common Unix ones do. Ext2/3/4 all do. FAT32 does not. HFS+ doesn't, either.)

NOTE: Sparse files still are, logically, the full size. Just the never-written sections aren't physically stored on disk. For the most part, the not-actually-stored part is hidden from programs. A few utilities have support for it, though. (E.g., dd conv=sparse, cp --sparse=auto/always, etc.). An actual USB stick can't be sparse. And if you use dd conv=sparse to write it, it'll probably be much faster, but you'll leave whatever data was there before, instead of the blocks full of NULs (0x00) expected. Should work fine (as its free space), but will leave old data on the USB stick—possibly a security concern.

3 edited body
source | link

The easiest way to do this is to create your backing file as a sparse file; that is, make it 1GB with truncate -s 1G disk.img instead of dd if=/dev/nullzero bs=1048576 count=1024 of=disk.img (or whatever). Nicely, truncate is also far faster.

If you do an ls -l on the file, it'll show as 1GB—but that's only its apparent size. du disk.img will give the actual size.

(Note—you'll need to have your image on a filesystem that supports sparse files. All the common Unix ones do. Ext2/3/4 all do. FAT32 does not. HFS+ doesn't, either.)

The easiest way to do this is to create your backing file as a sparse file; that is, make it 1GB with truncate -s 1G disk.img instead of dd if=/dev/null bs=1048576 count=1024 of=disk.img (or whatever). Nicely, truncate is also far faster.

If you do an ls -l on the file, it'll show as 1GB—but that's only its apparent size. du disk.img will give the actual size.

(Note—you'll need to have your image on a filesystem that supports sparse files. All the common Unix ones do. Ext2/3/4 all do. FAT32 does not. HFS+ doesn't, either.)

The easiest way to do this is to create your backing file as a sparse file; that is, make it 1GB with truncate -s 1G disk.img instead of dd if=/dev/zero bs=1048576 count=1024 of=disk.img (or whatever). Nicely, truncate is also far faster.

If you do an ls -l on the file, it'll show as 1GB—but that's only its apparent size. du disk.img will give the actual size.

(Note—you'll need to have your image on a filesystem that supports sparse files. All the common Unix ones do. Ext2/3/4 all do. FAT32 does not. HFS+ doesn't, either.)

2 added 55 characters in body
source | link

The easiest way to do this is to create your backing file as a sparse file; that is, make it 1GB with truncate -s 1G disk.img instead of dd if=/dev/null bs=1048576 count=1024 of=disk.img (or whatever). Nicely, truncate is also far faster.

If you do an ls -l on the file, it'll show as 1GB—but that's only its apparent size. du disk.img will give the actual size.

(Note—you'll need to have your image on a filesystem that supports sparse files. All the common Unix ones do. Ext2/3/4 all do. FAT32 does not. HFS+ doesn't, either.)

The easiest way to do this is to create your backing file as a sparse file; that is, make it 1GB with truncate -s 1G disk.img instead of dd if=/dev/null bs=1048576 count=1024 of=disk.img (or whatever). Nicely, truncate is also far faster.

If you do an ls -l on the file, it'll show as 1GB—but that's only its apparent size. du disk.img will give the actual size.

(Note—you'll need to have your image on a filesystem that supports sparse files. All the common Unix ones do.)

The easiest way to do this is to create your backing file as a sparse file; that is, make it 1GB with truncate -s 1G disk.img instead of dd if=/dev/null bs=1048576 count=1024 of=disk.img (or whatever). Nicely, truncate is also far faster.

If you do an ls -l on the file, it'll show as 1GB—but that's only its apparent size. du disk.img will give the actual size.

(Note—you'll need to have your image on a filesystem that supports sparse files. All the common Unix ones do. Ext2/3/4 all do. FAT32 does not. HFS+ doesn't, either.)

1
source | link