Sorry for being overly cautious it seems that the srm-dcache site is
slightly non standard. This triggered errors in the dcache install
script due to mount points for pnfs being slightly non standard. We are
sorry to have given a false alert.
We expect that this will not be an issue for automatically installed
sites as no code has changed in this area of the system from previous
releases. I will still be making further investigations anyway.
I still recommend and immediate upgrade. If any sites have issues with
the upgrade or running of dcache please send them in as bug reports.
regards
Owen Synge
On Mon, 26 Mar 2007 14:51:17 +0200
[log in to unmask] wrote:
> I have had an issues reported to me in terms of upgrade when running install.sh
>
> Please be aware that the install.sh script is causing issues for some sites linking to the domain name
>
> eg
>
> /pnfs/fs
> /pnfs/desy.de
>
> and the symlinks in this area. I will let you all know more when I have resolved the issues at desy. This issue was not found in upgrade testing on Friday night,
>
> Sorry to you all, please delay you upgrades until further notices.
>
> Owen Synge
>
>
>
> On Mon, 26 Mar 2007 12:45:18 +0200
> [log in to unmask] wrote:
>
> > Just to note the build, of 1.7.0-32 was did not contain the changes
> > listed on the change log due to a small mistake in our version control
> > usage it was identical to 1.7.0-31 for this reason the change log
> > should be.
> >
> > 1.7.0-31 => 1.7.0-33
> >
> > * added flag "remove-unexisting-entries-on-flush" to turn on file
> > removing
> > * fixed data corruption with multiple streams in e-mode
> > * fixed space miscalculation if restored file bigger than expected
> >
> >
> > 1.7.0-32
> > * internal testing version.
> >
> > Regards to all.
> >
> > Owen Synge
> >
> >
> >
> >
> > On Sat, 24 Mar 2007 20:15:24 +0100
> > "Fuhrmann, Patrick" <[log in to unmask]> wrote:
> >
> > >
> > > Recently one of the LHC Tier I centers reported a significant
> > > amount of corrupted data within its dCache repository. All
> > > this data had been transfered into that site via gsiFtp. The
> > > size of the affected files turned out to be correct.
> > >
> > > To our current knowledge, the signature of this corruption is :
> > >
> > > - gsiFtp PUT, using multiple streams.
> > > - (except for one file) all files have been below 200 MBytes.
> > > - up to now we believe that all of the corrupted files have
> > > been transferred to that site in March.
> > > - only a small portion of the files matching these criteria are
> > > affected.
> > >
> > > After detailed investigation, dCache people could confirm that under
> > > some circumstances, there is a certain likelihood of data corruption
> > > using the dCache gsiFtp protocol implementation with the criteria
> > > listed above.
> > >
> > > The code, we suspect to be responsible for the corruption, hasn't
> > > been touched for the versions the affected site has been upgraded
> > > to, within the last months. Therefor we assume that some environmental
> > > circumstances seem to trigger the misbehavior of our server. This could
> > > possibly be a slightly different ftp client behavior or transfer
> > > timing conditions.
> > >
> > > The code flaw has been fixed and the affected site is running
> > > the fix for more than 48 hours without reporting a single corrupted
> > > file. Statistically, we would have expected some hundreds of corrupted
> > > files without the code fix.
> > >
> > > Thursday, all other LHC Tier I's officially running dCache, have been
> > > informed on possible data corruption but none of them could confirm
> > > this observation yet.
> > >
> > > !!!
> > > !!! We are providing a dCache server version (1.7.0-32) on our web page,
> > > !!! fixing the problem to our current understanding and experience.
> > > !!!
> > >
> > > Timur and his team is working on a dCache ftp server fix, providing extended
> > > sanity checks to better identify and understand the issue. A new
> > > dCache version, having those checks included, should be available
> > > next week. We will keep you updated on this.
> > >
> > >
> > > patrick
|