gluster-devel
[Top][All Lists]
Advanced

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

Re: [Gluster-devel] [RFC] Block Device Xlator Design


From: M. Mohan Kumar
Subject: Re: [Gluster-devel] [RFC] Block Device Xlator Design
Date: Mon, 23 Jul 2012 11:03:06 +0530
User-agent: Notmuch/0.6.1 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-redhat-linux-gnu)

On Wed, 11 Jul 2012 05:45:56 -0400 (EDT), Shishir Gowda <address@hidden> wrote:
> Hi Mohan,
> 
> For the persistent gfid related issue discussed, could we look into mapping 
> the lv_uuid and lg_uuid to act as their gfid's for glusterfs?
> Assuming this to be unique across the cluster, we could guarantee persistence 
> of these attributes, rather than generating them on the fly.
> 
> If the above scenario can be utilized, there are further issues to be looked 
> into.
> 1. Can these uuid's be set through any interface?
> 2. Can just a uuid be sufficient for us to map it to a path? (to support 
> nameless lookup's)
> 

Hi Shishir,

I looked at LV & VG UUID, they are not real UUID, they contain standard
alphabets also. For example in my system, UUID of one of the LVs is

LV UUID                Hmn1uv-dScA-ch53-Qyxe-0yjW-VNk0-qpvrQr

uuid_parse routine in GlusterFS will fail for above UUID. I can
generate a md5 sum of the LV UUID and use that as gfid, but issue
is BD Xlator patches will have another dependency on the package
"openssl-devel".

So can't we use the inode of the device as gfid? Is there any issue?

Regards,
M. Mohan Kumar
 




reply via email to

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