Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!tut.cis.ohio-state.edu!morganucodon.cis.ohio-state.edu!jgreely From: jgreely@morganucodon.cis.ohio-state.edu (J Greely) Newsgroups: comp.unix.internals Subject: Re: How do you find the symbolic links to files. Message-ID: Date: 12 Dec 90 21:40:55 GMT References: <1990Dec7.192441.24778@dg-rtp.dg.com> <2469:Dec1001:13:4390@kramden.acf.nyu.edu> <1990Dec10.191522.2757@erg.sri.com> <2993:Dec1202:37:2090@kramden.acf.nyu.edu> Sender: news@tut.cis.ohio-state.edu Reply-To: J Greely Organization: Ohio State University Computer and Information Science Lines: 54 In-reply-to: brnstnd@kramden.acf.nyu.edu's message of 12 Dec 90 02:37:20 GMT In article <2993:Dec1202:37:2090@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >Does anyone else understand the importance of restoring as much stat >information as possible? Everyone does, Dan. I'd even wager that there are people who (say it isn't so!) understand it better than you. >Now Elizabeth's position has been that an archiver cannot do this >without going beyond the stat information and reading the raw disk. Not quite. Her original article said "get pretty intimate with", not necessarily "read the raw disk". To find out the actual space used by a file, you need the number of allocated blocks and the block size. The former is only available on systems that support st_blocks; the latter varies from system to system, and if your archiver has to cope with NFS, from filesystem to filesystem. The block size can usually be found with the statfs(3) call, unless the filesystem is mounted from a sun (in which case statfs returns the wrong answer). If you don't have statfs, you can compute the block size from a known hole-less file (a directory is a good choice on a local file system). Then, of course, you have to scan every block in the file to find out which ones are potential holes. Compared to what tar and cpio do, that looks like "pretty intimate" to me. > 1. On a system without st_blocks, an archiver can lseek past every > 0-filled region. The system will automatically use holes wherever > possible. > (C) This wastes only restore time, not dump time. It wastes bunches of dump time; every file has to be scanned for zero-filled blocks, or you waste shitloads of tape. > 2. On a system with st_blocks, an archiver can lseek past the first > N 0-filled regions, enough to restore st_blocks; and then it can > write explicit zeros in the rest. > (C) This wastes only restore time, not dump time; and it only > wastes restore time on files that actually do have holes. If you don't know the block size, this effectively degenerates to #1 above. Even if you do, it still wastes dump time finding the zero-filled blocks (but only in files that are known to have holes). Note that if you find the holes while dumping, you don't waste any time while restoring. >Right! So on a system with st_blocks, the archiver's responsibility is >to restore the right number of holes. Wrong! Its first responsibility is to not copy the contents of the right number of holes into the archive. Its *second* responsibility is to not restore the contents of the holes. Who cares about the value of st_blocks on the original filesystem? -- J Greely (jgreely@cis.ohio-state.edu; osu-cis!jgreely)