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.
So, can you see if you are getting a message about running recovery
during bootup:
XFS mounting filesystem sd(8,1)
XFS: WARNING: recovery required on readonly filesystem.
XFS: write access will be enabled during mount.
Starting XFS recovery on filesystem: sd(8,1) (dev: 8/1)
Ending XFS recovery on filesystem: sd(8,1) (dev: 8/1)
This should not happen after a clean shutdown. If this is happening,
then is it possible to bring a system up on a different root, or in
some other way run xfs_logprint -t on the filesystem before it is
mounted again?
Steve
--
Steve Lord voice: +1-651-683-3511
Principal Engineer, Filesystem Software email: lord@xxxxxxx
|