Date: Wed, 14 Aug 1996 09:02:28 -0700 (PDT) From: Ulf Zimmermann <ulf@Lamb.net> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: hackers@freebsd.org Subject: Re: Nightmare. Message-ID: <199608141602.JAA07816@Gatekeeper.Lamb.net> In-Reply-To: <14039.840020213@time.cdrom.com> from "Jordan K. Hubbard" at "Aug 14, 96 03:56:53 am"
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. I would go more into the direction of checking if the dump device is a mounted file system. Easy check. > > 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 > Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 Lamb Art Internet Services || http://www.Lamb.net/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608141602.JAA07816>