[Gluster-devel] Migration from Unify to DHT

[NovA]

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 at bmiag.de>:
> 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 at nongnu.org
>> [mailto:gluster-devel-bounces+m.gerstner=bmiag.de at nongnu.org] On Behalf
>> Of Anand Avati
>> Sent: Wednesday, December 10, 2008 6:53 AM
>> To: NovA
>> Cc: GlusterFS Devel
>> Subject: Re: [Gluster-devel] 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 at gmail.com>:
>> > 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 at nongnu.org
>> > http://lists.nongnu.org/mailman/listinfo/gluster-devel
>> >
>>
>>
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel at nongnu.org
>> http://lists.nongnu.org/mailman/listinfo/gluster-devel
>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
> http://lists.nongnu.org/mailman/listinfo/gluster-devel
>
>