Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ames!nrl-cmf!cmcl2!adm!xadmx!rbj@nav.icst.nbs.gov From: rbj@nav.icst.nbs.gov (Root Boy Jim) Newsgroups: comp.unix.questions Subject: dump/restore Message-ID: <17413@adm.BRL.MIL> Date: 2 Nov 88 15:31:00 GMT Sender: news@adm.BRL.MIL Lines: 31 From: Guy Harris 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 or Careful with that VAX Eugene!