Re: [Qemu-devel] [PATCH] HMP: snapshot_blkdev can not consider //root/sn1 and /root/sn1 as the same file

[jun muzi]

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 <address@hidden>

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