That would work. The logic that the RGW FSAL uses to do all of Frank describes is in the Ceph source rather than FSAL_RGW for the same reason. The strategy I take is to represent the RGW file handle as concatenated hashes of S3/swift container name and full object name, which yields stable handles. For directories, cookies are also the hash of the entry name. Frank's whence-is-name and compute-readdir-cookie apis were invented to support the RGW FSAL. Using them, you avoid the need to keep an indexed representation of the S3 namespace in the FSAL (or in my case, librgw).
Matt On Thu, Jan 4, 2018 at 7:18 AM, DENIEL Philippe <philippe.den...@cea.fr> wrote: > 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 list > Nfs-ganesha-devel@lists.sourceforge.net > https://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 > -- Matt Benjamin Red Hat, Inc. 315 West Huron Street, Suite 140A Ann Arbor, Michigan 48103 http://www.redhat.com/en/technologies/storage tel. 734-821-5101 fax. 734-769-8938 cel. 734-216-5309 ------------------------------------------------------------------------------ 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
