multi xfs support

[Assar Westerlund]

Marek Kowal <tomcat at fatcat.desy.de> writes:
> 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.

Well, what's real is what's in the source.  But we're happy to offer
you our - hopefully more digestible - interpretation of these
sources. :-)

> 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.

Ok.

> 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.

That's probably a problem, see later.

> 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?

Arlad is the one responsible for 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).

Unfortunately xfs fetches the data with kernel calls.  So arlad tells
xfs that this file resides in the local file with the file handle or
this file name and then xfs just accesses the data in whatever way it
wants.  The reason for this is of course to avoid having all the
read/write operations go through arlad.

I wonder what would be the easiest way of solving this.

Do you have any reference to the RFIO protocol?

/assar