I have an issue with an XFS filesystem on one server where df reports it
as one value (say, 95%, or even 100% full) but the actual total of file
sizes is much less.
df -h:
/dev/sda5 9.8G 8.0G 1.8G 82% /foo
# du -hs /foo
1.6G /foo
The environment on /foo is a little odd and probably has something to do
with the problem.
This filesystem receives a number of largish (100-800MB) datafiles each
day, which are seperated into subdirectories which are rotated daily at
midnight:
Feb 3 00:00 20050201
Feb 2 23:54 20050202
Feb 3 05:50 20050203
Feb 3 00:00 current -> 20050203
Feb 3 00:00 yesterday -> 20050202
The process puts files in "current" and there are lockfiles checked
between the process code and the rotate scripts. That works well enough.
Additionally, a script runs to compress the files after two days (i.e.
they used to be in "yesterday" and now they're a day older). After a
directory is 2 weeks old (+14 days) it is removed entirely.
There are about a dozen subdirectories which are in /foo that are rotated
and compressed like this. The point is, the rotate/compress scripts are
supposed to keep /foo clean, which it does - except df (and other system
calls) think more is used than actually is by the files. So if df says
"100%", and a file tries to copy into here, it will fail, saying it's out
of space.
Interim solution has been to remove subdirectories and compress
yesterday's datafiles manually to give it more apparent space, but that's
becoming less effective over time. When you've deleted everything you can
down to < 1GB and it still says 9GB is used, it's obvious there's a
problem.
I have already tried a xfs_fsr on /foo which has improved the extents used
by some files, but the apparent utilization didn't change.
Anything else I can try before I dump the fs and make a new one?
--
#!/jameel/akari
sleep 4800;
make clean && make breakfast
|