difference usaged diskspace between 'du' and 'df'
I'm running solaris8 .
Now on multiple occasions we encountered a relative large (some time hugh) difference between the reported usaged disk space between df and du.
for instance on a filesystem of 20G, du would give about 2G inuse and df, 19 G . df:avail in that case was 1 G.
logging is enabled.
In all the cases like this I had to repeatedly (up to 300 times) do a fsck (rdsk), or do a newfs and a ufsrestore from the mirror, which probably was a bit faster, but still would take several hours, to bring up the system.
Still, what haunts me, is the reason why this corruption accures.
The application runs under root. I'm not at all happy about it, but this isn't my discission.
I've got a feeling this is the greater part of the problem. However I would assume that the ufs-logging would handle this.
The only thing I can think of is that the ufs-logging in this cases turns out to small.
As far as I know there aren't signs off accessive much IO, or is would be a specific type of IO that I'm not formilure with.
How's got experience with the same thing ?
regards,
Helmer
# 1
> I'm running solaris8 .
> Now on multiple occasions we encountered a relative
> large (some time hugh) difference between the
> reported usaged disk space between df and du.
> for instance on a filesystem of 20G, du would give
> about 2G inuse and df, 19 G . df:avail in that case
> was 1 G.
That's normal if you've deleted 17G of files that were still open by an application (log files for instance). Deleting the files removes them from the directory (so du cannot find them), but the files remain allocated on disk.
If that's what's going on, then killing the application or at worst rebooting would return the space.
> logging is enabled.
That shouldn't make any difference.
> In all the cases like this I had to repeatedly (up to
> 300 times) do a fsck (rdsk), or do a newfs and a
> ufsrestore from the mirror, which probably was a bit
> faster, but still would take several hours, to bring
> up the system.
Did you unmount before running fsck? Did it unmount cleanly? Did unmounting and remounting still show the difference?
> Still, what haunts me, is the reason why this
> corruption accures.
Is this behavior still present immediately after mounting the filesystem?
> The application runs under root. I'm not at all happy
> about it, but this isn't my discission.
> I've got a feeling this is the greater part of the
> problem. However I would assume that the ufs-logging
> would handle this.
No. Logging handles certain crash behaviors. It's not a general mechanism to prevent corruption.
--
Darren
