Date: Wed, 14 Aug 1996 18:24:12 +0300 (EET DST) From: Narvi <narvi@haldjas.folklore.ee> To: "Jordan K. Hubbard" <jkh@time.cdrom.com> Cc: Michael Smith <msmith@atrad.adelaide.edu.au>, Paul Richards <p.richards@elsevier.co.uk>, 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: <Pine.BSF.3.91.960814182010.24575A-100000@haldjas.folklore.ee> In-Reply-To: <14039.840020213@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 14 Aug 1996, Jordan K. Hubbard wrote: > > 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? :-) :-) Ok, how about just some additional code to tar and dump to check against overwriting mounted file systems? For it seems probable that the root file system was mounted (and perhaps also double check if the file system is mounted root). Sander > > Jordan >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.960814182010.24575A-100000>