[Top][All Lists]
[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