Replication deleting file contents

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

 



Hi Vikas

This is a puzzle, I cant seem to be able to reproduce the problem, since 
I had the problem I had deleted the backing store directories. All I can 
think is when I originally started up the servers, I had not installed 
the fuse rpm's, maybe that created a funny state.
I will continue testing for the failure scenarios, as I want to start 
using glusterfs in a live environment in the new year, It looks like an 
excellent solution to distribute data files for our Beowulf clusters.

I now see the reported file sizes go to zero when the empty server 
joins, but the original data is still available in the first servers 
backing store.

Attached are the logs
I started the server and client on factory2, mounting the directory with 
mount -t glusterfs localhost /mnt/export/
copied in 3 files
ran ls -al /mnt/export and got correct file sizes.
Started factory2 and ran ls -al /mnt/ again and the file sizes are 0.

I do have one more question. When should a joining server get updated? 
 From the forum and docs it seems it should be as soon as the directory 
is read.
But I cant get the empty server to update its contents till I read the 
file contents eg md5sum the file. Is there any way to force a server to 
update?

regards
Adrian

Vikas Gorur wrote:
> Adrian Revill wrote:
>> Hi
>> I have read through the docs and google and I think i am trying to do 
>> this right, but just wanted to be sure i have it correctly configured.
>>
>> I have 2 servers factory1 and factory2, both clean installs of 
>> RHEL5.4 on basic hardware.
>> I followed the instructions from 
>> http://gluster.com/community/documentation/index.php/GlusterFS_User_Guide, 
>> and have installed 3.0.0-1
>>
>> On factory1 I ran the command
>> /usr/bin/glusterfs-volgen --name dataexp --raid 1 
>> factory1:/data/export factory2:/data/export
>>
>> I copied factory1-dataexp-export.vol to /etc/glusterfsd.vol on factory1
>> factory2-dataexp-export.vol to /etc/glusterfsd.vol on factory2
>>
>> and coppied dataexp-tcp.vol to /etc/glusterfs.vol on both factory1 
>> and factory2
>>
>> Then on both servers I started the server with the init script and ran
>> mount -t glusterfs /etc/glusterfs/glusterfs.vol /mnt/export
>>
>> Every thing works fine, i can copy files into either servers 
>> /mnt/export directory and they appear on the other server.
>>
>> I then tried a failure scenario. With both servers and clients up i 
>> deleted all the files from /mnt/export, so far so good.
>>
>> I then shut down the server on factory1, leaving the client up and 
>> copied three large files (715MB each) into /mnt/export on factory2
>> Both factory1 and factroy2 both show the files with the correct size 
>> and md5sum.
>>
>> I then started the server on factory1.
>> This is where it goes wrong, as soon as factory1 starts, both clients 
>> show the file sizes of the files as 0, checking the backing store 
>> /data/export i see the files are also 0 size there too. The md5Sum is 
>> now wrong.
>>
>> It seems that the replication has created the files on factory2, but 
>> before copying the contents, it has decided that the empty files on 
>> factory1 are newer than factory2 and decided to copy the zero size 
>> files back to factory1.
>>
>> Any one got any ideas?
>>
> Adrian, If this is reproducible easily, can you run the clients with 
> log level TRACE and send us the logs (or perhaps log a bug and attach 
> it there if they are big)?
>
> Vikas
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mnt-export-.log
URL: <http://gluster.org/pipermail/gluster-users/attachments/20091222/84639d46/attachment-0001.ksh>


[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