public inbox for util-linux@vger.kernel.org
 help / color / mirror / Atom feed
From: Phillip Susi <psusi@ubuntu.com>
To: util-linux@vger.kernel.org
Subject: Fwd: Bug#747948: mount: should warn user when potentially incorrect fstab order
Date: Tue, 13 May 2014 08:59:42 -0400	[thread overview]
Message-ID: <5372173E.7090002@ubuntu.com> (raw)
In-Reply-To: <20140513100450.GA1083@europecamions-interactive.com>


[-- Attachment #1.1: Type: text/plain, Size: 59 bytes --]

Forwarding this request from debian to get your thoughts.

[-- Attachment #1.2: Bug#747948: mount: should warn user when potentially incorrect fstab order.eml --]
[-- Type: message/rfc822, Size: 12155 bytes --]

[-- Attachment #1.2.1.1: Type: text/plain, Size: 4244 bytes --]

Package: mount
Version: 2.20.1-5.3
Severity: wishlist

Hello, there.

Firstly, tl;dr: mount should warn when interlocked mountpoints in fstab
aren't in the expected order.

I recently noticed what at first seemed a bug in mount management of
fstab, but, according to the french mailing list users, it's more a lack
of warning.

Here is the problem: currently, at start, filesystems referenced in
fstab are mounted following their order in fstab. The problem is, when
/etc/fstab contains config for two filesystems with interlocked
mountpoints, in my case /var/www and /var/www/cache, they are not
necessarily in the right order. In my example, because of limitations in
my hosting provider installer and my drive configuration, /var/www/cache
configuration was stored before /var/www's one. Because man mount did
not contained any warning regarding mountpoints order, I assumed this
was automagically managed at start; of course, it proved me wrong, as
you can see in the following command dump taken after a reboot:

david@Curunir:~$ df -h
Sys. fich.    Taille Util. Dispo Uti% Monté sur
rootfs           54G  3,1G   49G   6% /
udev             10M     0   10M   0% /dev
tmpfs            13G  328K   13G   1% /run
/dev/md1         54G  3,1G   49G   6% /
tmpfs           5,0M     0  5,0M   0% /run/lock
tmpfs            35G     0   35G   0% /dev/shm
/dev/md3         20G  233M   19G   2% /var/log
/dev/md4        1,7T  852M  1,6T   1% /var/www/cache
/dev/md6         99G  188M   94G   1% /home
/dev/md7        1,7T  852M  1,6T   1% /var/www
tmpfs            32G     0   32G   0% /tmp
david@Curunir:~$ sudo su
[sudo] password for david: 
root@Curunir:/home/david# umount /dev/md4
umount: /var/www/cache: not mounted
root@Curunir:/home/david# mount /dev/md4
root@Curunir:/home/david# df -h
Sys. fich.  Taille Util. Dispo Uti% Monté sur
rootfs         54G  3,1G   49G   6% /
udev           10M     0   10M   0% /dev
tmpfs          13G  328K   13G   1% /run
/dev/md1       54G  3,1G   49G   6% /
tmpfs         5,0M     0  5,0M   0% /run/lock
tmpfs          35G     0   35G   0% /dev/shm
/dev/md3       20G  233M   19G   2% /var/log
/dev/md4      124G  188M  118G   1% /var/www/cache
/dev/md6       99G  188M   94G   1% /home
/dev/md7      1,7T  852M  1,6T   1% /var/www
tmpfs          32G  4,0K   32G   1% /tmp
/dev/md4      124G  188M  118G   1% /var/www/cache

As you can see, in this case, the mounting of /var/www/cache behaves
erratically when its configuration is placed before /var/www's one in
/etc/fstab. When I noticed this problem, I checked all system logs, but
none showed messages regarding the mountpoints order, so I suspected a
failed disk, but my hosting provider's checks did not show any problem,
no more than fsck -f. I almost reinstalled the system, but, at the last
moment, I thought of fstab and changed mountpoints order to place
/var/www before /var/www/cache, and, after a reboot, the problem was
solved.

I mailed yesterday the Debian french users mailing list about this
problem, which I thought of as a bug, but they explained me that, under
some conditions, this behaviour may prove helpful. Nevertheless,
I still think that mount should warn about this most likely unwanted
behaviour, both in its manpage and by logging warnings in dmesg or syslog,
in order to help users confronted to this problem. At first, I expected
mount to reject such a mountpoint order to avoid problems, but, if I'm
right, it should be a bit extreme and bother users who uses this
behaviour to their advantage.

So, I would like to request the addition in mount of a warning when it
tries to mount a filesystem whose mountpoint contains an already used
mountpoint in order to avoid confusion for filesystem administation.
This warning should be printed on stderr, if not in dmesg and syslog, to
allow the admin to correct mountpoints order in the most likely case the
current behaviour is not the expected one.

Thanks for reading.

Regards.
-- 
David Guyot
Administrateur système, réseau et télécommunications / Sysadmin
Europe Camions Interactive / Stockway
Moulin Collot
F-88500 Ambacourt
Tel: +33 (0)3 29 30 47 85
Fax : +33 (0)3 29 31 31 31

[-- Attachment #1.2.1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 553 bytes --]

       reply	other threads:[~2014-05-13 12:59 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20140513100450.GA1083@europecamions-interactive.com>
2014-05-13 12:59 ` Phillip Susi [this message]
2014-05-26 10:24   ` Fwd: Bug#747948: mount: should warn user when potentially incorrect fstab order Karel Zak
2014-05-26 14:16     ` Phillip Susi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5372173E.7090002@ubuntu.com \
    --to=psusi@ubuntu.com \
    --cc=util-linux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox