Hi! As I understood from the mail-list, git logs here and there, glusterFS in "lookup-unhashed" mode will create so called link-files after successful lookup. This link-file has the same name as an original file and placed on the correct server selected by name hash. The link-file contains info where an original file resides, it's small and has sticky bit. If the link-file exists, GlusterFS just goes to the server it points to and do not lookup on all nodes. So there is need to create link-files only once on migration and then "lookup-unhashed" can be disabled. GlusterFS distribution has a simple script extras/migrate-unify-to-distribute.sh for such first-time link-file initialization. All the above is my view of the glusterFS functioning, correct me if I wrong. Best wishes, Andrey 2009/6/3 Markus Gerstner <m.gerstner@xxxxxxxx>: > Hello, > > has this migration document been posted already? I tried finding it on the > wiki but wasn't successful so far. Is it enough to just use distribute with > "option lookup-unhashed yes"? > Am I right in thinking that the client would then hash a given filename, try > to find it on the mapped server and if that fails, ask all other servers if > they have the given filename in their storage? > Given that neither server nor client store any metadata for DHT, this would > mean that you can never disable this option if there are any files present > which have not been stored using distribute, correct? > > "* lookup-unhashed > This option when provided, will make the dht translator act as a generic > cluster translator where it sends lookup call on all the subvolumes, hence > there will be no files missing over filesystem." > kind of sounds like distribute always sends lookups to all nodes, without even > trying to hash first, hence the questions. > > Also, is there any ETA on schedulers for DHT? > > Best regards and thanks in advance, > Markus > > >> -----Original Message----- >> From: gluster-devel-bounces+m.gerstner=bmiag.de@xxxxxxxxxx >> [mailto:gluster-devel-bounces+m.gerstner=bmiag.de@xxxxxxxxxx] On Behalf >> Of Anand Avati >> Sent: Wednesday, December 10, 2008 6:53 AM >> To: NovA >> Cc: GlusterFS Devel >> Subject: Re: Migration from Unify to DHT >> >> we will be putting up a migration document (from unify) on the wiki in >> the DHT section. >> >> avati >> >> 2008/11/17 NovA <av.nova@xxxxxxxxx>: >> > Hello everybody! >> > >> > As 1.4 release is approaching I'm preparing migration from 1.3. I hope >> > that DHT could increase performance a lot for our 24-nodes computing >> > cluster. Now unify really slows down file IO if there are hundreds of >> > files in a dir... >> > What is the simplest way for switching from unify to DHT? As I >> > understand, ideally one should recreate glusterfs volumes from scratch >> > to initialize new DHT file scheduling. But it could be problematic in >> > our case... What will happen if I start new glusterFS with DHT over >> > existing backends with thousands of files distributed by unify? Can it >> > reschedule files during self-healing process or something like that? >> > Or will it just stuck or even corrupt data? >> > >> > Thanks in advance for any comments. >> > >> > Best regards, >> > Andrey >> > >> > >> > _______________________________________________ >> > Gluster-devel mailing list >> > Gluster-devel@xxxxxxxxxx >> > http://lists.nongnu.org/mailman/listinfo/gluster-devel >> > >> >> >> _______________________________________________ >> Gluster-devel mailing list >> Gluster-devel@xxxxxxxxxx >> http://lists.nongnu.org/mailman/listinfo/gluster-devel > > > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@xxxxxxxxxx > http://lists.nongnu.org/mailman/listinfo/gluster-devel > >
