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. > I would strongly suggest to drop this hack, it's really no problem for > the user to add -o loop for loop mounts. Especially as we might replace > the current loop driver with a more flexible one with a different name > in the future, so mount hardcoding loop is not a good thing. That argument is bogus, the kernel will need to provide the old loop API anyway. Thanks, Miklos -- 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
