Replicating directories - Intercepting write/modify system calls

Replicating directories - Intercepting write/modify system calls

[Siddhartha Jain]

Hello,

I need a module/tool to replicate directories locally or across a network.
Locally, the master and the mirror directories may not belong to the same
FS. My immiediate need is to replicate a NFS-mounted directory to another
local/NFS directory. So here is what I figured:

1. A config file contains the master and mirror paths
2. Expand the vnode structure to include two things: a bit-flag to indicate
that the vnode has a replica and a pointer to the replica vnode.
3. When an open() is called,
	a. check if the read/modify option is set in the open() (I am not
interested in replicating access-time at the moment).
	b. If yes, check the path of the file against the known masters in the
config.
	c. If it matches, copy the file to a destination specified by the mirror's
path.
	d. Set the flag in the master vnode for replica and place a pointer to the
replica vnode in the master's structure.
	e. After this replicate all write() calls for the master vnode to the
replica vnode.
	f. close() the replica vnode when the master is close()-ed.


Being a sysadmin and not really a C/Kernel programmer, I do not know how
much is this feasible and practical.

Given that it is ok, how do I avoid the copy at open() and do only
incremental changes everytime a file is closed and re-opened.

Regards,

Siddhartha

RE: Replicating directories - Intercepting write/modify system calls

[Joseph D. Wagner]

Too complicated.  Too invasive.

Replicating the entire partition rather than just a specific directory is more feasible.

Does it need to be replicated in real-time, or would an incremental synchronization be acceptable (i.e. synced every 15 minutes or so)?

Does it need to be a two-way synchronization, or is a one-way synchronization acceptable?  In other words, do changes on the replica need to be synced back to the original?

Are you willing to commission someone (i.e. pay them money) to do this work? 8-D

Joseph D. Wagner, Underemployed
www.josephdwagner.info

> -----Original Message-----
> From: Siddhartha Jain [mailto:sid@netmagicsolutions.com]
> Sent: Thursday, February 12, 2004 6:39 AM
> To: linux-fsdevel@vger.kernel.org
> Subject: Replicating directories - Intercepting write/modify system calls
> 
> Hello,
> 
> I need a module/tool to replicate directories locally or across a network.
> Locally, the master and the mirror directories may not belong to the same
> FS. My immiediate need is to replicate a NFS-mounted directory to another
> local/NFS directory. So here is what I figured:
> 
> 1. A config file contains the master and mirror paths
> 2. Expand the vnode structure to include two things: a bit-flag to
> indicate
> that the vnode has a replica and a pointer to the replica vnode.
> 3. When an open() is called,
> 	a. check if the read/modify option is set in the open() (I am not
> interested in replicating access-time at the moment).
> 	b. If yes, check the path of the file against the known masters in
> the
> config.
> 	c. If it matches, copy the file to a destination specified by the
> mirror's
> path.
> 	d. Set the flag in the master vnode for replica and place a pointer
> to the
> replica vnode in the master's structure.
> 	e. After this replicate all write() calls for the master vnode to
> the
> replica vnode.
> 	f. close() the replica vnode when the master is close()-ed.
> 
> 
> Being a sysadmin and not really a C/Kernel programmer, I do not know how
> much is this feasible and practical.
> 
> Given that it is ok, how do I avoid the copy at open() and do only
> incremental changes everytime a file is closed and re-opened.
> 
> Regards,
> 
> Siddhartha
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Replicating directories - Intercepting write/modify system calls

[Siddhartha Jain]

Hey Joseph,

>Too complicated.  Too invasive.

In what way? Will it slow down the FS too much? What other approach can be adopted to keep the implementation FS-independant and still track the changes in real-time.

>Replicating the entire partition rather than just a specific directory is more feasible.

How would I do that? Will the implementation still be FS-independant?

>Does it need to be replicated in real-time, or would an incremental synchronization be acceptable (i.e. synced every 15 >>minutes or so)?

Synced every fifteen minutes is ok but anything that scans the whole partition/directory file by file would be nighmarish given that the mail toasters I am mirroring have tens of thousands of files. Therefore, IMHO, the solution needs to track changes as and when they happen to the file and mirror them immiediately.

For eg, a rsync/mirrordir takes upto half-an-hour to sync about 100,000 files. Not to mention the 40% CPU load on the file server while the rsync runs (a host mounts the NFS folder from a NetApp filer and rsyncs it to a local dir). This is just one server. If I were to put all my 6 mail toasters on the filer and mirror the filer's main volume to a host, I guess either would croak.

