gluster-devel
[Top][All Lists]
Advanced

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

[Gluster-devel] Some FAQs ...


From: Steffen Grunewald
Subject: [Gluster-devel] Some FAQs ...
Date: Wed, 25 Apr 2007 16:15:00 +0200
User-agent: Mutt/1.5.13 (2006-08-11)

Hi,

I'm in the process of evaluating parallel file systems for a cluster made
of 15 storage servers and about 600 compute nodes, and came across GlusterFS.
Having read most of the documentation, I've got some more FAQs I couldn't
find in the Wiki. I'd appreciate any answer...

- The two example configs are a bit confusing. In particular, I suppose I
        don't have to assign different names to all 15 volumes? Different
        ports are only used to address a certain sub-server?
- This would mean I could use the same glusterfs-server.vol for all 
        storage bricks?
- The "all-in-one" configuration suggests that servers can be clients at the
        same time? (meaning, there's no real need to separately build
        server and client)

- The instructions to add a new brick (reproduce the directory tree with 
        cpio) suggest that it would be possible to form a GluFS from 
        already existing separate file servers, each holding part of the
        "greater truth", by building a unified directory tree (only
        partly populated) on each of them, then unifying them using
        GluFS. Am I right?

- Would it still be possible to access the underlying filesystems, using
        NFS with read-only export?
- What would happen if files are added to the underlying filesystem on one
        of the bricks? Since there's no synchronization mechanism this should
        look the same as f the file entered through GluFS?

- What's the recommended way to backup such a file system? Snapshots?

- Is there a Debian/GNU version already available, or someone working on it?

- Are there plans to implement "relaxed" RAID-1 by writing identical copies
        of the same file (the same way AFR does) to different servers?
_ I couldn't find any indication of metadata being kept somewhere - how do
        I find out which files were affected if a brick fails and cannot
        be repaired? (How does AFR handle such situations?) I suppose there
        are no tools to re-establish redundancy when slipping in a fresh
        brick - what's the roadmap for this feature?

- In several places, the FAQ refers to "the next release" for certain 
        features - it would make sense to put the release number there.

- The benchmark GluFS vs. Lustre looks almost too good - what was the
        underlying filesystem on the bricks? Don't the results reflect
        the big (6GB) buffer cache instead of the real FS performance?

More to come...

Cheers,
 Steffen

-- 
Steffen Grunewald * MPI Grav.Phys.(AEI) * Am Mühlenberg 1, D-14476 Potsdam
Cluster Admin * http://pandora.aei.mpg.de/merlin/ * http://www.aei.mpg.de/
* e-mail: steffen.grunewald(*)aei.mpg.de * +49-331-567-{fon:7233,fax:7298}
No Word/PPT mails - http://www.gnu.org/philosophy/no-word-attachments.html





reply via email to

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