CentOS - Jun 2009 - Question about dd (fill a hard disks' unused space with blanks)

Hi,

I'm currently experimenting with G4U (Ghost for Unix), a small cloning 
application sending disk images to an FTP server.

The application reads the whole disk bit by bit, compresses it and then 
stores it remotely. Due to this approach, it's more or less 
filesystem-independent. The drawback is that it sometimes results in 
huge image files.

Now I'm currently following a hint which suggests to fill the disks' 
unused space with zero bits. Here's the command for that:

# dd if=/dev/zero of=/0bits bs=20M
# rm /0bits

Now I gave that a shot, but after half an hour or so, I got a bit 
impatient. Now the computer does not respond any more. Does that mean 
he's just way too busy with dd? Or is there some mistake in the command? 
As I see it, it will just be chugging on and on, no? Shouldn't there be 
a 'count=x' option somewhere?

Niki

Am 07.06.2009 um 18:22 schrieb Niki Kovacs:
> Hi,
>
> I'm currently experimenting with G4U (Ghost for Unix), a small cloning
> application sending disk images to an FTP server.
>
> The application reads the whole disk bit by bit, compresses it and  
> then
> stores it remotely. Due to this approach, it's more or less
> filesystem-independent. The drawback is that it sometimes results in
> huge image files.
>
> Now I'm currently following a hint which suggests to fill the
disks'
> unused space with zero bits. Here's the command for that:
>
> # dd if=/dev/zero of=/0bits bs=20M
> # rm /0bits


This will create a file that fills up the root-partition.
If you have multiple partitions beyond that, it's not of much use.
Ideally, the zero'ing of the disk should take place before the OS is  
installed, via a boot-cd and using dd with the disk-device itself

All this made some sense when disks didn't come in sizes of 250GB  
upwards...
If you get 20MB/s from your dd(1), it would take 1000 seconds to fill  
20 GB...





Rainer

Niki Kovacs wrote:
> Hi,
> 
> I'm currently experimenting with G4U (Ghost for Unix), a small cloning 
> application sending disk images to an FTP server.
> 
> The application reads the whole disk bit by bit, compresses it and then 
> stores it remotely. Due to this approach, it's more or less 
> filesystem-independent. The drawback is that it sometimes results in 
> huge image files.
> 
> Now I'm currently following a hint which suggests to fill the
disks'
> unused space with zero bits. Here's the command for that:
> 
> # dd if=/dev/zero of=/0bits bs=20M
> # rm /0bits
> 
> Now I gave that a shot, but after half an hour or so, I got a bit 
> impatient. Now the computer does not respond any more. Does that mean 
> he's just way too busy with dd? Or is there some mistake in the
command?
> As I see it, it will just be chugging on and on, no? Shouldn't there be
> a 'count=x' option somewhere?
I'll second the recommendation for clonezilla.  It knows enough about 
most filesystems (including windows ntfs) to only store the used blocks 
and it can use network storage over nfs, smb, or sshfs if you use the 
bootable CD clonezilla-live version.   If you do a lot of cloning, you 
can also use the network-booting drbl version on a server that will PXE 
boot a client into clonezilla with the image storage directory already 
NFS-mounted.  There is an rpm for Centos to install this.

-- 
   Les Mikesell
    lesmikesell at gmail.com