Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!wuarchive!zaphod.mps.ohio-state.edu!uwm.edu!rutgers!mcnc!rti!xyzzy!meissner From: meissner@dg-rtp.dg.com (Michael Meissner) Newsgroups: comp.unix.questions Subject: Re: sparse files Message-ID: Date: 11 Dec 89 18:01:08 GMT References: <21581@adm.BRL.MIL> <235@dg.dg.com> <2700@auspex.auspex.com> Sender: usenet@xyzzy.UUCP Organization: Data General (Languages @ Research Triangle Park, NC.) Lines: 40 In-reply-to: guy@auspex.auspex.com's message of 8 Dec 89 18:48:36 GMT In article <2700@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: | >UNIX treats the "holes" as 0's when read. In fact, UNIX has only | >minimal support for sparse files. Backing up sparse files often | >involves copying large amounts of nulls. Once an area of a file is | >written, it cannot be returned to its previous sparse state. | | Not in general, anyway. At least the first version of AIX for the RT PC | claimed, in its documentation, that it had an "fclear()" call to punch | holes in files; I think this may show up in future releases of other | UNIXes as well. | | >In arguments that UNIX is not suitable for DP applications, sparse | >files usually come up if the conversation goes on long enough between | >knowledgeable people. | | Umm, what other operating systems support sparse files *and* return a | "there's a hole there" indication? For instance, are there any OSes | with extent-based file systems (VMS, OS/360 and successors as I | remember, IRIX with SGI's Extent File System) that support sparse files? Data General's AOS/VS and AOS/VS-II operating systems support sparse files, and recently they added a version of the read block system call that would indicate where the holes are. The default read and read block system calls just return all zeroes. Both the file level backup programs, and the low level disk copy programs preserve holes. Actually the user level backup programs will never write blocks of all 0's to the backup media (unlike either tar or cpio). Before the system call to tell where the holes were added, you could watch the backup program get into a tight CPU loop when it would be processing a large host (say a couple of meg of so). The OS would realize that there was a hole, and fill the buffer with all 0's, the dump program would then compare the block to see if it contained all 0's, and if it did skip it, maintaining the file position internally so it could then be indicated when the next real data was encountered. -- -- Michael Meissner, Data General. Until 12/15: meissner@dg-rtp.DG.COM After 12/15: meissner@osf.org