Hi Maarten,
[log in to unmask] wrote:
> Indeed, we had plenty of those during the EDG days... :-(
>
> Nowadays we only know 2 scenarios for the file to be able to get corrupted:
>
> 1. The file system filled up - did that happen?
>
> 2. The file system is an NFS - is that the case?
Both aren't true in this case.
[root@rb root]# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda3 68342936 4865428 60005864 8% /
/dev/sda1 77750 26086 47650 36% /boot
none 512652 0 512652 0% /dev/shm
> In any case, the cleanup recipe for this problem:
[...]
Thanks, it worked. Do I have to do anything with the input.fl.BAD file?
> In case neither scenario was true, please tar up /var/edgwl/workload_manager
> and send us the file (gzipped).
Ok, you'll get this out-of-band...
It is interesting that our BDII response & entries became much more stable:
http://goc.grid.sinica.edu.tw/gstat/HG-01-GRNET/BDIINode_Perf_tim_.html
>>PS.
>>Our mysql->lbserver20 database is extremely huge, 640M. Is this expected?
>>[root@rb root]# du -sh /var/lib/mysql/lbserver20/
>>640M /var/lib/mysql/lbserver20
>
>
> You call that huge? How about the test zone RB lxn1188.cern.ch:
>
> 8.4G /var/lib/mysql/lbserver20
I see... are these 8.4 Gbytes of useful information?
Maybe instead of a large physics-related intensive data-processing project,
there is some socio-surveillanco-scientific experiment going on! ;-)
--
echo "sysadmin know better bash than english" | sed s/min/mins/ \
| sed 's/better bash/bash better/' # Yelling in a CERN forum
|