From owner-freebsd-hackers Tue Mar 7 12:52:40 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from usc.edu (usc.edu [128.125.253.136]) by hub.freebsd.org (Postfix) with ESMTP id 183C537B54C for ; Tue, 7 Mar 2000 12:52:37 -0800 (PST) (envelope-from walker@usc.edu) Received: from skat.usc.edu (walker@skat.usc.edu [128.125.253.131]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id MAA14484; Tue, 7 Mar 2000 12:51:05 -0800 (PST) Received: from localhost (walker@localhost) by skat.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id MAA26999; Tue, 7 Mar 2000 12:51:04 -0800 (PST) Date: Tue, 7 Mar 2000 12:51:03 -0800 (PST) From: Mike Walker To: "Louis A. Mamakos" Cc: sthaug@nethelp.no, kc5vdj@swbell.net, jbryant@ppp-207-193-2-159.kscymo.swbell.net, mbac@nyct.net, freebsd-hackers@FreeBSD.ORG Subject: Re: Copy-on-write filesystem In-Reply-To: <200003051405.JAA17903@whizzo.transsys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > Imagine: cp file file2, file and file2 reference the same exact blocks, > > > > but modified chunks of file2 would be given their own private blocks. > > > > > > This is not a microsoft innovation, actually, I believe it was a VMS > > > innovation. It's called a generational filesystem. the original is > > > stored, and later generations of the file are stored as diffs. > > > > As far as I know, VMS simply stores whole files - no diffs involved. Now > > if you go back to for instance Univac 1100 and the Exec-8 OS (I suppose > > it is OS-1100 now), you'll find a system that *did* store the diffs. In > > the form of punched card images! :-) > > Well, not really. That was mostly an application convention rather than > being done in the OS. And that all the applications wanted to use > SIR$ SDF to read program file elements was just a coincidence :-) > > The cools part of Exec-8 that we still need (we already have sparse > files) are the virtual filesystem bits. E.g., unloaded files. People > have been struggling with multi-level storage architectures on UNIX > for years, while this was pretty much a solved problem on these 1's > complement 36 bit dinosars 30 years ago. > > (The notion was that if you didn't use a file in a while, the system > would release the data blocks, and mark the file as "unloaded." When > you "assigned"/opened one of these files, a system process would cause > the current backup tape to be loaded, and the file restore. When you > began to get low on disk space, likeway a systen process would start, > and sort all files based on their priority for being unloaded - based > on last reference time, do we have a current backup, who created it, etc. > It would then begin to release the data blocks until you acheived a > configured threshold.) > > louie Unitree does something like this for UNIX with auto migration to tape. See http://www.unitree.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message