Hi Steve,

Burke, S (Stephen) пишет:
>
> As Owen said, this is not a good solution because you won't be able to read
> the files, the normal replica management tools need to find the SE in the
> information system.

How's that? I need no infosys to query RLS; and RLS records have pretty
explicit SFNs, don't they? globus-url-copy needs no infosys either.

Anyway, I am not really insisting on removing SEs from the infosystem;
but do you know of any LCG tool or method that makes use of the
published free space? And you actually mentioned yourself that what is
published is the overall space, not a per-VO quota. I'm suggesting a
least damaging solution (in my opinion), and I'm willing to discuss
alternatives.

> Also, intrinsically a full SE is not a fatal error any
> more than a full disk on any system, it's just that users need some way of
> dealing with the condition.

A full disk on a system is not a fatal error. I have plenty of them full
sitting around. Just checked, NorduGrid has 17 out of 43 disk SEs
completelly full. You just use the system read-only, which is perfectly
fine for a Storage Element. A full *system* partition is fatal, but I am
sure nobody has storage area and system area on the same partition.

> The free space is published in the information
> system so it should be possible to recognise the situation and deal with it
> in whatever way you like - maybe atlas would actually rather leave the SEs
> full and write new files somewhere else.

This is effectively the situation. If a job fails to write to an SE -
whatever is the reason, - it will eventually store the file wherever it
can be stored. It doesn't use the free space reported in the infosystem,
just a "kamikaze" method :-)

BTW, the reported free space is useless for yet another reason: imagine
there's 10 GB reported free, and 10 jobs read this information
simultaneously (and they do, even more than 10), and duly start
uploading a 2GB file each. Guess what will happen. Right, all will fail.
  Meanwhile, the SE GRIS will time out because the system will get
overloaded with 10 multithreaded transfers, and 10 more jobs will still
see the 2 GB free because this is what will be cached in the BDII. And
so on. Ain't that cool.

> The only reason it can be a problem
> is on systems where all VOs share the space and there are no quotas, so one
> VO can block the others.

So, we can block LHCb and they can block us. We're even ;-)

>   A separate point is the question of reliability. Tier-1s will typically
> commit to a high level of reliability so you can resonably expect that files
> there are safe. Many sites, even ones with large amounts of space, may not
> have much reliability or backup, so if disks crash data may be lost. I'm not
> sure how that can be represented, how do you quantify the likelihood of
> losing data?

Nobody's perfect. A certain person here suggested to have data loss
insurance :-) Smaller is the site, less compensation is to be paid.
Profits from the insurance  company should finance purchase of more
storage hardware. How's that? ;-)

Seriously, I would suggest to change the entire LCG SE model - and the
information system schema. As a SE, only a reasonably reliable facility,
committed for long-term storage, should qualify. SEs should not
necessarily be linked to sites, they should be standalone services
available via GridFTP, SRM, whatever, and register to GIISes
independently on the rest of the site. Thus we will be able to have a
set of sites for running data, and a [different] set of SEs for storing
the results. The disk space local to the site and necessary for its
proper functioning should be renamed and treated as "cache" and must not
be used for long-term data storage. Of course, the "real" SE disk space
may well be cross-mounted on the WNs, it is up to sysadmin's choice.

Oxana