>Does it need to be a two-way synchronization, or is a one-way synchronization acceptable?  In other words, do changes on the >replica need to be synced back to the original?

For my purpose, one-way is fine. But two-way would be cool and in the greater good of humankind ;)

>Are you willing to commission someone (i.e. pay them money) to do this work? 8-D

Yep, I will give you a free mail account on my mail servers and if the code is really good, maybe a rksh account too :P

Btw, I am willing to do all the dirty work of wrestling with C code and testing but I need guidance.

Sorry, if my questions sound too un-informed or stupid. I feel like a mere human roaming amongst gods of FS. :)

Siddhartha Jain (CISSP)


> -----Original Message-----
> From: Siddhartha Jain [mailto:sid@netmagicsolutions.com]
> Sent: Thursday, February 12, 2004 6:39 AM
> To: linux-fsdevel@vger.kernel.org
> Subject: Replicating directories - Intercepting write/modify system calls
> 
> Hello,
> 
> I need a module/tool to replicate directories locally or across a network.
> Locally, the master and the mirror directories may not belong to the same
> FS. My immiediate need is to replicate a NFS-mounted directory to another
> local/NFS directory. So here is what I figured:
> 
> 1. A config file contains the master and mirror paths
> 2. Expand the vnode structure to include two things: a bit-flag to
> indicate
> that the vnode has a replica and a pointer to the replica vnode.
> 3. When an open() is called,
> 	a. check if the read/modify option is set in the open() (I am not
> interested in replicating access-time at the moment).
> 	b. If yes, check the path of the file against the known masters in
> the
> config.
> 	c. If it matches, copy the file to a destination specified by the
> mirror's
> path.
> 	d. Set the flag in the master vnode for replica and place a pointer
> to the
> replica vnode in the master's structure.
> 	e. After this replicate all write() calls for the master vnode to
> the
> replica vnode.
> 	f. close() the replica vnode when the master is close()-ed.
> 
> 
> Being a sysadmin and not really a C/Kernel programmer, I do not know how
> much is this feasible and practical.
> 
> Given that it is ok, how do I avoid the copy at open() and do only
> incremental changes everytime a file is closed and re-opened.
> 
> Regards,
> 
> Siddhartha
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Replicating directories - Intercepting write/modify system calls

[Joseph D. Wagner]

>> Too complicated.  Too invasive.

> In what way? Will it slow down the FS too much? What other approach
> can be adopted to keep the implementation FS-independant and still
> track the changes in real-time.

The changes you proposed in your original email would require changes to too
many functions, files, and other segments of code and design.  Such changes
would never be adopted by the Linux "powers that be."  As such, you'd have
to maintain the code yourself and manually patch each new kernel with your
customized replication code.  The goal, therefore, is to make changes that
get adopted into the official Linux kernel to save yourself future
maintenance work and allow others to both debug and benefit from your code.

A rule of thumb -- the change that accomplishes the task in the least amount
of code wins.

As for another approach, see my next point.

>> Replicating the entire partition rather than just a specific directory
>> is more feasible.

> How would I do that? Will the implementation still be FS-independant?

To be brief, I don't know that it can be done -- the code may have to be
written first -- and no implementation will be FS independent.

The VFS (Virtual File System) is merely a set of function pointers.  A
function pointer when called simply says, "Use this other function."  In
other words, a function pointer is a variable that stores which function to
use, but a function pointer is not in and of itself a function.  It cannot
do any grunt work of its own.  Hence, implementing your proposal at the VFS
level would be impossible because all the VFS does is call the appropriate
FS-specific function.

Your proposal would be easier to implement in C++ which uses virtual
functions rather than function pointers, but converting the Linux kernel to
C++ is a whole different topic.  FYI: the core kernel developers have
already outright refused to do that.

>> Does it need to be replicated in real-time, or would an
>> incremental synchronization be acceptable (i.e. synced
>> every 15 minutes or so)?

> Synced every fifteen minutes is ok but anything that scans the
> whole partition/directory file by file would be nighmarish given
> that the mail toasters I am mirroring have tens of thousands of
> files. Therefore, IMHO, the solution needs to track changes as
> and when they happen to the file and mirror them immiediately.
>
> For eg, a rsync/mirrordir takes upto half-an-hour to sync about
> 100,000 files. Not to mention the 40% CPU load on the file server
> while the rsync runs [trimmed].

You can scan ~100,000 files to see if they have changed in less than 90
seconds -- at least on a locally mounted partition.  The part that takes
forever is the actual syncing of data.

