dump/restore

[Root Boy Jim]

   From: Guy Harris <guy at auspex.uucp>

   Furthermore (although this isn't as likely to be a problem), neither
   "cpio" nor "tar" know about files with "holes" - they just read the file
   and, if they hit a hole, the file system code dutifully gives them a
   block full of zeroes, which as far as they're concerned is a disk block
   full of zeroes.

Which doesn't bother me too much that the zeros are written on tape; after
all, people have more tape than disk. And to change it would require
storing the disk block addresses, most likely increasing the dump size
for most normal dumps, which contain no real or potential holes.

   This means that if you use "cpio" or "tar" to dump and restore a file
   system containing files with holes, you may again fild that the backup
   won't fit, because those holes will get assigned blocks when you restore
   the dump....

But disk is another matter again. Isn't it about time the kernel created
holes via writing as well as seeking? I can see possible performance
problems with all those `looking for zero' scanning loops; perhaps a
flag to open(2), O_HOLY could announce the user's intention to create
such files. Alternatively, restore could do it for all files, but this
would require knowing the block and fragment size of the filesystem.

I suspect that none of this has been done because holy files are
relatively rare, and the savings wouldn't really be that great.

	(Root Boy) Jim Cottrell	(301) 975-5688
	<rbj at nav.icst.nbs.gov> or <rbj at icst-cmr.arpa>
	Careful with that VAX Eugene!