On Tue, Apr 20, 2010 at 02:56:11PM -0400, Daniel Barowy wrote: > > The problem is that we're copying the entire disk, so, as far as the > disk (i.e., SSDs) is aware, that disk is 100% full-- all blocks are > marked as used even if they're empty. If I understand correctly, > how the controller handles block reallocation in this scenario > depends how it is implemented in the disk's firmware, with some > being better than others. At present, we have Intel X25-E disks.
Err, just how frequently are you doing this? The answer is going to change a bit if you're doing this infrequently vs. doing this as a part of manufacturing turn key boxes. I am going to assume the former, not the latter. If you don't want as many blocks to appear as used, write to fewer blocks. IE partition it, slice it, mkfs it, and restore from a tarball. You can even put your gzipped tarball of the base system where the installer expects to find base##.tgz and tell it to only install your tarball. > > So, if the above is correct, then I will need to either rethink our > deployment strategy (like, always leave some spae on the disk, > untouched by dd), or else try not to write so often (like, using a > ramdisk). I could also be overestimating the importance of all of > this. Just rethink your deployment strategy to not use 'dd'. Even Windows cloning systems stopped trying to copy all bits on the disk 6+ years ago. 'dd' made some sense when the disk was mostly full and there was a huge penalty to keep seeking between data and metadata. 'dd' continues to make sense if you need to make a copy of everything before attempting to recover data or metadata. -- Chris Dukes