See my next point for a continued explanation.

>> Does it need to be a two-way synchronization, or is a one-way
>> synchronization acceptable?  In other words, do changes on the
>> replica need to be synced back to the original?

> For my purpose, one-way is fine. But two-way would be cool and
> in the greater good of humankind ;)

Is this for load balancing, or a sophisticated way of doing a backup?

If it's just for a backup, I'll tell you right now that your project isn't
worth the effort.

If it's for load balancing, you'll have to do a quasi-cost/benefit analysis
on whether or not real-time replication really results in a balanced load or
if the network bandwidth and CPU cycles consumed by real-time replication
offsets the load balancing benefits.  After all, one of the pillars of load
balancing is to reduce the amount of work in the here and now, and real-time
replication -- as opposed to syncing every 15 or so minutes -- is
counterproductive to that end.

>> Are you willing to commission someone (i.e. pay them money) to
>> do this work? 8-D

[paraphrased] Yep, I will give you a free mail account on hotmail....

Uh... gee, thanks, but I was hoping for something along the lines of actual
cash or employment.  You see, I'm a computer programmer with my BA in
Computer Science and even a 3.0 GPA, but no one's willing to hire me without
2-3 years of experience.  (Catch 22.  How do I get the experience if no one
is willing to give it?)  BTW, I could also be a system administrator; my
degree covered that too.  It's just that I haven't gotten far enough down my
career path to be fixed on one road or the other.

> Btw, I am willing to do all the dirty work of wrestling with C code
> and testing but I need guidance.

At the risk of sounding rude, without the motivation of actual cash or
employment, the most I'm willing to do is direct you to some good albeit
expensive books on the topic.

Understanding the Linux Kernel (2nd Edition)
http://www.amazon.com/exec/obidos/ASIN/0596002130/

Linux Device Drivers, 2nd Edition
http://www.amazon.com/exec/obidos/ASIN/0596000081/

UNIX Filesystems: Evolution, Design, and Implementation
http://www.amazon.com/exec/obidos/ASIN/0471164836/

Linux Kernel Programming, Third Edition
http://www.amazon.com/exec/obidos/ASIN/0201719754/

C: The Complete Reference, (Book/CD Package)
http://www.amazon.com/exec/obidos/ASIN/0072121246/

And maybe more depending on your familiarity with operating system theory.
FYI: I own all of the above books except "C: The Complete Reference" and
recommend ALL of them for your project.

> Sorry, if my questions sound too un-informed or stupid. I feel
> like a mere human roaming amongst gods of FS. :)

Thanks, but I'm not god.  I've only been at this whole FS development thing
a few months myself.  Actually, I'm finishing up a defrag program for ext2
and ext3 file systems.  It works perfectly -- at least on my computer ;-)
I need only finish the documentation, and then I'll release it into the
wild.  This project has baptized me by fire.

Joseph D. Wagner

> -----Original Message-----
> From: Siddhartha Jain [mailto:sid@netmagicsolutions.com]
> Sent: Thursday, February 12, 2004 6:39 AM
> To: linux-fsdevel@vger.kernel.org
> Subject: Replicating directories - Intercepting write/modify system calls
> 
> Hello,
> 
> I need a module/tool to replicate directories locally or across a network.
> Locally, the master and the mirror directories may not belong to the same
> FS. My immiediate need is to replicate a NFS-mounted directory to another
> local/NFS directory. So here is what I figured:
> 
> 1. A config file contains the master and mirror paths
> 2. Expand the vnode structure to include two things: a bit-flag to
> indicate
> that the vnode has a replica and a pointer to the replica vnode.
> 3. When an open() is called,
> 	a. check if the read/modify option is set in the open() (I am not
> interested in replicating access-time at the moment).
> 	b. If yes, check the path of the file against the known masters in
> the
> config.
> 	c. If it matches, copy the file to a destination specified by the
> mirror's
> path.
> 	d. Set the flag in the master vnode for replica and place a pointer
> to the
> replica vnode in the master's structure.
> 	e. After this replicate all write() calls for the master vnode to
> the
> replica vnode.
> 	f. close() the replica vnode when the master is close()-ed.
> 
> 
> Being a sysadmin and not really a C/Kernel programmer, I do not know how
> much is this feasible and practical.
> 
> Given that it is ok, how do I avoid the copy at open() and do only
> incremental changes everytime a file is closed and re-opened.
> 
> Regards,
> 
> Siddhartha

RE: Replicating directories - Intercepting write/modify system calls

[Siddhartha Jain]

Thanks, your explanation was very succinct and to the point.
>
> >> Too complicated.  Too invasive.
>
> > In what way? Will it slow down the FS too much? What other approach
> > can be adopted to keep the implementation FS-independant and still
> > track the changes in real-time.
>
> The changes you proposed in your original email would require
> changes to too > many functions, files, and other segments of code and
design.
> Such changes would never be adopted by the Linux "powers that be."  As
such, you'd have
> to maintain the code yourself and manually patch each new kernel with your
> customized replication code.  The goal, therefore, is to make changes that
> get adopted into the official Linux kernel to save yourself future
> maintenance work and allow others to both debug and benefit from
> your code.
>
> A rule of thumb -- the change that accomplishes the task in the
> least amount
> of code wins.

I totally agree.

>
> As for another approach, see my next point.
>
> >> Replicating the entire partition rather than just a specific directory
> >> is more feasible.
>
> > How would I do that? Will the implementation still be FS-independant?
>
> To be brief, I don't know that it can be done -- the code may have to be
> written first -- and no implementation will be FS independent.
>
> The VFS (Virtual File System) is merely a set of function pointers.  A
> function pointer when called simply says, "Use this other function."  In
> other words, a function pointer is a variable that stores which
> function to
> use, but a function pointer is not in and of itself a function.  It cannot
> do any grunt work of its own.  Hence, implementing your proposal
> at the VFS
> level would be impossible because all the VFS does is call the appropriate
> FS-specific function.

Ok, to give an example (with ref to
http://www.faqs.org/docs/kernel_2_4/lki-3.html)

the function open() really calls upon sys_open in fs/open.c.

sys_open looks like:
asmlinkage long sys_open(const char __user * filename, int flags, int mode)
{
        char * tmp;
        int fd, error;

#if BITS_PER_LONG != 32
        flags |= O_LARGEFILE;
#endif
        tmp = getname(filename);
        fd = PTR_ERR(tmp);
        if (!IS_ERR(tmp)) {
                fd = get_unused_fd();
                if (fd >= 0) {
                        struct file *f = filp_open(tmp, flags, mode);
                        error = PTR_ERR(f);
                        if (IS_ERR(f))
                                goto out_error;
                        fd_install(fd, f);
                }
out:
                putname(tmp);
        }
        return fd;

out_error:
        put_unused_fd(fd);
        fd = error;
        goto out;
}


Change it to include:
1. Check if the filename path matches any master definition in a config
file.
2. If it does, append the (filename path - master path) and append the
remaining to the mirror path.
3. Replicate every call within sys_open with the parameter mirror_file.

Same goes for sys_write and other functions that modify a file (ioctl?).

Ofcourse, what I should be doing is trying it out and seeing if it works
instead of increasing mail traffic. But I do not know the repurcussions on
other parts of the kernel and that is where I need your input.

>
> Your proposal would be easier to implement in C++ which uses virtual
> functions rather than function pointers, but converting the Linux
> kernel to
> C++ is a whole different topic.  FYI: the core kernel developers have
> already outright refused to do that.

C++?? Now now, I am humble being. I don't want to be another Linus. One's
enough for the M$ and the like :)

>
> >> Does it need to be replicated in real-time, or would an
> >> incremental synchronization be acceptable (i.e. synced
> >> every 15 minutes or so)?
>
> > Synced every fifteen minutes is ok but anything that scans the
> > whole partition/directory file by file would be nighmarish given
> > that the mail toasters I am mirroring have tens of thousands of
> > files. Therefore, IMHO, the solution needs to track changes as
> > and when they happen to the file and mirror them immiediately.
> >
> > For eg, a rsync/mirrordir takes upto half-an-hour to sync about
> > 100,000 files. Not to mention the 40% CPU load on the file server
> > while the rsync runs [trimmed].
>
> You can scan ~100,000 files to see if they have changed in less than 90
> seconds -- at least on a locally mounted partition.  The part that takes
> forever is the actual syncing of data.

Yep, scanning might not take long. But the whole process and overheads are
just not practical. I guess, rsync/mirrodir weren't written with this
application in mind.

