Hello Philippe,
Did you mean it like I could directly use the FSAL you developed, modify
some code (or not?) in order to use S3 as a storage? Or is it to share
solutions you found to some problems I will encounter during the
development of my FSAL_S3.
In both cases, I sure would be happy to have a look at your project, thank
you for that.
What do you mean by no compliancy to support_ex, does that imply a specific
range of ganesha versions? other constraints?
Regards,
Aurélien
2018-01-04 13:18 GMT+01:00 DENIEL Philippe <philippe.den...@cea.fr>:
> Hi Aurélien,
>
> I can provide you an alternate solution, still nfs-ganesha based. For the
> need of a project, I developed an open-source library that emulate a POSIX
> namespace using a KVS (for metadata) and an object store (for data). For
> example, you can use REDIS and RADOS. I have written a FSAL for it (it is
> not pushed in the official branch) but with no compliancy to support_ex,
> it's still using the former FSAL semantics (so it should be ported to
> support_ex). If you are interested, I can give you some pointers (the code
> is on github). You could use S3 as data storage for example. In particular,
> I had to solve the same "inode" issue that you met. This solution as very
> few impact on nfs-ganesha code (it just adds a new FSAL).
>
> Regards
>
> Philippe
>
> On 01/03/18 19:58, Aurelien RAINONE wrote:
>
> To follow up on the development on an FSAL for S3, I have some doubts and
> questions I'd like to share.
>
> Apart from its full path, S3 doesn't have the concept of file descriptor, I
> mean, there's nothing else
>
> than the full path that I can provide to S3 in order to get attribute of
> content of a specific object.
>
> I have some doubts regarding the implementation of the S3 fsal object handle
> (s3_fsal_obj_handle).
>
> Should s3_fsal_obj_handle be very simple, for example should it only
> contain a key that maps to the full S3 filename, in an key-value store.
>
> Or on the contrary, should the handle implement a tree like structure, like I
> saw in FSAL_MEM?
>
> Or something in between, but what?
>
> Having a very simple handle has some advantages but may require some more
> frequent network calls,
>
> for example readdir won't have any kind of information about the content of
> the directory.
>
> Having a whole tree-like structure in the handle would allow to have direct
> access to directory content,
>
> but isn't that the role of ganesha cache to do that?
>
> My questions probably shows that I have problems to understand the
> responsability of my FSAL implementation
>
> regarding the cache. Who does what, what doesn't do what?
>
> Good evening,
>
> Aurélien
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
>
> _______________________________________________
> Nfs-ganesha-devel mailing
> listNfs-ganesha-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
>
>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
