On Thu, Sep 11, 2014 at 3:26 AM, Miklos Szeredi wrote:
> On Wed, Sep 10, 2014 at 6:14 PM, Anand Avati wrote:
>
> >
> > This is something beyond the libfuse API. Unless the kernel/user ABI is
> > modified to present the entire 128bits with each call (i.e, both nodeID +
> > generation instead of j
On Wed, Sep 10, 2014 at 6:14 PM, Anand Avati wrote:
>
> This is something beyond the libfuse API. Unless the kernel/user ABI is
> modified to present the entire 128bits with each call (i.e, both nodeID +
> generation instead of just nodeID) we are still bound to provide unique
> 64bit nodeID (and
On Wed, Sep 10, 2014 at 7:20 AM, Miklos Szeredi wrote:
>
> >> This would be a challenge with any FUSE based filesystem which has
> >> persistent filehandles larger than 64bit.
>
> Fuse does provide a total of 128bits of file handle identification
> with nodeID + generation, with some of that numbe
On Thu, Sep 4, 2014 at 5:42 PM, Goswin von Brederlow wrote:
> On Tue, Sep 02, 2014 at 08:20:35AM -0700, Anand Avati wrote:
>> On Mon, Sep 1, 2014 at 6:07 AM, Vimal A R wrote:
>>
>> > Hello fuse-devel / fs-cache / gluster-devel lists,
>> >
>> > I would like to propose the idea of implementing FS-C
