To add a bit more information, someone (sorry, didn't catch the name)
suggested that we check /proc/mounts. Lo and behold /proc/mounts does in
fact have the correct setup (as opposed to what mount|/etc/mtab reports).
root@bloodhound:/mnt# mount
/dev/sda1 on / type ext2 (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
none on /proc type proc (rw)
/dev/vg00/lvol1 on /mnt/lvol1 type ext2 (rw)
/dev/vg00/lvol1 on /mnt/lvol1-two type ext2 (ro) <-- note ro
root@bloodhound:/mnt# cat /proc/mounts
none / shm rw 0 0
none socket: sockfs rw 0 0
none pipe: pipefs rw 0 0
none / proc rw 0 0
none / devpts rw 0 0
/dev/root / ext2 rw 0 0
none /dev/pts devpts rw 0 0
none /proc proc rw 0 0
/dev/vg00/lvol1 /mnt/lvol1 ext2 rw 0 0
/dev/vg00/lvol1 /mnt/lvol1-two ext2 rw 0 0 <-- note rw
for those who didn't read the prev post, I was doing a mount -t ext2
/dev/vg00/lvol1 /mnt/lvol1 && mount -t ext2 -o ro /dev/vg00/lvol1
/mnt/lvol1-two, which should make /mnt/lvol1-two RO, but in practice does
not.
So are we looking at a bug in mount? And what is the proper behavior for
the bind & multi mounts? Should either allow me to change from rw to ro on
the 2nd mount?
Any information would be appreciated,
-b
On Wed, 12 Jul 2000, Brian Poole wrote:
> G'day everyone,
>
> Here is the setup..
> 2.4.0-test3, mount 2.10m
>
> didn't see anything about this in the pre patches and the mount should be
> the latest.
>
> And the problem..
>
> root@bloodhound:/mnt# mount -t bind -o ro / /mnt/root-two/
> root@bloodhound:/mnt# mount
> /dev/sda1 on / type ext2 (rw)
> none on /dev/pts type devpts (rw,gid=5,mode=620)
> none on /proc type proc (rw)
> / on /mnt/root-two type bind (ro)
> root@bloodhound:/mnt# touch root-two/file
> root@bloodhound:/mnt# rm root-two/file && umount root-two
>
> Hrmf, it is reported as ro, but obviously does not work this way..
> Identical behavior occurs when a multimount is done w/ the root
> partition..
>
> root@bloodhound:/mnt# mount -o ro /dev/sda1 /mnt/root-two/
> root@bloodhound:/mnt# mount
> /dev/sda1 on / type ext2 (rw)
> none on /dev/pts type devpts (rw,gid=5,mode=620)
> none on /proc type proc (rw)
> /dev/sda1 on /mnt/root-two type ext2 (ro)
> root@bloodhound:/mnt# touch root-two/file
> root@bloodhound:/mnt# rm root-two/file && umount root-two
>
> it should be noted that the -o option itself isn't broken, it still works
> if it is the first mount, just not when the partition/dir is already
> mounted as rw. yet another example to show this to be the truth..
>
> root@bloodhound:/mnt# mount -o ro /dev/vg00/lvol1 /mnt/lvol1
> root@bloodhound:/mnt# mount -t bind -o ro /mnt/lvol1 /mnt/lvol1-two
> root@bloodhound:/mnt# touch /mnt/lvol1
> touch: /mnt/lvol1: Read-only file system
> root@bloodhound:/mnt# touch /mnt/lvol1-two/
> touch: /mnt/lvol1-two/: Read-only file system
> root@bloodhound:/mnt# umount lvol1-two/
> root@bloodhound:/mnt# mount -o rw /dev/vg00/lvol1 /mnt/lvol1-two
> root@bloodhound:/mnt# touch lvol1-two/file
> touch: lvol1-two/file: Read-only file system
>
> if this is a feature (not allowing the options to change between the two)
> mount should error out with 'unable to set $opt' or similar IMHO, to keep
> people from believing they have successfully mounted w/ the options, when
> it apparently doesn't work.
>
> if it is a real bug, well there she is, enjoy!
>
> and of course if it is somehow my mistake, sorry :)
>
>
> -b
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jul 15 2000 - 21:00:17 EST