compressed HDD image using dd...clearing unused blocks
Paul Schenkeveld
fb-chat at psconsult.nl
Sat Jul 14 01:01:47 UTC 2007
On Fri, Jul 13, 2007 at 02:02:55PM +0200, Oliver Fromme wrote:
> Paul Schenkeveld wrote:
> > Michael Eubanks wrote:
> > Paul Schenkeveld wrote:
> > > > What about:
> > > >
> > > > # dd < /dev/zero > BIG_EMPTY_FILE bs=128k
> > > > # rm BIG_EMPTY_FILE
> > > >
> > > > Comes close to what you want, only a couple of
> > > > indirect blocks are
> > > > not zeroed this way but the majority of unused
> > > > blocks will be.
> > >
> > > ...snip...
> > > [...]
> >
> > The bs=128k is just for speed. Dd will write an incomplete block at the
> > end of the file to fill up just whatever space you need. If you fear
> > system instability, run this in single user mode.
> >
> > Oh, do a sync and wait a while between the dd and the rm to allow the
> > kernel some time to flush out blocks to disk, otherwise you've only
> > efficiently zeroed out the buffer cache :-)
>
> Are you sure? ISTR once I wrote a big file to a floppy
> which didn't fit. I got an error message and removed
> the incomplete file, but the floppy drive continued to
> write the blocks from the cache.
>
> I think the buffer cache works on block level, not on
> file level, so the syncing and waiting shouldn't be
> necessary. The zeroed data blocks schould still be
> written to disk, even after the directory entry has
> been unlinked.
If I understand softupdates correctly then the rm prevents further
flushing of data blocks from the buffercache to the disk. Somewhere in
the original softupdates docs I read that softupdates are ideal for
/tmp filesystems as many temporary files will never make it to the
physical disk during large builds like make world.
> Besides, the buffer cache is certainly _much_ smaller
> than the hard disk in question, so the majority of
> blocks has already been zeroed on disk when the dd
> command finishes.
But on a machine with lots of RAM, say 4GB, the blocks that haven't
made it to the disk can still make your dd image unnecessarily huge,
on a pristine system even a couple of times lager than necessary.
> Best regards
> Oliver
-- Paul Schenkeveld
More information about the freebsd-chat
mailing list