Re: mount inconsistencies
On 5/12/14 8:52 AM, "Jochen Spieker" <ml@well-adjusted.de> wrote:
>Hi folks,
>
>this looks very weird to me. My wheezy system claims that a filesystem
>is mounted, but the mount directory appears to be empty and umount fails
>because the filesystems is not mounted, after all:
>
>| # grep backup /etc/fstab
>| /dev/mapper/backup-decrypted /srv/backup ext4
>noatime,nodiratime,barrier=1,noauto,nodelalloc 0 0
>|
>| # mount | grep backup
>| /dev/mapper/backup-decrypted on /srv/backup type ext4
>(rw,noatime,nodiratime,nodelalloc,data=ordered)
>|
>| # df -h /srv/backup/
>| Filesystem Size Used Avail Use% Mounted on
>| /dev/mapper/backup-decrypted 2.5T 1.8T 699G 72% /srv/backup
>|
>| # ls -la /srv/backup/
>| total 8
>| drwxr-xr-x 2 root root 4096 Oct 21 2011 ./
>| drwxr-xr-x 11 root root 4096 Oct 22 2013 ../
>|
>| # umount /srv/backup
>| umount: /srv/backup: not mounted
>
>I don't think it's important, but the filesystem is encrypted using LUKS
>on top of an LVM volume:
>
>| # grep backup /etc/crypttab
>| backup-decrypted /dev/mapper/backup2-lvol0 none
> noauto,luks,cipher=aes-cbc-plain:sha256
>
>Interestingly, when I mount /srv/backup again, I can see its contents
>and umount it afterwards. But only once. Complete transcript:
>
>| # mount /srv/backup/
>|
>| # ls /srv/backup/
>| abattoir/ abattoir-winxp/ cupcake/ jigsaw/ lost+found/ mail/
>manowar/ _manual/ xenhost/
>|
>| # mount | grep backup
>| /dev/mapper/backup-decrypted on /srv/backup type ext4
>(rw,noatime,nodiratime,nodelalloc,data=ordered)
>| /dev/mapper/backup-decrypted on /srv/backup type ext4
>(rw,noatime,nodiratime,nodelalloc,data=ordered)
>|
>| # umount /srv/backup
>|
>| # umount /srv/backup
>| umount: /srv/backup: not mounted
>
>Do you have any ideas what's wrong?
>
>Regards,
>J.
>--
>I will not admit to failure even when I know I am terribly mistaken and
>have offended others.
>[Agree] [Disagree]
> <http://www.slowlydownward.com/NODATA/data_enter2.html>
>
Has your system recently crashed, or had to be powered down forcefully?
The contents of /etc/mtab may be out of date and reporting conditions that
existed before a forced power down.
On the other hand, if /etc/mtab is a symlink to /proc/mounts, it should be
current.
If /etc/mtab is not a symlink, you may want to make it so.
You can also look at /proc/mounts directly and see what it says.
I'm not sure if any of this will actually help explain any root causes,
but may point in the right direction.
Bob
Reply to: