[Linux-cluster] The file on a GFS2-filesystem seems to be corrupted
swhiteho at redhat.com
Mon Dec 15 09:23:47 UTC 2014
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 ?
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?
> 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!
>> P.S. I use CentOS-6 and I have these packages installed:
>> Linux-cluster mailing list
>> Linux-cluster at redhat.com
More information about the Linux-cluster