[Gluster-users] upgrading from 1.3.10 to 2.0.0rc7

[Matthew Wilkins]

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