gluster-devel
[Top][All Lists]
Advanced

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

Re: [Gluster-devel] 2.0.1


From: Gordan Bobic
Subject: Re: [Gluster-devel] 2.0.1
Date: Fri, 15 May 2009 07:16:09 +0100
User-agent: Thunderbird 2.0.0.19 (X11/20090107)

Brent A Nelson wrote:
On Thu, 14 May 2009, Gordan Bobic wrote:

Gordan Bobic wrote:
SQLite is still unstable with 2.0.1. Bookmarks in firefox still don't work when /home is on GlusterFS.

First access immediately after mounting still fails, too.


FYI, I haven't seen the first-access-on-mounting problem since one of the earlier 2.0.0RCs. I don't need to first "ls" my filesystems, they just work from the start.

It still seems to occur, at least I use a script that does something along the following lines:

mount /etc/glusterfs/foo.vol /mnt/foo
mount --bind /mnt/foo/bar/x /mnt/foo/baz

If it is being done by a script so there is no delay between the two, the mount --bind will fail the first time at least when foo is an AFR volume with the current machine being the only one that is up from the AFR cluster.

The delay required may have reduced since earlier versions, but it sounds like there is still a race somewhere.

I hope to try a GlusterFS as my home directory soon and will be very interested to see if I hit any trouble with FireFox bookmarks.

Both this and the first access problem are 100% reproducible on all my systems.

2) File writes to a kernel-NFS-reexported GlusterFS are marked dirty by replicate, such that self-heal is triggered when stat'ing the directory. The unfs3 user-mode NFS server does not trigger this issue, nor do non-NFS writes.

Can you elaborate on this? If a file is written via NFS, then it should be synced to other nodes since it wouldn't have been written to all the nodes.

3) replicate self-heal fails to preserve mtime.

Doesn't this completely kill the concept of self-heal? Surely, the primary ways to detect that a file needs healing is to check it's mtime?

4) GlusterFS seems to have trouble creating or renaming files that match the pattern '..*.*.*'; this is noticed when rsyncing directories containing dot-files.

Interesting, I hadn't noticed that. Thanks for pointing it out.

Gordan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]