Date: Wed, 14 Aug 1996 03:56:53 -0700 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: p.richards@elsevier.co.uk (Paul Richards), lada@ws2301.gud.siemens.co.at, philip_milne@il.us.swissbank.com, hackers@freebsd.org, armando_ferreira@il.us.swissbank.com, charlie_conklin@il.us.swissbank.com Subject: Re: Nightmare. Message-ID: <14039.840020213@time.cdrom.com> In-Reply-To: Your message of "Wed, 14 Aug 1996 20:01:55 %2B0930." <199608141031.UAA01998@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> The problem is that they are intentionally or otherwise _not_ telling us > what they really did. Some people have assumed that they typoed the > tar command; this is certainly a good place to start, but there are other > obvious possibilities beyond this. Actually, they've already admitted full guilt in email to myself and the guy in Austria, they probably just forgot to cc this list. They did indeed make a typo and it was indeed /dev/rsd0a that they backed their root partition onto, sort of a recursive backup with on-the-fly format conversion, of sorts. A novel idea, and I've never heard of anyone trying to do before. Having, however, now seen where one definitely *might* want to do something like this if feeling especially depressed or bored, it occurs to me that we should try to better facilitate our users' needs by implementing the following support features in 2.2: a) Write a filesystem which understands tar files natively. Note: there may be a slight performance penalty for folks running with their root partitions mounted on a TARFS - perhaps we could note this somewhere. b) Add special code to tar which detects that it's writing on the same filesystem(s) it's dumping from, something which shouldn't require much more than a full mark & sweep pass over all files on the system first to figure out where they all reside. Once you've identified the files most immediately in jeopardy of having their inodes or blocks overwritten by tar, you put them first into the backup list and buffer up the output going to the tarfile (the filesystem in this case) until you're sure they've been sucessfully read in - this is your "window". Continue this process, shrinking or growing the window as needed, until the entire filesystem is converted. Note: This may require some use of memory but will otherwise be trivial to implement. c) Tweaks to the kernel so that as soon as it notices that a root filesystem is in the process of being "converted" this way, all processes except for tar are suspended until the operation completes. The root filesystem could then be umounted from UFS and remounted onto the TARFS using the same block device. There will be some kernel and process state to adjust, of course, and all processes with vnodes open on the old root fs will need their file tables adjusted to point to new vnodes which duplicate the exact state of the old ones, but that's just the details. We can probably get a summer student to hack all this out in a weekend if we agree to buy the Jolt. Any volunteers? :-) :-) Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14039.840020213>