On Wed, 30 Jan 2008, Troy Dawson wrote:

<snip>
>>  I had checked by ftp (same answer) but when I just looked again the files
>>  seem to be back again.
>>
>>  Hopefully it isn't just that one of N servers has bad data.
>>
>>  If someone fixed it in the meantime then many thanks.
>>
>>    -- Jon
>
> Hi Jon,
> This is an issue we are working on.  We believe it is an NFS client issue. 
> That was the reason rsync.scientificlinux.org was rebooted a couple of weeks 
> ago.  But the kernel put in then didn't fix it.
> We're going to try the new kernel from RedHat, which fixed some NFS issues, 
> and might fix this one.

If you mean SL5 then the TUV announcement only mentions one about umounts 
crashing #414041, but they may have sneaked something else in too...

> Anyway, the symptom is that a bunch of files suddenly dissapear.  Most 
> always, they are in alphabetical order (your's happen to be the f's I see).
> They come back after some time.
>
> The reason we think it is an NFS client issue, is because we are able to look 
> at the back end with other clients and still see the files.
>
> We're also going to soon switch rsync.scientificlinux.org to a new machine. 
> We're getting it ready right now.

I've altered my scripts to no longer use the --delete option when talking 
to rsync.scientificlinux.org at least for now...

Hopefully that won't cause any big problems except maybe with 
intentionally transient files (eg while you are copying bits into 
place...)

btw it wasn't one contiguous block (alphabetically) which went missing, at 
least not unless it has a crazy sort order!

We couldn't see firefox but firefox-devel was ok, all but three of the 
files starting with fonts, freeglut and some of the fuse* packages (maybe 
a few more).  Could they be contiguous in the order they appear in the 
directory?

  -- Jon