Matt, Stephen, Sam, Wahid, Alessandra, Mark, Brian, Jens, Ewan


And apologies for the EVO bookings confusion - seems to be caused
by Panda trouble (wrong Panda?)


1. Check the integrity of files stored in the SE
2. Consistency of files with catalogue - OK
3. Consistency of files an external checksum (catalogue)
   - syncat can choose to include checksums, but it may not be
     used.
4. Check file transfer, write - OK, done by FTS
5. Check file transfer, write - OK, done by FTS

Shallow checksum for transfer into SE is successful (write)

Can be calculated from the transfer (which is what everything does),
or from the file which has just been written (reread from disk)

Shallow checksum also for checking that the file is still the one which
was received.

Need a deep checksum for checking against the shallow one - then we
can cope with using the shallow checksums against the external checksum
because the SE is doing its own integrity checking.

Tier 1 has a script which checks all new files written to a server,
and one which picks a small number of random files which checks them.
This is against the CASTOR nameserver checksum and the physical
file.  It may be using xroot, not RFIO.

DPM toolkit - copying binaries which can do ADLER32 checksums to disk
servers to do checksums there - Ricardo can't release 32 bit binaries.
Govind reports it may be dependent on the EMI DPM in the actual release.
Sam will clarify with Ricardo.  Checks against the nameserver.  Still
takes a long time.  Would be better as a background task.

Check a random number of files, check recently written files, check
files of a certain age, or check the lot.  In the latter case, it should
run as quickly as possible.  Can in general afford to use CPU on disk
servers.

lcg-get-checksum can do both shallow and deep.  But probably not for
a lot of files.

What happens if a file is corrupted and not discovered on the source SE
and is then transferred by FTS?  Does it fail the transfer, or does it
fail the source?  It fails after the transfer, flagging the source as
corrupt.  Something should check the source checksum


Quick roundup of OGF stuff (will do in more detail later)
- GLUE2 - new schema for storage
- Usage records - StAR to be published
- "Storage cloud solutions" - little uptake
- discussion re data centre certifications
- data workflow
- use of CDMI - 1.02 may become ISO 17826

... couple of other things on NFS/security, archives, etc
[10:02:45] Brian Davies joined
[10:02:51] Stephen Jones joined
[10:03:00] Mark Norman joined
[10:03:04] Sam Skipsey joined
[10:05:21] Stephen Jones Wahid, can you read thos?
[10:06:40] Matthew Doidge joined
[10:06:41] Mark Norman left
[10:09:52] Mark Norman joined
[10:17:07] Jens Jensen dcache also uses adler32
[10:30:29] Stephen Jones Sorry - I've got to go now. Cheers
[10:30:33] Stephen Jones left
[10:32:44] Pete Gronbech joined
[10:37:57] Mark Norman left