[KLUG Members] Transactional filesystems?

Adam Williams members@kalamazoolinux.org
Sat, 21 Dec 2002 14:41:21 -0500 (EST)


>I'm starting to realize that a distributed filesystem that allows multiple 
>updaters just might actually have some use in the world.  After playing with
>SQL Server's replicatoin features I'm pretty geeked on the idea now.  I'm sort
>of wondering -why- this doesn't really exist at the FS layer to tell you the 
>truth.  

CODA, GFS, etc...

>Anybody ever seen PDM systems that need to keep local CAD drawings in their
>repository in sync and in different regions?  Could be useful there -- I know
>MatrixOne and Workamanger both have stuff to do this, but it's done with
>seperate processes.  Much like how SQL Server/Sybase do their DB replication
>really -- at least the same model.

I think your looking for GFS.

>With the plethora of journaling filesystems being released for Linux it might
>not be too much work to hi-jack one of them and turn them into something like
>this.  Here's the idea:
>You mount an exported directory of which you also have a local mirror of.
>When you update your local copy changes are migrated off to the master server
>which them pushes the changes down to all the other subscribers to the
>fileystem.  Everybody has the files locally for fast access time, but work
>done on one system gets pushed over to another one.  Sorta like NFS with a
>giant cache I suppose.  Tag each file with a unique identiefer (128 bit random

Actually some NFS clients (AIX for one) actually can do client side 
caching of chunks of files.  But this gets REALLY tricky and is in the end 
far more complicated than the plan you laid out - but GFS is supposed to 
be able to handle all this.  And since it is made by the same people 
(Sistina.com) as the Linux LVM system I'd tend to believe them.  But I 
haven't got around to trying it yet.

>My biggest problem with the idea is -- how do you control what -order- theese
>changes get commited to the master repository?  I'm sure some DB research
>would let me know how they do this.  A timestamp isn't reliable, as you can't
>be sure that all the system's clock are sligned perfectly.  It's just not
>feasible.

They clock sync, and not just by NTP, but the databases keep a clock 
differential between themselves, and usually some type of shared 
lock/state database.  Then ultimately it is using time stamps.

>Is there any interest in something like this, or does something like it
>already exist and I've just never heard of it?

GFS.