[Gluster-users] upgrading from 1.3.10 to 2.0.0rc7

Thu Apr 9 10:13:58 UTC 2009

I think you can run a 2.0.0rc7 glusterfs beside your running old one for
testing.
I have not tried nufa translator yet, but dht translaitor had caused me a
little headache.
Maybe , you would need to stat each of your existing file on the new system,
and do mkdir on all the low layer storages.

-----Original Message-----
From: gluster-users-bounces at gluster.org
[mailto:gluster-users-bounces at gluster.org] On Behalf Of Matthew Wilkins
Sent: Thursday, April 09, 2009 6:58 AM
To: gluster-users at gluster.org
Subject: [Gluster-users] upgrading from 1.3.10 to 2.0.0rc7

Hi,

I am currently running glusterfs-1.3.10 in a NUFA situation using the
unify translator, nufa scheduler, and an AFR'ed namespace.  A
config from one of my servers is below if you want the full
details.  I want to upgrade to 2.0.0rc7 and use the nufa
translator instead of unify.  The nufa cluster translator sounds like
the better option.  I have some questions for you helpful people!

1. Is it possible to do such an upgrade?  I was thinking I would
umount the fs and stop the gluster daemons.  Upgrade to 2.0.0rc7 and
put the new config files in.  Mount up the fs again.  Note the
namespace will have disappeared because it isn't necessary in version
2 right?  So what will happen now?  Will there be a lot of
self-healing necessary?  Can that just happen as people use the
gluster?  (btw, total size is 32T, used size is about 15T).

2. I have a sneaking suspicion that the answer to 1 is 'No it wont
work'.  Either way I am wondering how the distributed translator
works.  The nufa translator a special case of the distributed
translator correct?  (but is must have some bias towards the local
server?).  Anyway, how do they work?  When a client wants to find a
file a hash is done on the filename, somehow that maps to a particular
server, then the client asks that server for the file?  Are any
extended attributes set on the file?

3. One of my servers has two bricks.  The nufa example at
http://gluster.org/docs/index.php/NUFA_with_single_process
doesn't show me what to do.  It has two examples; the first when each node
has one brick, and another where nodes have more than one brick but
nufa is not used, rather unify.  So how can I used the nufa translator
when one or more nodes contribute more than one brick?  I was thinking
something like a server side unify, then nufa on top, but I'm not sure
of the syntax.  If it isn't possible it isn't the end of the world
(the second brick isn't that big).

4. At the end of my new config for version 2 I have the following:

        volume nufa
           type cluster/nufa
           option local-volume-name `hostname`
           subvolumes tur-awc1 tur-awc2 tur-awc3

        volume writebehind
           type performance/write-behind
           option page-size 128KB
           option cache-size 1MB
           subvolumes nufa
        end-volume

        volume ra
        end-volume

Is that the correct order for these performance translators, it isn't
obvious to me if the read-ahead should be before or after write-behind
(all the examples I have seen have io-cache at the end though).  Does
the order matter?

Thank you very much for any help.  If you can only help with one
question I would still very much appreciate it.

Matt

Here is my current config:

volume brick0
 type storage/posix
 option directory /export/brick0
end-volume

volume iot-0
 type performance/io-threads
 subvolumes brick0
end-volume

volume brick1
 type storage/posix
 option directory /export/brick1
end-volume

volume iot-1
 type performance/io-threads
 subvolumes brick1
end-volume

volume brick-ns
 type storage/posix
 option directory /export/brick-ns
end-volume

volume iot-ns
 type performance/io-threads
 subvolumes brick-ns
end-volume

volume server
 type protocol/server
 subvolumes iot-0 iot-1 iot-ns
 option transport-type tcp/server # For TCP/IP transport
 option auth.ip.iot-0.allow *
 option auth.ip.iot-1.allow *
 option auth.ip.iot-ns.allow *
end-volume

volume client-tardis-0
 type protocol/client
 option transport-type tcp/client
 option remote-host tardis
 option remote-subvolume iot-0
end-volume

volume client-orac-0
 type protocol/client
 option transport-type tcp/client
 option remote-host orac
 option remote-subvolume iot-0
end-volume

volume client-orac-ns
 type protocol/client
 option transport-type tcp/client
 option remote-host orac
 option remote-subvolume iot-ns
end-volume

volume afr-ns
 type cluster/afr
 subvolumes iot-ns client-orac-ns
end-volume

volume unify
 type cluster/unify
 option namespace afr-ns
 option scheduler nufa
 option nufa.local-volume-name iot-0,iot-1
 option nufa.limits.min-free-disk 5%
 subvolumes iot-0 iot-1 client-orac-0 client-tardis-0
end-volume

volume ra
 type performance/read-ahead
 subvolumes unify
end-volume

volume ioc
 type performance/io-cache
 subvolumes ra
end-volume

_______________________________________________
Gluster-users mailing list
Gluster-users at gluster.org
http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users