Since I went through and resolved refcount issues with fsal_pnfs_ds (that were exposed when I looked at all the export refcounting), I notice that there's code for DS only mode, but I'm not sure how it actually works. FSAL_GLUSTER, FSAL_GPFS, and FSAL_LIZARDFS are all set up to associate a fsal_pnfs_ds with an export. FSAL_CEPG seems to be set up to use the DS only mode, which does NOT associate an export with a fsal_pnfs_ds. But then how does, for example FSAL_CEPH's ds_read method supposed to work? It immediately de-references op_ctx->fsal_export which will be NULL if called with a Ceph DS handle. Another issue is the processing for the DS config block makes no check about the FSAL specified, so you could configure: DS { Number = 1; FSAL { Name = GPFS; } } Which probably will go badly in some way. I suspect the config processing should try and determine if the FSAL actually supports DS only mode. Frank
The Ceph FSAL supported an early version of ds-only mode. The idea was reworked during development of a cohortfs fsal, which was a limited prototype. The Ceph ds path is probably no longer correct. Making setup more foolproof makes sense. We can go over the way we most recently used ds-only, at some point. We did not and for posterity did not want to require the pnfs driver to have exports (for various reasons). Matt On Mon, Aug 10, 2020 at 7:45 PM Frank Filz <ffilzlnx@mindspring.com> wrote:
Since I went through and resolved refcount issues with fsal_pnfs_ds (that were exposed when I looked at all the export refcounting), I notice that there’s code for DS only mode, but I’m not sure how it actually works.
FSAL_GLUSTER, FSAL_GPFS, and FSAL_LIZARDFS are all set up to associate a fsal_pnfs_ds with an export.
FSAL_CEPG seems to be set up to use the DS only mode, which does NOT associate an export with a fsal_pnfs_ds. But then how does, for example FSAL_CEPH’s ds_read method supposed to work? It immediately de-references op_ctx->fsal_export which will be NULL if called with a Ceph DS handle…
Another issue is the processing for the DS config block makes no check about the FSAL specified, so you could configure:
DS {
Number = 1;
FSAL {
Name = GPFS;
}
}
Which probably will go badly in some way…
I suspect the config processing should try and determine if the FSAL actually supports DS only mode…
Frank
_______________________________________________ Devel mailing list -- devel@lists.nfs-ganesha.org To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org
-- 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
The Ceph FSAL supported an early version of ds-only mode. The idea was reworked during development of a cohortfs fsal, which was a limited prototype. The Ceph ds path is probably no longer correct.
Ok, that certainly makes sense, and the code at the Protocol level supports that. FSAL_CEPH looks like it's currently coded to have an export associated with the DS, so maybe the config code for DS only should also reject FSAL_CEPH for now (i.e. actually not be valid for any in-tree FSAL). The code will be there and easy enough to make use of when someone's actually ready to code up a DS only FSAL.
Making setup more foolproof makes sense. We can go over the way we most recently used ds-only, at some point. We did not and for posterity did not want to require the pnfs driver to have exports (for various reasons).
Ok, will do. Also I think the DS only mode may not be documented, which is probably ok... Frank
participants (2)
-
Frank Filz -
Matt Benjamin