Yes, I checked the latest code immediately after posting this. The
latest code is handling it correctly.
- Sriram
On Mon, Mar 13, 2017 at 11:02 PM, Frank Filz wrote:
>> This is all different in 2.4 and later, where MDCACHE takes out much of
> this
>> special handling. I suspect it's correct now
> This is all different in 2.4 and later, where MDCACHE takes out much of
this
> special handling. I suspect it's correct now.
Support_ex also should have improved various create scenarios.
I'm working on an even more improved create, but it's been hung up with
issues for 9P...
Frank
> On 03/1
This is all different in 2.4 and later, where MDCACHE takes out much of
this special handling. I suspect it's correct now.
Daniel
On 03/13/2017 12:15 PM, sriram patil wrote:
> Hi,
>
> According to POSIX semantics, when open is does with O_CREAT and
> O_EXCL then it should return EEXIST. But, ga
Hi,
According to POSIX semantics, when open is does with O_CREAT and
O_EXCL then it should return EEXIST. But, ganesha always expects fsal
layer to return EEXIST from create if the file already exists. This is
handled in cache_inode_create. If fsal create returns EEXIST then
ganesha does a lookup
I haven't seen anything link this. The CLIENT is refcounted, but the
refcounting is unused, and nothing has changed in this respect on HEAD.
So the client lifetime for the CLIENT in NSM appears to just be between
nsm_connect() and nsm_disconnect(). nsm_unmonitor() calls
nsm_connect(), so the
>From Patrice LUCAS :
Patrice LUCAS has uploaded this change for review. (
https://review.gerrithub.io/352463
Change subject: FSAL_PROXY : fix pxy_close in support_ex case
..
FSAL_PROXY : fix pxy_close in support_ex case
mdca
Probably a bug! Having said that we have a long way to go from the
current 1MB to going beyond 4GB. It is nice to fix it though.
Regards, Malahal.
On Mon, Mar 13, 2017 at 3:33 PM, LUCAS Patrice wrote:
> Hi,
>
>
> Why fs_maxwrite and fs_maxread export functions are returning an
> uint32_t (src/in
We got the following stack trace. This is with ganesha 2.3
(corresponding libntirpc) on a customer system. Did anyone see this in
the past. The __kind mutex field is -1, implying that the code is
using freed memory. The pthread_mutex_lock() failed and our
mutex_lock() macro called abort().
(gdb) b
My bad, I should have mentioned the version in the original post.
Mahalal was kind enough to share a list of relevant commits. With the
patches I continued to see the issue. I suspect the client code is not
handling GSS_S_CONTEXT_EXPIRED correctly on a call to gss_verify_mic.
Instead I fixed the s
Hi,
Why fs_maxwrite and fs_maxread export functions are returning an
uint32_t (src/include/fsal_api.h:859) whereas maxread and maxwrite
values are often managed as uint64_t, like in the gsh_export structure
(src/include/export_mgr.h:64) or in the fsal_dynamicfsinfo_t structure
(src/include/fs
10 matches
Mail list logo
