On Tue, Mar 16, 2010 at 10:23:38AM +0100, Miklos Szeredi wrote:
> On Tue, 2010-03-16 at 04:29 -0400, Christoph Hellwig wrote:
> > On Mon, Mar 15, 2010 at 05:32:48PM +0100, Karel Zak wrote:
> > > The problem with this feature is that mount(2) syscall allows to use
> > > regular files (or whatever) as the source argument. The interpretation
> > > of the source argument completely depends on filesystem driver. So you
> > > can create FS that is able to mount regular files...
> > >
> > > This is reason why we should not automatically create loop devices for
> > >
> > > mount -t foo disk.img /mnt
> > >
> > > because we know nothing about 'foo'. It means that the feature will
> > > be used only when fylesystem type is not specified, for example:
> > >
> > > mount disk.img /mnt
> > >
> > > I guess it's 99% of all use cases. Thanks to Miklos for his comments.
> >
> > Honestly I think doing this is broken. I've done tons of custome one
> > filesystems for customers that just mount a regular file to implement
> > weird semantics I didn't want to throw into a character driver, and
> > it's also possible to do mount --bind or similar namespace manipulation
> > on every type of file
>
> Right, the patch needs some more thought, but I don't think detecting if
> loopback mount is needed is fundamentally broken.
>
> Ideally, if mount can guess the filesystem type and it knows that it
> needs a block device then automatically setting up a loop device should
> be perfectly fine.
Fixed & pushed.
All filesystems in libblkid need a block device, so we can use the
library (blkid_known_fstype() function) to check that the automatic
loop device initialization makes sense. It means:
# mount disk.img /mnt --> creates a loop-dev
# mount -t ext4 disk.img /mnt --> creates a loop-dev
# mount -t foo disk.img /mnt --> calls mount(2) for the file
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
