In article <200605041855.UAA0000002017@zel459.zel.kfa-juelich.de>,
Matthias Drochner  <M.Drochner@fz-juelich.de> wrote:
>
>nblists@anastigmatix.net said:
>> It may be something changed in option handling
>
>Don't know whether this is related to the mfs problem, but there
>was a change a while ago to mount argument verification which has
>strange side effects. I only could observe this in conjunction with
>the "getargs" option however:
>
>$ /sbin/mount | grep wd0a
>/dev/wd0a on / type ffs (soft dependencies, local)
>$ mount_ffs -o getargs /dev/wd0a /
>[no output, this is OK here]
>$ mount_ffs -o getargs,rw /dev/wd0a /
>$ mount_ffs -o getargs,ro /dev/wd0a /
>mount_ffs: /dev/wd0a on /: incorrect super block
>[this is nonsense]
>$ mount_ffs -o getargs,update /dev/wd0a /
>mount_ffs: /dev/wd0a on /: specified device does not match mounted device
>[nonsense too]
>
>One might argue that a combination of "getargs" with something
>else doesn't make sense. Historic behaviour is however that the
>kernel ignores other flags if "getargs" is set.

It is the result of this:

1.218        (yamt     06-Apr-05):      /*
1.218        (yamt     06-Apr-05):       * if MNT_GETARGS is specified, it shoul
d be only flag.
1.218        (yamt     06-Apr-05):       */
1.218        (yamt     06-Apr-05):
1.218        (yamt     06-Apr-05):      if ((SCARG(uap, flags) & MNT_GETARGS) !=
 0 &&
1.218        (yamt     06-Apr-05):          (SCARG(uap, flags) & ~MNT_GETARGS) !
 = 0) { 
1.218        (yamt     06-Apr-05):              return EINVAL;
1.218        (yamt     06-Apr-05):      }