>
> See my next point for a continued explanation.
>
> >> Does it need to be a two-way synchronization, or is a one-way
> >> synchronization acceptable?  In other words, do changes on the
> >> replica need to be synced back to the original?
>
> > For my purpose, one-way is fine. But two-way would be cool and
> > in the greater good of humankind ;)
>
> Is this for load balancing, or a sophisticated way of doing a backup?
>
> If it's just for a backup, I'll tell you right now that your project isn't
> worth the effort.
>
> If it's for load balancing, you'll have to do a
> quasi-cost/benefit analysis
> on whether or not real-time replication really results in a
> balanced load or
> if the network bandwidth and CPU cycles consumed by real-time replication
> offsets the load balancing benefits.  After all, one of the
> pillars of load
> balancing is to reduce the amount of work in the here and now,
> and real-time
> replication -- as opposed to syncing every 15 or so minutes -- is
> counterproductive to that end.

See, I have a NetApp filer. All mail toasters mount the same volume from the
filer. Now, what if the filer dies - as in a hardware failure? I would have
to bring up another file server and restore the last tape backup to it. The
loss of mails between the last tape backup and disaster time are not
acceptable. Another option is that I buy another filer and run (buy)
NetApp's propreitary code to do the replication between the two filers.
Unfortunately, I have money for neither.

So what I can do is keep another Linux box as a filer. Export a volume as
NFS to all the toasters. And the toasters replicate the NetApp filer mounted
directory to the Linux-filer mounted directory. Initially, one way is good.
Later, if I can get two-way to work, then I catch load-balance between the
NFS filers with intelligent DNS.

>
> >> Are you willing to commission someone (i.e. pay them money) to
> >> do this work? 8-D
>
> [paraphrased] Yep, I will give you a free mail account on hotmail....
>
> Uh... gee, thanks, but I was hoping for something along the lines
> of actual
> cash or employment.  You see, I'm a computer programmer with my BA in
> Computer Science and even a 3.0 GPA, but no one's willing to hire
> me without
> 2-3 years of experience.  (Catch 22.  How do I get the experience
> if no one
> is willing to give it?)  BTW, I could also be a system administrator; my
> degree covered that too.  It's just that I haven't gotten far
> enough down my
> career path to be fixed on one road or the other.

I don't want to mock you. I know you live in the US or some developed
nation. But if you want a job, I can offer you one. Its in India and we pay
reasonanly well according to Indian standards. On what we pay, you can rent
a place, buy a car, spend nights at a disc/pub/PS2/X-box and still save a
bit. We are a small company that enjoys working with people who have new
ideas and we encourage whatever cool stuff people want to do (as long as it
makes some money for us). Basically, no corporate crap and policy and stuff.
Check out www.netmagicsolutions.com

>
> > Btw, I am willing to do all the dirty work of wrestling with C code
> > and testing but I need guidance.
>
> At the risk of sounding rude, without the motivation of actual cash or
> employment, the most I'm willing to do is direct you to some good albeit
> expensive books on the topic.

Thanks for the same. I don't expect anyone to do my work for me. Goodluck
with your little project. May it find its place in the official Linux kernel
tree :)

RE: Replicating directories - Intercepting write/modify system calls

[Joseph D. Wagner]

> Ok, to give an example (with ref to
> http://www.faqs.org/docs/kernel_2_4/lki-3.html)
> 
> the function open() really calls upon sys_open in fs/open.c.
> 
> sys_open looks like:
> asmlinkage long sys_open(const char __user * filename, int flags, int
> mode)
> {
[trimmed]
> }
> 
> Change it to include:
> 1. Check if the filename path matches any master definition in a config
> file.
> 2. If it does, append the (filename path - master path) and append the
> remaining to the mirror path.
> 3. Replicate every call within sys_open with the parameter mirror_file.
> 
> Same goes for sys_write and other functions that modify a file (ioctl?).

Ah!  Right idea; wrong terminology.  Sorry for the miscommunication.

sys_open() is the kernel function that gets called when a user program calls the POSIX open() function.  It could very well be considered part of the VFS because it does the pre-work before the file system specific function is called; however, most people, including myself, do not think of it that way.

Assuming you decided to go forward with your project, this would be the correct location to start, but see my next point.

>>>> Does it need to be a two-way synchronization, or is a one-way
>>>> synchronization acceptable?  In other words, do changes on the
>>>> replica need to be synced back to the original?

>>> For my purpose, one-way is fine. But two-way would be cool and
>>> in the greater good of humankind ;)

>> Is this for load balancing, or a sophisticated way of doing a backup?

[paraphrased] For now, backup, but I'd like to do load balancing in the [paraphrased] future.

If you want one-way, non-real-time duplication, you don't even need to hack the kernel.  Simply create a daemon (program that runs in the background) that executes every x minutes to scan files for changes and duplicate those files.

