RFC - named loop devices...

I havent thought about this too much, but...

When /etc/mtab is a symlink to /proc/mounts the umount command will fail to unmount loopback mounted filesystems properly.

I was wondering if a solution to this would be to introduce 'named' loopback devices.

with named loop devices, umount will then know that mount was the creator of a loopback device that it mounted, and can safely destroy it.

at present, mounting and unmounting disc images causes one to run out of loopback devices rather rapidly.

If I were to knock up a patch to implement named loop devices, would it stand a chance of being accepted?

also, how should this work? should the name be that of the creating process or should it just be a field that the creator can fill in as it pleases?

What about losetup?

Regards
Frank

I have such symlink!

Have no time to think about this now, but will test any patches - I want /etc/mtab -> /proc/mounts to become standard practice --
vda

me too. :-)

/proc/mounts and /etc/mtab contain different information. /etc/mtab can contain what ever information a user space app needs. /proc/mount can't. See the following as a perfect example, specifically the automount and NFS entries.

Also, remember that mount uses /etc/mtab to perform synchronisation between two concurrent mount requests for the same device/resource.

/etc/mtab:

/dev/hda3 / ext2 rw,noatime 0 0
proc /proc proc rw 0 0
pts /dev/pts devpts rw,gid=5,mode=620 0 0
/dev/hda4 /usr ext2 rw,noatime 0 0
/dev/hda5 /var ext2 rw,noatime 0 0
/dev/hda7 /usr/src ext2 rw 0 0
/dev/hda1 /mnt/adfs adfs rw,gid=501,ownmask=770,othmask=077 0 0
automount(pid440) /net/flint autofs rw,fd=5,pgrp=440,minproto=2,maxproto=3 0 0 automount(pid474) /net/sturm autofs rw,fd=5,pgrp=474,minproto=2,maxproto=3 0 0 automount(pid504) /net/tika autofs rw,fd=5,pgrp=504,minproto=2,maxproto=3 0 0 flint:/home/users /net/flint/users nfs rw,rsize=4096,wsize=4096,timeo=10,retrans=4,addr=195.xx.xxx.xx 0 0 tika:/usr/src/v2.5 /net/tika/v2.5 nfs rw,rsize=4096,wsize=4096,timeo=10,retrans=4,addr=195.xx.xxx.xx 0 0

/proc/mounts:

/dev/root / ext2 rw,noatime 0 0
/proc /proc proc rw 0 0
pts /dev/pts devpts rw 0 0
/dev/hda4 /usr ext2 rw,noatime 0 0
/dev/hda5 /var ext2 rw,noatime 0 0
/dev/hda7 /usr/src ext2 rw 0 0
/dev/hda1 /mnt/adfs adfs rw 0 0
automount(pid440) /net/flint autofs rw 0 0
automount(pid474) /net/sturm autofs rw 0 0
automount(pid504) /net/tika autofs rw 0 0
flint:/home/users /net/flint/users nfs rw,v2,rsize=4096,wsize=4096,hard,udp,lock,addr=flint 0 0 tika:/usr/src/v2.5 /net/tika/v2.5 nfs rw,v2,rsize=4096,wsize=4096,hard,udp,lock,addr=tika 0 0

Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

[snip]

It is clear to me that what really needs to happen is to retire /etc/mtab. It seems to be the last file in /etc that needs to be written. Mount, df and others need to look elsewhere and we might need a syscall (if it doesn't exist) to support umount and root pivoting when not even proc is mounted. It might be a pain to coordinate but should be worth it.

________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		[email protected]

		Remember Cernan and Schmitt