If mount a local file(disk) in two different dirctories, it is similar to the network storage. Detecting identical "files" is still a problem. Such as: dd if=/dev/zero of=aa bs=1M count=10 mkfs.ext4 aa Then mount aa to two directories. mount aa /mnt/dir1 mount aa /mnt/dir2 # tune2fs -l aa tune2fs 1.42.5 (29-Jul-2012) Filesystem volume name: <none> Last mounted on: <not available> Filesystem UUID: bb095a44-e896-4949-b5f4-9d9468a7178e Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super huge_file uninit_bg dir_nlink extra_isize Filesystem flags: signed_directory_hash Default mount options: user_xattr acl Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 2560 Block count: 10240 Reserved block count: 512 Free blocks: 8795 Free inodes: 2549 First block: 1 Block size: 1024 Fragment size: 1024 Reserved GDT blocks: 39 Blocks per group: 8192 Fragments per group: 8192 Inodes per group: 1280 Inode blocks per group: 160 Flex block group size: 16 Filesystem created: Mon Dec 9 14:00:46 2013 Last mount time: Mon Dec 9 14:01:35 2013 Last write time: Mon Dec 9 14:01:35 2013 Mount count: 2 Maximum mount count: -1 Last checked: Mon Dec 9 14:00:46 2013 Check interval: 0 (<none>) Lifetime writes: 1150 kB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 128 Journal inode: 8 Default directory hash: half_md4 Directory Hash Seed: efe7990e-1414-4ede-9488-4f4d369fe7f5 Journal backup: inode blocks --- Can create the same file in /mnt/dir1 and /mnt/dir2. ----- For network storage, usually mounted via FuseFS(such as glusterfs). Can not check file identity when mount in more than a directory. So maybe it is the same as the network storage file.
Best wishes, Jun Li 2013/11/18 Stefan Hajnoczi <stefa...@gmail.com> > On Fri, Nov 15, 2013 at 10:21:40AM -0700, Eric Blake wrote: > > On 11/15/2013 09:42 AM, Max Reitz wrote: > > > > > Actually, the same problem can occur anyway if you have a path with a > > > couple of “.” and “..” in it – or even just a hardlink. Thus, to be > > > completely safe, we'd have to check whether the snapshot file (if it > > > already exists) has a different inode number and/or is located on a > > > different filesystem. > > > > See also the recent thread on detecting backing file loops - this should > > be part of that solution (if it isn't already): > > https://lists.gnu.org/archive/html/qemu-devel/2013-11/msg01840.html > > > > > > Backing file loops might get away with string-only detection; but then I > > start to worry that the string-only detection will misbehave on relative > > paths (consider: /dir1/a <- /dir1/b [backed by relative 'a'] <- /dir2/a > > [backed by absolute /dir1/b] <- /dir2/a [backed by relative 'a']); > > devno/inode pairs are the only reliable to detect loops when only the > > filesystem is involved, but then you also introduce network protocols > > (and there, it's worse: gluster://host1/vol/img and > > gluster://host2/vol/img could be the same file, if host1 and host2 are > > part of the same storage cluster, but there is no devno/inode to tell > > you that). > > Detecting identical "files" is not a problem that can be solved in the > general case. Once network storage comes into play we don't have the > ability to check file identity. > > Users can misconfigure QEMU if they try hard enough. Filename string > manipulation is very error-prone and I'd rather just avoid it than > provide a false sense of security. > > What's the real use case for this patch? > > Stefan >
