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: 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