multi xfs support

[Marek Kowal]

> > > 1. How can I support two different daemons in one system? At my site we
> > > are heavily using AFS (arla, of course!) and therefore I would love to
> > > have possibility to use two daemons at the same time:
> > > - first, arlad, listening on /dev/xfs0 and responding to access to /afs
> > > - second, robotd, listening on /dev/xfs1 and responding to access to
> > > /robot
> > 
> > There should be no problems in the architecture doing this. But its depends
> > on the xfs-implementation if its done right.
> 
> This has been working for some time on *BSD, solaris, and some other.
> The problems that Love alludes to with the Linux xfs has been fixed as
> of a few days ago.  The only minor thing is that you have to use the
> `mount_xfs' binary and not ordinary mount on Linux.  On what platforms
> have you been trying to do this?  If linux, please fetch the current
> source from CVS.
> 

Hello again,

Thanks for quick response to my problem. 

Now I have another question, concerning the cache of the arla. I know I
should find the answer myself in the sources, but they are quite
complicated, so I'd rather hear the "real" truth from you, guys.

The exact setup we plan to have is the following: The filesystem is
visible on /robot directory via the arlad-like daemon - it will work in
exactly the same way as arlad, but will forward calls to our robot
hardware/software.

Trial to open the file will cause the file to be staged from tape -
simple. But: the file will not be staged to local disc (due to resource
bottleneck), but rather to the specially designated machine, called disc
cache manager, located close to the robot. From there only requested parts
of the file (by means of read/write system calls) will be fetched - this
can be easily done by use of RFIO protocol, as designed in CERN or here at
DESY.

So this setup looks similar to the arlad setup - we also have server which
gives us the data and we also have a cache for data - but the cache is
remote and does not reside on local disc. The question is: who actually is
managing the cache? Is it just xfs which expects the cached data to be
located at given inode and goes there by itself, using only kernel calls,
or rather is asks arlad to fetch cached data from disc (then it would be
very easy to support remote cache).

Mind that I do not want to change xfs.o module at all - than I can use
yours every time you do the update. But of course I will have to write my
own daemon, so implementation of cache there would not be too difficult.

Cheers,
Marek.

--------------------------------------
Marek Kowal
tomcat at mail.desy.de
e cache of the arla. I know I
should find the answer myself in the sources, but they are quite
complicated, so I'd rather hear the "real" truth from you, guys.

The exact setup we plan to have is the following: The filesystem is
visible on /robot directory via the arlad-like daemon - it will work in
exactly the same way as arlad, but will forward calls to our robot
hardware/software.

Trial to open the file will cause the file to be staged from tape -
simple. But: the file will not be staged to local disc (due to resource
bottleneck), but rather to the specially designated machine, called disc
cache manager, located close to the robot. From there only requested parts
of the file (by means of read/write system calls) will be fetched - this
can be easily done by use of RFIO protocol, as designed in CERN or here at
DESY.

So this setup looks similar to the arlad setup - we also have server which
gives us the data and we also have a cache for data - but the cache is
remote and does not reside on local disc. The question is: who actually is
managing the cache? Is it just xfs which expects the cached data to be
located at given inode and goes there by itself, using only kernel calls,
or rather is asks arlad to fetch cached data from disc (then it would be
very easy to support remote cache).

Mind that I do not want to change xfs.o module at all - than I can use
yours every time you do the update. But of course I will have to write my
own daemon, so implementation of cache there would not be too difficult.

Cheers,
Marek.

--------------------------------------
Marek Kowal
tomcat at mail.desy.de
--------------------------------------