I am running an Opensuse 11.2 system as a backup file server. Several external hard drives are attached via USB and mounted during boot via the fstab file.
Recently, I noticed the df command showed the root partition being >65% full, while the du command showed the same drive was only about 20% full.
After much investigation, I discovered that some large directories had been created under the /media folder on the root partition that were hidden when the external drives were mounted as directories with the same names under /media. I could only see this when I rebooted with a live CD and mounted the suspect partition without the external drives mounted.
My question - is there a way to examine whether a mounted partition has existing files “hidden” when a separate file system is mounted “on top of it”?
On Sun, 24 Oct 2010 00:36:02 +0530, lakeland419 <lakeland419@no-mx.forums.opensuse.org> wrote:
>
> I am running an Opensuse 11.2 system as a backup file server. Several
> external hard drives are attached via USB and mounted during boot via
> the fstab file.
>
> Recently, I noticed the df command showed the root partition being >65%
> full, while the du command showed the same drive was only about 20%
> full.
>
> After much investigation, I discovered that some large directories had
> been created under the /media folder on the root partition that were
> hidden when the external drives were mounted as directories with the
> same names under /media. I could only see this when I rebooted with a
> live CD and mounted the suspect partition without the external drives
> mounted.
>
> My question - is there a way to examine whether a mounted partition has
> existing files “hidden” when a separate file system is mounted “on top
> of it”?
When you mount a filesystem on a directory /mount-point, you can no longer access files under /mount-point directly. They still exist, but /mount-point now refers to the root of the mounted filesystem, not to the directory that served as a mount point, so the contents of this directory cannot be accessed, at least in this way. For example:
touch /mount-point/somefile
mount /dev/something /mount-point
ls /mount-point/somefile
ls: cannot access /mount-point/somefile: No such file or directory
There are ways to get a merged view of the mounted filesystem and the data that was already present, but you need an extra layer called a union filesystem.
Under Linux, there is a way to see the hidden files. You can use mount --bind to get another view of the filesystem where the mount point is. For example
mount --bind / /other-root-view
You’ll see all the files in the root filesystem under /other-root-view (e.g. /bin/ls will also be accessible as /other-root-view/bin/ls, etc.). In particular, /mount-point will now be accessible as /other-root-view, and since /other-root-view/mount-point is not a mount point, you can see its contents there (e.g. /other-root-view/mount-point/somefile).
du shows the actual usage in means of bytes on the hard disk. df shows how much disk space is allocated. Certain applications like database create large files which may be actually empty, but the disk space is reserved and cannot be used by other files. In case of a 100GB database on a 100GB disk du would show not much usage, but df would show that the disk is full, because no new files could be created there.
While basicaly correct, clever system mangers have a usage for having something in the directory that is to serve as a mountpoint. When you create a file with e.g. the name file-system-not-mounted in that directory, you will be warned when you venture there when the mount failed for some reason.
On 2010-10-23 23:06, please try again wrote:
>
> hcvv;2242767 Wrote:
>> While basicaly correct, clever system mangers have a usage for having
>> something in the directory that is to serve as a mountpoint. When you
>> create a file with e.g. the name -file-system-not-mounted- in that
>> directory, you will be warned when you venture there when the mount
>> failed for some reason.
>
> And you’ll just have to check if this file exists or not rather than
> using mount (which might fail for different reasons). That’s clever
> indeed.
Yes, I use that system - but it is not safe for scripts, it can fail - I mean, I may have forgotten
to create the empty flag file. It is just a visual aid.
This is what I do:
MOUNT=`mount | grep $1`
if test -n "$MOUNT" ; then
echo "mounted"
else
echo "not mounted"
fi
–
Cheers / Saludos,
Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)
Yes, it is primeraly used for a visual aid. You are trying to do something and the system tells you that files are not there… Then, as a last hope before you tell your boss you are unfit for your job, you do a cd to the mountpoint and do an ls. Taraaaaaaaaa! there it is.
But I do use it in a script here at home to see if an NFS mount is done (the server system may be down in our home environment).
On 2010-10-24 21:36, hcvv wrote:
>
> Yes, it is primeraly used for a visual aid. You are trying to do
> something and the system tells you that files are not there… Then, as a
> last hope before you tell your boss you are unfit for your job, you do a
> -cd- to the mountpoint and do an -ls-. Taraaaaaaaaa! there it is.
>
> But I do use it in a script here at home to see if an NFS mount is done
> (the server system may be down in our home environment).
Yes, I did that, too. The problem is that the flag file could be accidentally removed, or that you
forgot to create it. The your script runs. It doesn’t find that file, and it goes ahead, copying
gigabytes of data… on the root partition.
Which is why I say, in scripts test for the mount, not the flag file.
–
Cheers / Saludos,
Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)
Of course, not mounting on top of existing files is ideal. However, in my case I am mounting external USB hard drives used for backing up automatically during the boot process. In some strange cases I cannot reproduce, the mount occasionally fails. In that case, the automatic backup script just creates backup directories on the root file system in the same place that the USB hard drive should have mounted. Next time the system boots and the USB mounts correctly, the problem I inquired about occurs.
This has happened only once in the last 6 months - so it is not a crisis. I was more interested in avoiding the problem in the future
There is another thread around here were the not mounting of the backup device resulted in filling up the root file system to 100% (realy 100%, no 5% leeway left). And that made the system unbootable. Thus: better change your backupscript and test for the mount first.
On 2010-10-28 11:36, hcvv wrote:
>
> There is another thread around here were the not mounting of the backup
> device resulted in filling up the root file system to 100% (realy 100%,
> no 5% leeway left). And that made the system unbootable. Thus: better
> change your backupscript and test for the mount first.
And it was a commercial backup software… Acronis, was it?
I think it ate that 5% because the backup has to run as root.
Another solution, more general, is that the backup program should estimate how much disk space it
could need, and refuse to run (or warn) if it seems there is not enough. Doing this it does not need
to know what to mount.
–
Cheers / Saludos,
Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)
)