On Sun, Mar 16, 2003 at 11:29:15PM +0000, Dirk Koopman wrote: > On Sun, 2003-03-16 at 18:53, Chris Benson wrote: > > > > I think of it as 'copying the inode-table' ... and since their f/s > > doesn't rewrite blocks only writes fresh ones, by looking at the 0800 > > copy of the inode-table, you get the files at 0800. This leads to two > > problems that I see: some real hot-spots on the disks that they fix by > > having battery backed RAM-cache and just the management of such a f/s -- > > makes my head hurt thinking about it. > > Erm.. none of this is actually that new and the problems are (or at were > in about 1967) quite well understood. Neither is it particularly hard. A > combination of copy on write with some (:-) administration to make it > all hang together, together with some careful write ordering will do the > job very nicely.
Nope, but *I've* not seen it done: I'm very comfortable with 'trad' Unix filesystem semantics - the 'never rewrite a block' which suggests that the block-list of a file gets updated with every write is a bit worrying because it's unfamiliar (I'm getting staid in my advancing years :-) ... and as you say "some careful write ordering". Actually I think my head was hurting because of some bug. A couple of paracetamol and I'm much better now. -- Chris Benson - trying to remember the hierarchical database that did something like this on CP/M back in the '80s -- you could append 'AT yy/mm/dd hh:ss' to a query to get it at that point in time ... unless the logs had been flushed.
