gluster-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gluster-devel] Migration from Unify to DHT


From: NovA
Subject: Re: [Gluster-devel] Migration from Unify to DHT
Date: Wed, 3 Jun 2009 21:15:22 +0400

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 <address@hidden>:
> 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: address@hidden
>> [mailto:address@hidden 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 <address@hidden>:
>> > 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
>> > address@hidden
>> > http://lists.nongnu.org/mailman/listinfo/gluster-devel
>> >
>>
>>
>> _______________________________________________
>> Gluster-devel mailing list
>> address@hidden
>> http://lists.nongnu.org/mailman/listinfo/gluster-devel
>
>
> _______________________________________________
> Gluster-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/gluster-devel
>
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]