RFC - named loop devices...

RFC - named loop devices...

[Ian Molton]

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?

Re: RFC - named loop devices...

[Frank Schaefer]

On Tue, 2002-05-21 at 02:55, Ian Molton wrote:
> 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

Re: RFC - named loop devices...

[Denis Vlasenko]

On 20 May 2002 22:55, Ian Molton wrote:
> 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 have such symlink!

> 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?

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

Re: RFC - named loop devices...

[Ian Molton]

On Tue, 21 May 2002 17:11:34 -0200
Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua> wrote:

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

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

me too. :-)

Re: RFC - named loop devices...

[Russell King]

On Thu, May 23, 2002 at 06:01:05PM +0100, Ian Molton wrote:
> On Tue, 21 May 2002 17:11:34 -0200
> Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua> wrote:
> 
> > > I was wondering if a solution to this would be to introduce 'named'
> > > loopback devices.
> 
> > Have no time to think about this now, but will test any patches -
> > I want /etc/mtab -> /proc/mounts to become standard practice
> 
> 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 (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: RFC - named loop devices...

[jw schultz]

On Thu, May 23, 2002 at 06:04:53PM +0100, Russell King wrote:
> On Thu, May 23, 2002 at 06:01:05PM +0100, Ian Molton wrote:
> > On Tue, 21 May 2002 17:11:34 -0200
> > Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua> wrote:
> > 
> > > > I was wondering if a solution to this would be to introduce 'named'
> > > > loopback devices.
> > 
> > > Have no time to think about this now, but will test any patches -
> > > I want /etc/mtab -> /proc/mounts to become standard practice
> > 
> > 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.
> 
[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:		jw@pegasys.ws

		Remember Cernan and Schmitt