> > b) 1 pool for read access + 1 for writing:
> > clearly, if you got updates of files in the writing pool, then the read
> > pool would have its cache not up-to-date and you will have to find a
> > mechanism to update it. It could be done using xrdcp.
> I think that a combined r/w + ro pool can be done as described above, with
> the caveat that a command would have to be run explicitly to trigger a
> stage-out. This is probably sufficient for the user areas. (True production
> areas could of course have automated migration to MSS as they like as long
> they are willing to say "once I drop the file in it can be considered r/o".)
> Comments? (From anyone.)
In our case of r/o files, we may even stage out files automatically and
let user's publish collections ion the bookkeeping. With the
amount of users activity, we can easily affod archiving
everything they produce. Otherwise who will do cleaning out of files
that users chose not to stage out and publish?