RE: [SLUG] Ok we have it now,,

From: R P Herrold (herrold@owlriver.com)
Date: Tue Feb 26 2002 - 16:38:16 EST


On Tue, 26 Feb 2002, Grantham, Patrick wrote:

> Seems odd to me, say this is accomplished. What price would be paid in the
> way of overhead on the server, constantly synching the file in ram (read)
> with the file on the disk (writes)?

Rsync can handle that with relativey little load; The issue is
not there -- The issue is that you are essentially creating a
RAID file subsystem, where one leg is RW and the other is RO
-- Which is 'correct' and authoritative?

If it were a write only system, you'd open the file in append
-- but then, how do you update the changed inode information
in the RO side when a new inode is added ?

The inode table loses coherency, and the RW filesystem is then
corrupt relative to the RO one.

By way of analogy, it is like a special serial device -- read
only -- you cannot 'rewind' the data stream, and if you need
to do so, you'd better capture the data stream into a caching
temp file, which you _can_ re-play parts of. But at that
point, the current state of the serial device [always at head
of any ring buffer], and the pointer location into the
tempfile [random] are not synchronized.

-- Russ Herrold

> > Could that be done so that the writes would follow the link? There must be
> > some way to trap access to filesystems and catch the writes and redirect
> > them to another filesystem. Is anyone out there technical enough to explain
> > why this cannot be? Or better yet is anyone out there thinking outside the
> > box today and can tell me hoe to accomplish this?
>
> it may be possible -- but it is a major undertaking --
> certainly nothing I have ever seen



This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 16:47:36 EDT