Recovering a broken distributed volume

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jul 11, 2012 at 11:27:58AM +0100, Brian Candler wrote:
> (1) The "single1" volume is empty, which I expected since it's a brand new
> empty directory, but I cannot create files in it.
> 
> root at dev-storage1:~# touch /gluster/single1/test
> touch: cannot touch `/gluster/single1/test': Read-only file system

Sorry, this was my problem: it turns out a few more drives failed, and the
underlying brick filesystem went read-only.  Unbelievably that's 7 seagate
drives failed out of an array of 12!

Anyway, rebuilding the array with the remaining 5 working disks, the single
volume came up fine. Also the distributed volume healed itself after I
did 'ls' a few times on it.

root at dev-storage1:~# ls /gluster/fast
...
root at dev-storage1:~# ls /gluster/fast
images  iso
root at dev-storage1:~# ls /gluster/fast/images/
root at dev-storage1:~# ls /gluster/fast/iso
linuxmint-11-gnome-dvd-64bit.iso
root at dev-storage1:~# ls /gluster/fast/images/
lucidtest
root at dev-storage1:~# ls /gluster/fast/images/lucidtest/
tmpaJqTD9.qcow2

I can only see one other strange thing: the newly-created replica appears to
have made a sparse copy of a file which wasn't sparse on the original.

On the original working side of the replicated volume:

root at dev-storage2:~# ls -l /disk/storage2/safe/images/lucidtest/
total 756108
-rw-r--r-- 2 root root 774307840 Jul 11 14:55 tmpaJqTD9.qcow2
root at dev-storage2:~# du -k /disk/storage2/safe/images/lucidtest/
756116	/disk/storage2/safe/images/lucidtest/

On the newly-created side, which glustershd rebuilt automatically:

root at dev-storage1:~# ls -l /disk/storage1/safe/images/lucidtest/
total 422728
-rw-r--r-- 2 root root 774307840 Jul 11 14:55 tmpaJqTD9.qcow2
root at dev-storage1:~# du -k /disk/storage1/safe/images/lucidtest/
422736	/disk/storage1/safe/images/lucidtest/

Is this intentional?  Does glustershd notice runs of zeros and create a
sparse file on the target?

(This may or may not be desirable, e.g.  for performance you might want to
fully preallocate a VM image)

Regards,

Brian.


[Index of Archives]     [Gluster Development]     [Linux Filesytems Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux