At 10:43 23-9-2003 +0200, Nicolas Kowalski wrote:
Hello.
We have several servers here using XFS filesystems ; they work
perfectly well, except for one of them, reporting a wrong filesystem
space usage. It seems that this filesystem grows everyday since its
installation last July. No reboot has been done since 54 days (and I
would not like to do one, as it is an important production server).
Here are the details:
Linux olan 2.4.21-xfs-olan #1 Wed Jul 30 09:29:56 CEST 2003 i686 unknown
olan:/var# df .
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/sda4 5750784 4388576 1362208 77% /var
olan:/var# du -s
2692296 .
Has anyone an idea of what is wrong ?
Not really, but it seems that after removal of files the information never
seems to get to disk.
I only managed to see this once using a 2.4.20-18-xfs-1.3pre kernel.
It's now running SGI XFS snapshot 2.4.22-2003-09-03_04:09_UTC and the
reboot seemed to clear it as well.
I tried a few options like remounting the filesytem read only which didn't
work. (mount -o remount)
The file I deleted was a 113GB tar file which the system did not pick up.
xfs_repair reported no problems either. I suspect it's a in memory thing
that doesn't get refreshed.
Since xfs_repair reports no problems I suspect a case of metadata flushed
to disk but failing to update the in memory information. Or something like
that anyways.
There are no messages in the system log or dmesg.
Note that you will have to reboot the system before it reaches 100% since
it _will_ error out (I tried this on purpose since it isn't a production box).
So far this was the only one that I observed, the other machines are still
humming along.
I suggest updating to a more recent snapshot or 2.4.22 if you wil.
This was about the same time that the new xfs sync code went in which
changed the way things are flushed out dramatically from the previous
version. I suspect that your version might have a buggy version.
You are probably using a CVS snapshot right?
Cheers
--
Seth
It might just be your lucky day, if you only knew.
|