regards
Aravinda
On 01/11/2016 08:00 PM, Shyam wrote:
On 01/06/2016 04:46 AM, Aravinda wrote:
regards
Aravinda
On 01/06/2016 02:49 AM, Shyam wrote:
On 12/09/2015 12:47 AM, Aravinda wrote:
Hi,
Sharing draft design for GFID to Path Conversion.(Directory GFID to
Path is
very easy in DHT v.1,
On 01/05/2016 08:24 PM, Venky Shankar wrote:
Shyam wrote:
On 12/09/2015 12:47 AM, Aravinda wrote:
Hi,
Sharing draft design for GFID to Path Conversion.(Directory GFID to
Path is
very easy in DHT v.1, this design may not work in case of DHT 2.0)
(current thought) DHT2 would extend the manne
On 01/06/2016 04:46 AM, Aravinda wrote:
regards
Aravinda
On 01/06/2016 02:49 AM, Shyam wrote:
On 12/09/2015 12:47 AM, Aravinda wrote:
Hi,
Sharing draft design for GFID to Path Conversion.(Directory GFID to
Path is
very easy in DHT v.1, this design may not work in case of DHT 2.0)
(current
regards
Aravinda
On 01/06/2016 02:49 AM, Shyam wrote:
On 12/09/2015 12:47 AM, Aravinda wrote:
Hi,
Sharing draft design for GFID to Path Conversion.(Directory GFID to
Path is
very easy in DHT v.1, this design may not work in case of DHT 2.0)
(current thought) DHT2 would extend the manner i
Shyam wrote:
On 12/09/2015 12:47 AM, Aravinda wrote:
Hi,
Sharing draft design for GFID to Path Conversion.(Directory GFID to
Path is
very easy in DHT v.1, this design may not work in case of DHT 2.0)
(current thought) DHT2 would extend the manner in which name,pGFID is
stored for files, for
On 12/09/2015 12:47 AM, Aravinda wrote:
Hi,
Sharing draft design for GFID to Path Conversion.(Directory GFID to Path is
very easy in DHT v.1, this design may not work in case of DHT 2.0)
(current thought) DHT2 would extend the manner in which name,pGFID is
stored for files, for directories. S
Some more analysis wrt storage space,
"Since support was added to the Linux kernel, there is a hard limit of
64KiB for the size of each extended attribute value, however different
file systems impose additional constraints. For ext2/3/4 and btrfs,
each extended attribute is limited to a file syst
Hi,
Sharing draft design for GFID to Path Conversion.(Directory GFID to Path is
very easy in DHT v.1, this design may not work in case of DHT 2.0)
Performance and Storage space impact yet to be analyzed.
Storing the required informaton
---
Metadata information relate
regards
Aravinda
On 11/24/2015 11:25 PM, Shyam wrote:
There seem to be other interested consumers in gluster for the same
information, and I guess we need a god base design to address this on
disk change, so that it can be leveraged in the various use cases
appropriately.
Request a few folk
There seem to be other interested consumers in gluster for the same
information, and I guess we need a god base design to address this on
disk change, so that it can be leveraged in the various use cases
appropriately.
Request a few folks to list out how they would use this feature and also
w
Aravinda, List,
The topic is interesting and also relevant in the case of DHT2 where we
lose the hierarchy on a single brick (unlike the older DHT) and so some
of the thoughts here are along the same lines as what we are debating
w.r.t DHT2 as well.
Here is another option that extends the cu
Hi,
We have a volume option called "build-pgfid:on" to enable recording
parent gfid in file xattr. This simplifies the GFID to Path conversion.
Is it possible to save base name also in xattr along with PGFID? It
helps in converting GFID to Path easily without doing crawl.
Example structure,
ject: [Gluster-devel] GFID to Path Conversion if Historical Changelogs
available
Hi,
While discussing about the possible options to convert from GFID to
path, Venky suggested to search in Historical GlusterFS Changelogs and
get the information about Parent GFID and basename of the file. Thi
Hi,
While discussing about the possible options to convert from GFID to
path, Venky suggested to search in Historical GlusterFS Changelogs and
get the information about Parent GFID and basename of the file. This
method works well for FOPs except Rename and Hard links.
Approach:
-
Wil
14 matches
Mail list logo
