One common way to get into this state is for a process to open and write data into a huge file and continue writing into it while it runs. (Although I didn't remember the kblocks field being 0 in this case.) Then another process removes that file (while it is still being held open by the first process).
In this case, the file data still resides on the disk even though it no longer has a name that appears in the file hierarchy. The file data will not be release until the process that has the file open closes it.
If fsck was run on /dev/md/dsk/d109 (i.e. /opt/mix ) and something had been placed in Lost+Found , wouldn't the ls output shown in post #1 in this thread have to include the directory Lost+Found ? Instead it shows that not even . and .. exist. Something like an
rm -rf /opt/mix
must have been run by root after the filesystem was remounted after the fsck to get something this messed up (and I thought even that should have failed for a mount point).
@Don.....I agree that this is a mess. What puzzles me is that the 'df -k' only shows one mounted filesystem. No sign of the root filesystem!
I also jumped to the conclusion, perhaps incorrectly, that /opt/mix being empty was due to that filesystem failing to mount. There's nothing under the mount point (or shouldn't be) until the filesystem is mounted under it.
I reckon that the 'df -k' is telling lies. The root filesystem has to be mounted otherwise the system wouldn't be up.
Perhaps the root filesystem is full to the extent that the system only just boots and can't mount any non-root filesystems.
What do you think?
---------- Post updated at 10:42 AM ---------- Previous update was at 10:35 AM ----------
I think we need more info here. Is that really the only output from 'df -k' or has it been edited? What files are visible on the root filesystem? Is there anything in Lost+Found on root?