Bug#531371: `mount -o loop' runs out of loop devices
On Sun, Jun 21, 2009 at 01:49:14PM +0100, Roger Leigh wrote: I get the same loopback release with /etc/mtab as a regular file. This may be due to the new kernel or new util-linux in unstable, but it is now freeing the loop devices correctly. It must be in the new util-linux, because it's putting the loop device, rather than the loopback filename, as the source in /etc/mtab such that it always matches /proc/mounts. Previously they differed, and this resulted in the loop device not being freed when the loop device was used. This is no longer the case. (I'm not familiar with the util-linux source, but I can't actually see this change and it /looks/ like it uses the old behaviour, but this may be just a special case for certain use cases. The observed behaviour is what we want though!) Dmitry, can you confirm this on your system? Your bug report shows you are using stable; do you have a system running unstable you can check on (or if anyone else can check this as I have above?) Roger, I've checked in squeeze using 2.6.26 kernel with /etc/mtab linked to /proc/mounts and the loop device is freed according to losetup -a. -- /Dmitry ledes...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531371: `mount -o loop' runs out of loop devices
On Mon, Jun 01, 2009 at 02:19:51PM +1200, Dmitry Maksyoma wrote: `mount -o loop' runs out of loop devices when /etc/mtab is a symlink to /proc/mounts. Just rechecking this issue, and it no longer occurs for me: % uname -a Linux ravenclaw 2.6.30-1-amd64 #1 SMP Sun Jun 14 15:00:29 UTC 2009 x86_64 GNU/Linux % ls -l /etc/mtab lrwxrwxrwx 1 root root 12 2009-06-21 13:29 /etc/mtab - /proc/mounts % dd if=/dev/zero of=/tmp/l1 bs=1024 count=4096 % /sbin/mkfs -t ext2 /tmp/l1 % sudo mount -o loop /tmp/l1 /mnt % sudo losetup -a /dev/loop0: [0011]:175224 (/tmp/l1) % grep /mnt /etc/mtab /proc/mounts /etc/mtab:/dev/loop0 /mnt ext2 rw,relatime,errors=continue 0 0 /proc/mounts:/dev/loop0 /mnt ext2 rw,relatime,errors=continue 0 0 % sudo umount /mnt % sudo losetup -a % grep /mnt /etc/mtab /proc/mounts % I get the same loopback release with /etc/mtab as a regular file. This may be due to the new kernel or new util-linux in unstable, but it is now freeing the loop devices correctly. It must be in the new util-linux, because it's putting the loop device, rather than the loopback filename, as the source in /etc/mtab such that it always matches /proc/mounts. Previously they differed, and this resulted in the loop device not being freed when the loop device was used. This is no longer the case. (I'm not familiar with the util-linux source, but I can't actually see this change and it /looks/ like it uses the old behaviour, but this may be just a special case for certain use cases. The observed behaviour is what we want though!) Dmitry, can you confirm this on your system? Your bug report shows you are using stable; do you have a system running unstable you can check on (or if anyone else can check this as I have above?) Since this was IIRC the only blocker for #494001 (replacing /etc/mtab with a symlink), it looks like this can now go ahead if anyone else can confirm the loop issue is fixed. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Bug#531371: `mount -o loop' runs out of loop devices
Package: mount Version: 2.13.1.1-1 Severity: normal `mount -o loop' runs out of loop devices when /etc/mtab is a symlink to /proc/mounts. I know it's documented in mount(8), but please consider that lenny/squeeze have moved to the setup where /etc/mtab is symlinked (only new Lenny installs though). The changes are documented in the following bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494001. $ls -l /etc/mtab lrwxrwxrwx 1 root root 12 Май 30 23:07 /etc/mtab - /proc/mounts $dd if=/dev/zero of=img bs=10240 count=10 10+0 records in 10+0 records out 102400 bytes (102 kB) copied, 0,000302873 s, 338 MB/s $mkfs.ext2 img mke2fs 1.41.3 (12-Oct-2008) img is not a block special device. Proceed anyway? (y,n) y Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) 16 inodes, 100 blocks 5 blocks (5.00%) reserved for the super user First data block=1 1 block group 8192 blocks per group, 8192 fragments per group 16 inodes per group Writing inode tables: done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 30 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. #losetup -a #ls /dev/loop* /dev/loop0 /dev/loop2 /dev/loop4 /dev/loop6 /dev/loop1 /dev/loop3 /dev/loop5 /dev/loop7 #for i in `seq 1 9`; do echo $i; mount img /mnt/tmp/ -oloop umount /mnt/tmp/; done 1 2 3 4 5 6 7 8 9 mount: could not find any free loop device #losetup -a /dev/loop0: [fd03]:1032215 (/home/ledestin/tmp/img) /dev/loop1: [fd03]:1032215 (/home/ledestin/tmp/img) /dev/loop2: [fd03]:1032215 (/home/ledestin/tmp/img) /dev/loop3: [fd03]:1032215 (/home/ledestin/tmp/img) /dev/loop4: [fd03]:1032215 (/home/ledestin/tmp/img) /dev/loop5: [fd03]:1032215 (/home/ledestin/tmp/img) /dev/loop6: [fd03]:1032215 (/home/ledestin/tmp/img) /dev/loop7: [fd03]:1032215 (/home/ledestin/tmp/img) -- System Information: Debian Release: 5.0.1 APT prefers stable APT policy: (600, 'stable'), (500, 'proposed-updates') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-686 (SMP w/4 CPU cores) Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R) Shell: /bin/sh linked to /bin/bash Versions of packages mount depends on: ii libblkid1 1.41.3-1 block device id library ii libc6 2.7-18 GNU C Library: Shared libraries ii libselinux1 2.0.65-5 SELinux shared libraries ii libuuid1 1.41.3-1 universally unique id library mount recommends no packages. Versions of packages mount suggests: ii nfs-common 1:1.1.2-6lenny1 NFS support files common to client -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
