Branch next
Tag:V2.6-rc2
NOTE: This merge includes an ntirpc pullup, please update your submodule.
Release Highlights
* Don't print "CRIT: Likely bug.." trace when attr mask is ATTR_RDATTR_ERR
* Pullup NTIRPC through #99
Signed-off-by: Frank S. Filz
Contents:
Daniel Gryniewicz wrote on Fri, Jan 12, 2018 at 11:19:27AM -0500:
>> As to Lustre, I'm pretty sure the stackable FSAL will work fine. A stacked
>> FSAL does have the pointer to the subfsal object, and knows which FSAL is
>> the subfsal, so in this case where FSAL_LUSTRE MUST stack on top of
On 01/12/2018 10:08 AM, Frank Filz wrote:
So, the linux/freebsd split was not something I was considering for
stacking. I
agree, that doesn't match well. But the VFS subfsal API looks like it can
just
go away and be a stack instead. And I certainly would not like to see it
extended.
All work necessary to work in containerized ceph/ganesha will be
backported to 2.6, as it's ready. This means that some version 2.6.x
(likely low, maybe 2 or 3) will be fully ready for containerized
deployment. This also means that 2.7.0 will work out-of-the-box, since
the work will be done
> So, the linux/freebsd split was not something I was considering for
stacking. I
> agree, that doesn't match well. But the VFS subfsal API looks like it can
just
> go away and be a stack instead. And I certainly would not like to see it
> extended.
Yea, I think the subfsal could go away.
So, the linux/freebsd split was not something I was considering for
stacking. I agree, that doesn't match well. But the VFS subfsal API
looks like it can just go away and be a stack instead. And I certainly
would not like to see it extended.
Daniel
On 01/09/2018 06:19 PM, Frank Filz
Hi Daniel,
Thanks for reply. Does it mean that 2.7 will already be ready to support
containerized nfs-ganesha?
Are there more details on what exact features need to be implemented in
nfs-ganesha and cephfs to make
OpenShift/Kubernerties work. I am aware of blog post by Jeff:
On 01/10/18 16:04, Frank Filz wrote:
Hi Frank, others,
Frank Filz wrote on Tue, Jan 09, 2018 at 03:19:46PM -0800:
All in all, these functions are not a great fit for the FSAL API so
I'm not sure it would be a good solution. Forcing some of the
functions into FSAL methods would require some