If you want two-way, non-real-time duplication for load balancing, simply run one daemon on each server: one on the original to send to the replica, and one on the replica to send to the original.  The only catch is that you'd have no way of knowing if you're opening an outdated, unsynced file.  To fix that, you'd need to hack the kernel.  However, in this way you'd only have to change sys_open() and sys_close() with a minimal amount of changes to the kernel code leaving most of the work to the daemon.  (Ah, and now we've scaled back your proposal to something more feasible.)  This is the most likely solution to be accepted and adopted by the Linux community.

If you want any real-time duplication, you've got your work cut out for you.

Joseph D. Wagner

RE: Replicating directories - Intercepting write/modify system calls

[Siddhartha Jain]

Apart from this, how do I keep my filesystems sane between kernel crashes? I
mean once I start playing with the kernel (that too with stuff like
sys_open, sys_write), there will be several crashes.

There has to be a way other than re-installing the OS over and over again.
Right?

TIA,

Siddhartha

Re: Replicating directories - Intercepting write/modify system calls

[Akshat Aranya]

If you're doing kernel development, and fall in the 99.9% category of 
people who crash and burn, it would be wise to use VMWare 
(www.vmware.com).  It saves a lot of trouble.  It lets you mess around 
with the kernel as much as you want.  You can save snapshots of the 
state of the virtual machine before you run the new code, and just 
revert to the snapshot if you crash.  However, the snapshot facility is 
really useful only if you're writing kernel modules and not modifying 
kernel proper.

-Akshat Aranya

Siddhartha Jain wrote:
> Apart from this, how do I keep my filesystems sane between kernel crashes? I
> mean once I start playing with the kernel (that too with stuff like
> sys_open, sys_write), there will be several crashes.
> 
> There has to be a way other than re-installing the OS over and over again.
> Right?
> 
> TIA,
> 
> Siddhartha
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

Re: Replicating directories - Intercepting write/modify system calls

[Herbert Poetzl]

On Fri, Feb 13, 2004 at 10:11:32AM -0500, Akshat Aranya wrote:
> If you're doing kernel development, and fall in the 99.9% category of 
> people who crash and burn, it would be wise to use VMWare 
> (www.vmware.com).  It saves a lot of trouble.  It lets you mess around 
> with the kernel as much as you want.  You can save snapshots of the 
> state of the virtual machine before you run the new code, and just 
> revert to the snapshot if you crash.  However, the snapshot facility is 
> really useful only if you're writing kernel modules and not modifying 
> kernel proper.

or even better use QEMU or bochs, which are free
and in some aspects better suited for testing ...

best,
Herbert

> -Akshat Aranya
> 
> Siddhartha Jain wrote:
> >Apart from this, how do I keep my filesystems sane between kernel crashes? 
> >I
> >mean once I start playing with the kernel (that too with stuff like
> >sys_open, sys_write), there will be several crashes.
> >
> >There has to be a way other than re-installing the OS over and over again.
> >Right?
> >
> >TIA,
> >
> >Siddhartha
> >
> >-
> >To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> >the body of a message to majordomo@vger.kernel.org
> >More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> >
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Replicating directories - Intercepting write/modify system calls

[Nir Tzachar]

hello there.

there is yet another approach you can take. are you familiar with the 
fistfs project? (http://www.filesystems.org/)

the idea is stacking a new file system on top of another. 
basically, you build a new _virtual_ file system, which propagates changes 
to the lower one (in ur case, the lower ones, since u will stack on top of 
2 file systems...). 

let me describe a simple example. suppose you want to replicate dir 
/dir/to/be/replicated to /dir/to/replicate/to. to achieve a one way 
replication scheme you can do smth like that (once you have written the 
code though ... ;) ):

[ insert ur file system module ]:
insmod my_filesystem source=/dir/to/be/replicated dest=/dir/to/replicate/to

[ and now mount ur dir on the original dir]:
mount -t my_filesystem none /dir/to/be/replicated 

from now on, all operations performed on the _virtual_ tree located at the 
new mount point /dir/to/be/replicated will be propagated to the _real_ 
/dir/to/be/replicated and to /dir/to/replicate/to. voila ;)


the fist project provides automated tools for creation of such file 
systems, however i have coded a parasitic file system b4 (without using 
fist.. ) which takes over a different file system
(http://www.cs.bgu.ac.il/~srfs ) 


p.s all of the above is just an idea, u will have to code it urself to 
make it work though ... ;)




-- 
========================================================================
nir.