xfs
[Top] [All Lists]

Re: files in /etc/xinetd.d become 0 byte size

To: Florin Andrei <florin@xxxxxxx>
Subject: Re: files in /etc/xinetd.d become 0 byte size
From: Simon Matter <simon.matter@xxxxxxxxxxxxxxxx>
Date: Wed, 27 Mar 2002 08:41:21 +0100
>received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 8234257306; Wed, 27 Mar 2002 08:41:22 +0100 (CET)
Cc: Juri Haberland <juri@xxxxxxxxxxxxxx>, linux-xfs <linux-xfs@xxxxxxxxxxx>
Organization: Sauter AG, Basel
References: <3C961055.FF5DF9C6@xxxxxxxxxxxxxxxx> <1017176697.16815.21.camel@xxxxxxxxxxxxxxxxxxx> <3CA0E904.1080907@xxxxxxxxxxxxxx> <1017179446.17163.29.camel@xxxxxxxxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
Florin Andrei schrieb:
> 
> On Tue, 2002-03-26 at 13:32, Juri Haberland wrote:
> > Florin Andrei wrote:
> >
> > > It's been a long time since i started to always do "sync; reboot"
> > > instead of just "reboot". I've always felt this is safer.
> > > But you're right, the OS should do that for me, at the right time.
> > > Therefore, i've submitted a bug report to bugzilla.redhat.com:
> > >
> > > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=62025
> >
> > Ahm, Florin, I think that the conclusion of this thread was that even
> > multiple syncs don't help - instead you could just use 'sleep 30'.
> 
> Yes, that's true for this particular bug.
> 
> But the patch that i included in the bug report does sync AND sleep.
> That should cover this bug, and also some other unforeseen bugs.
> Since "sync is cheap" when in runlevel 6, i guess it's a good idea to do
> it anyway. There are so many things that could go wrong during shutdown.
> 
> > 'sleep 30'...
> 
> This should be tunable in /etc/sysconfig/whatever. One is not supposed
> to edit the init scripts to do parameter tuning.
> 
> --
> Florin Andrei
> 
> "Sorry judge, we would like to publish the file formats, but the data is
> not stored in files. It is stored in a database that is an indivisible
> part of the operating system." - a potential future Microsoft excuse

Hi Florin,

When I discovered the bug, I first tried it with sync in the halt
script. Unfortunately it doesn't help. The only thing that helped was to
sleep long enough and magically everything was written where it should.
I don't understand interna of the kernel but it sems that sync does not
ensure data to be written to disk.

Using a script with fuser to determine open files does not help too
because there were no open files. They have been closed immediately
before shutdown but did not get written to disk, only metadata was
written, not data.

The culprit was the remount readonly feature of XFS enabled kernels
which was buggy. It does not apply to ext2/3 filesystems.

The bug is fixed in current CVS as well as in the upcoming 2.4.9-31
based XFS 1.1 release.

-Simon



<Prev in Thread] Current Thread [Next in Thread>