Hi! The qcow2 isn't inderneath it, we can assume it's an ordinary file on a filesystem. Its' size was about 300-400 GB, but now size is 7493992262336241664 bytes and I don't understand how it's happened. I'd like to remove it, but I worry about consequences. :( On Mon, Dec 15, 2014 at 09:23:47AM +0000, Steven Whitehouse wrote: > Hi, > > How did you generate the image in the first place? I don't know if > we've ever really tested GFS2 with a qcow device underneath it - > normally even in virt clusters the storage for GFS2 would be a real > shared block device. Was this perhaps just a single node? > > Have you checked the image with fsck.gfs2 ? > > Steve. > > On 15/12/14 09:17, Vladimir Melnik wrote: > >And one more question, > > > >Is it safe to remove this file? What will happen if I try to run 'rm > >/mnt/sp1/ac2cb28f-09ac-4ca0-bde1-471e0c7276a0.bak', won't it corrupt > >other files? > > > >Thanks. > > > >On Sat, Dec 13, 2014 at 06:04:48PM +0200, Vladimir Melnik wrote: > >>Dear colleagues, > >> > >>I encountered some very strange issue and would be grateful if you share > >>your thoughts on that. > >> > >>I have a qcow2-image that is located at gfs2 filesystem on a cluster. > >>The cluster works fine and there are dozens of other qcow2-images, but, > >>as I can see, one of images seems to be corrupted. > >> > >>First of all, it has quite unusual size: > >>>stat /mnt/sp1/ac2cb28f-09ac-4ca0-bde1-471e0c7276a0.bak > >> File: `/mnt/sp1/ac2cb28f-09ac-4ca0-bde1-471e0c7276a0.bak' > >> Size: 7493992262336241664 Blocks: 821710640 IO Block: 4096 regular file > >>Device: fd06h/64774d Inode: 220986752 Links: 1 > >>Access: (0744/-rwxr--r--) Uid: ( 0/ root) Gid: ( 0/ root) > >>Access: 2014-10-09 16:25:24.864877839 +0300 > >>Modify: 2014-12-13 14:41:29.335603509 +0200 > >>Change: 2014-12-13 15:52:35.986888549 +0200 > >> > >>By the way, I noticed that blocks' number looks rather okay. > >> > >>Also qemu-img can't recognize it as an image: > >>>qemu-img info /mnt/sp1/ac2cb28f-09ac-4ca0-bde1-471e0c7276a0.bak > >>image: /mnt/sp1/ac2cb28f-09ac-4ca0-bde1-471e0c7276a0.bak > >>file format: raw > >>virtual size: 6815746T (7493992262336241664 bytes) > >>disk size: 392G > >> > >>Disk size, although, looks more reasonable: the image's size is really > >>should be about 300-400G, as I remember. > >> > >>Alas, I can't do anything with this image. I can't check it by qemu-img, > >>neither I can convert it to the new image, as qemu-img can't do anything > >>with it: > >> > >>>qemu-img convert -p -f qcow2 -O qcow2 /mnt/sp1/ac2cb28f-09ac-4ca0-bde1-471e0c7276a0.bak /mnt/tmp/ac2cb28f-09ac-4ca0-bde1-471e0c7276a0 > >>Could not open '/mnt/sp1/ac2cb28f-09ac-4ca0-bde1-471e0c7276a0.bak': Invalid argument > >>Could not open '/mnt/sp1/ac2cb28f-09ac-4ca0-bde1-471e0c7276a0.bak' > >> > >>Any one have experienced the same issue? What do you think, is it qcow2 > >>issue or a gfs2 issue? What would you do in similar situation? > >> > >>Any ideas, hints and comments would be greatly appreciated. > >> > >>Yes, I have snapshots, that's good, but wouldn't like to lose today's > >>changes to the data on that image. And I'm worried about the filesystem > >>at all: what if something goes wrong if I try to remove that file? > >> > >>Thanks to all! > >> > >> > >>-- > >>V.Melnik > >> > >>P.S. I use CentOS-6 and I have these packages installed: > >> qemu-img-0.12.1.2-2.415.el6_5.4.x86_64 > >> gfs2-utils-3.0.12.1-59.el6_5.1.x86_64 > >> lvm2-cluster-2.02.100-8.el6.x86_64 > >> cman-3.0.12.1-59.el6_5.1.x86_64 > >> clusterlib-3.0.12.1-59.el6_5.1.x86_64 > >> kernel-2.6.32-431.5.1.el6.x86_64 > >> > >>-- > >>Linux-cluster mailing list > >>Linux-cluster@xxxxxxxxxx > >>https://www.redhat.com/mailman/listinfo/linux-cluster > > -- > Linux-cluster mailing list > Linux-cluster@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/linux-cluster -- V.Melnik -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
