Hi Matthew, please find the inlined comments. On Tue, Apr 7, 2009 at 5:38 AM, Matthew Wilkins <daibutsu at gmail.com> wrote: > 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? yes, files are mapped to servers based on their hash value. DHT does not use any extended attributes. > > > 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). export each brick separately and have the client protocols corresponding to each of the exported brick as children of nufa. > > > 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 > -- Raghavendra G -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://zresearch.com/pipermail/gluster-users/attachments/20090414/4938c8fe/attachment.htm>
