Steve Lord wrote:
> On Tue, 2002-03-19 at 10:44, Simon Matter wrote:
> n
>>
>> It was on the same partition. I also used to copy the files from
>> /root/xinetd.d/ to /etc/xinetd.d and just rebooted after and no zeros.
>> But I can reproduce it now very easily.
>>
>> ntsysv (en/disabling rsh) ; reboot : gives zeroed files
>> ntsysv (en/disabling rsh) ; sleep 40 ; reboot : is okay.
>>
>> I'm sure ntsysv does something 'interesting' here but from my
>> understanding it should not be possible to damage the FS in such way. It
>> seems to me that somehow bdflush does not update the changes ntsysv did.
>>
>
> ntsysv does a synchronous transaction in the kernel you have - which in
> itself is not a problem. What appears to be happening is that the
> remount readonly is not doing its job, or log recovery is for some
> reason thinking the filesystem was not cleanly unmounted - which
> might (just might) have something to do with the raid1 root partition.
Ok, when you mentioned the SW RAID1 root partition I remembered that I
have a similar box sitting here. It's also a fresh SGI-RH7.2
installation with all updates and all partitions are on a SW-RAID1, but
on SCSI disks, not on IDE disks.
I ran three test like yours (ntsysv (en/disabling time ; reboot)) and
afterwards I still had all files in /etc/xinetd.d with their proper
contents. I also had my .bash_history.
This box runs a 2.4.18-xfs-smp kernel from CVS, checked out on 4th of March.
Simon
what about a recent kernel? 2.4.9-31 is user contributed IIRC. It might
not be a good choice...
Juri
|