[Gluster-devel] Weird lock-ups
gordan at bobich.net
Mon Nov 3 13:51:11 UTC 2008
Thinking about it, could it be that symlinking to a different FS (that
doesn't exist on the other node) is what causes the lock-uk/crash in
1.3.x, too? This might explain why syncing from the remote node (invalid
link) works but from the local node (valid link) hangs.
Krishna Srinivas wrote:
> Hi Gordan,
> Next pre release will fix this, excuse us for not responding to this thread.
> On Mon, Nov 3, 2008 at 7:05 AM, Gordan Bobic <gordan at bobich.net> wrote:
>> I 1.4.0pre5 doesn't seem to work for me at all.
>> When I try to ls the share, I get broken directory entries. This is the sort
>> of thing ls returns for my home directory:
>> ?--------- ? ? ? ? ? gordan
>> instead of:
>> drwxr-x--- 70 gordan gordan 4096 Nov 3 01:22 gordan
>> This is what ends up in the log:
>> 2008-11-02 13:42:02 C [posix.c:2749:ensure_file_type] home-store: stat
>> failed while trying to make sure entry /gluster/home/gordan/.
>> wine is a directory: No such file or directory
>> 2008-11-02 13:42:02 E [afr_self_heal.c:123:afr_lds_setdents_cbk] home:
>> op_ret=-1 op_errno=2
>> 2008-11-02 13:42:02 E [fuse-bridge.c:398:fuse_entry_cbk] glusterfs-fuse: 50:
>> LOOKUP() /gordan => -1 (Input/output error)
>> The .wine directory it is complaining about is actually a symling to a
>> directory on a local file system.
>> The above issue exhibits itself on both of the nodes when the 2nd node has
>> the gluster daemon up and running. But when the 2nd node is removed and only
>> one node remains, it starts working OK again.
>> Christopher Hawkins wrote:
>>> When I upgraded I had only one problem... The way to specify a transport
>>> type in the config file for server and client (I believe?) changed from:
>>> option transport-type tcp/client
>>> option transport-type socket
>>> option address-family inet
>>> See the wiki page here:
>>> Other than that everything worked great. I tried rolling back to 1.3 at
>>> one point too and that worked fine, so if you needed to go back it should
>>> ----- Original Message -----
>>> From: "Gordan Bobic" <gordan at bobich.net>
>>> To: "Gluster List" <gluster-devel at nongnu.org>
>>> Sent: Wednesday, October 29, 2008 1:16:16 PM GMT -05:00 US/Canada Eastern
>>> Subject: RE: [Gluster-devel] Weird lock-ups
>>> Ah yes, I remember the inconsistency / splitbrain issue race condition
>>> being discussed and demonstrated.
>>> Is migration from 1.3.x to 1.4.x transparent? Can I use the same
>>> pre-populated backing store from 1.3.x, with xattrs set as 1.3.x set them?
>>> Or is a backup/restore required?
>>> And if there is a problem, is the downgrade path clean (i.e. can I just
>>> put 1.3.x back if 1.4.x goes wrong for me)? Are there any changes to xattrs
>>> used/set that can cause compatibility problems?
>>> -----Original Message-----
>>> From: "KwangErn Liew" <ke.liew at gmail.com>
>>> To: "Gordan Bobic" <gordan at bobich.net>
>>> Cc: "Gluster List" <gluster-devel at nongnu.org>
>>> Sent: 29/10/08 14:55
>>> Subject: Re: [Gluster-devel] Weird lock-ups
>>> On Wed, Oct 29, 2008 at 12:09 AM, Gordan Bobic <gordan at bobich.net> wrote:
>>>> KwangErn Liew wrote:
>>>>> 1.3.x isn't exactly a usable release for AFR anymore.
>>>> That's pretty worrying. The "stable" release is unusable for AFR, but the
>>>> pre-release is? Isn't that a bit backward? How stable is the pre-release?
>>> Split-brain issue is known in 1.3.x
>>> More info
>>> The 1.4.x pre-release is in QA mode.
>>> Gluster-devel mailing list
>>> Gluster-devel at nongnu.org
>> Gluster-devel mailing list
>> Gluster-devel at nongnu.org
More information about the Gluster-devel