public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Blake Barnett <blake.barnett@developonline.com>
To: Mark Richards <richard@ecf.utoronto.ca>
Cc: Linux-kernel@vger.kernel.org
Subject: Re: Multiplexing filesystem
Date: 27 Nov 2001 16:39:38 -0700	[thread overview]
Message-ID: <1006904378.6664.46.camel@shiva> (raw)
In-Reply-To: <3C030FB4.C3303BE4@ecf.utoronto.ca>
In-Reply-To: <3C030FB4.C3303BE4@ecf.utoronto.ca>

You may want to look into utilizing CVS for the check-in/check-out
mechanism and just virtualizing that layer on top of whatever FS is
being used.... 

This may be a good place to start looking.
http://sourceforge.net/projects/cvsfs/

If you don't need all the sophistication of CVS perhaps RCS would do.
 
The way Coda does it is by "hoarding" files, you specify what files you
want to hoard, and it refers to those as local only, when you "un-hoard"
them it syncs them with the server  (I think this is the process, it's
been a while since I played with it.)

I think intermezzo has something similar, but neither does any revision
control.


On Mon, 2001-11-26 at 20:59, Mark Richards wrote:
> Quick question, which I suspect has a long answer.
> 
> I would like to write a multiplexing filesystem.  The idea is as follows:
> 
> The filesystem would ideally wrap another filesystem, such as nfs or smbfs or
> ext2.  Most operations would just be passed to the native fs call.  However, for
> some files, selectable at run time by some control singal, would actually reside
> on another file system.  The other filesystem would have to be mounted.
> 
> The idea is for a version controlling filesystem.  The server would be a network
> server (hence the desire to wrap nfs) which presents a 'view' of the source
> code.  When the user reserves a file for editing, the file is copied to the
> local disk.  From that point on, the local file is referred to until the user
> commits the change or unreserves the file.  Ideally, the local copy of the file
> could be on any file system, not one that is necessarily local.  And this has to
> be totally transparent to the user, except for the step where the user
> 'reserves' the file.
> 
> I've thought about two ways to do this.  One is to wrap the 'versioning' file
> system with a multiplexor that checks fs calls to see if they are referring to a
> file that is on a different fs.  The other approach is to intercept calls to the
> VFS to do the same trick.
> 
> I'm new to the whole filesystem-coding thing, so bear with me if what i've just
> said makes no sense.  So, my question (I guess it wasn't quick after all) is:
> Can it be done, and are either of my two approaches feasible?  Any suggestions
> or tips?
> 
> Thanks,
> Mark Richards
> 
> PS please CC me if possible.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-- 
Blake Barnett (bdb)  <blake.barnett@developonline.com>
Sr. Unix Administrator
DevelopOnline.com                 office: 480-377-6816

"Do, or do not.  There is no try." --Yoda


      parent reply	other threads:[~2001-11-27 23:40 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-27  3:59 Multiplexing filesystem Mark Richards
2001-11-27  4:34 ` Jeff V. Merkey
2001-11-27  4:39   ` Jeff V. Merkey
2001-11-27  7:38 ` James Davies
2001-11-28  0:34   ` Pavel Machek
2001-11-27 10:27 ` Helge Hafting
2001-11-27 14:45   ` Mark Richards
2001-11-27 19:37     ` Mike Fedyk
2001-11-28 11:11     ` Helge Hafting
2001-11-29  1:56       ` Mark Richards
2001-11-27 15:15 ` Eli Carter
2001-11-27 23:39 ` Blake Barnett [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1006904378.6664.46.camel@shiva \
    --to=blake.barnett@developonline.com \
    --cc=Linux-kernel@vger.kernel.org \
    --cc=richard@ecf.utoronto.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox