Hi Andrey,
Yes! your doubts are very much valid, and we are working on it, to provide
a smooth transition mechanism. As of now, one can switch between unify to
DHT with a fresh backend for DHT, and copy everything over DHT freshly.
But for users who are already using unify, this may become a
problem/overhead. So, we currently are planing a 2-phase transition, where
we will bring a extra check in dht code to create a dummy linkfile (ie,
something similar to namespace 0 byte file) in the subvolume corresponding
to its hashed node. This will be first stage, where there will be no data
movement, but is instant transition to dht from unify, and all your new
files will be using dht.
In stage two. we will provide another tool which will start re-organising
files to corresponding nodes (when you have mountpoints intact).
This is the current plan as of now. I will update again when the team gets
much better solution.
Regards,
Amar
2008/11/27 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 already 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://supercolony.gluster.org/pipermail/gluster-users/attachments/20081201/5baba489/attachment.html>