loflags = obj->obj_ops.status(obj);
while ((!fsal_is_open(obj))
|| (loflags && loflags != FSAL_O_RDWR && loflags != openflags)) {
loflags = obj->obj_ops.status(obj);
if ((!fsal_is_open(obj))
|| (loflags && loflags != FSAL_O_RDWR
&& loflags != openflags)) {
fsal_status = fsal_open(obj, openflags);
if (FSAL_IS_ERROR(fsal_status))
goto out;
opened = true;
}
loflags = obj->obj_ops.status(obj);
}
......
......
......
if (opened) {
fsal_status = obj->obj_ops.close(obj);
if (FSAL_IS_ERROR(fsal_status)) {
LogEvent(COMPONENT_FSAL,
"fsal_rdwr_plus: close = %s",
fsal_err_txt(fsal_status));
goto out;
}
}
Here multiple thread can come into this function and call fsal_is_open function. For example
T1 thread opens it and sets opened flag to true.
T2 will see that ,it already opened . continue withour calling fsal_open.
T1 finishes the r/w operation and close the file.
T2 is now trying to work on closed fd.
is this situation can arise from above code ? is Ganesha expects some reference count for open file fd inside fsal here ?
Thanks,
Sagar.
Okay, so there are a few places where files are unconditionally closed, regardless of whether or not they were open to begin with. The FSAL would return ERR_FSAL_NOT_OPENED, but the caller would ignore the error, since all it wanted to do was ensure the global FD was closed. Examples of this are:
On remove
When we're recycling a handle
When a handle transitions from L1 to L2 of the LRU
My guess is that the last case is the one you're hitting. If the file is in use, and very few handles are in use, then the handle will transition back and forth across the L1/L2 border. Since you haven't implemented open()/close() in your FSAL, the status() op can't tell the handle was closed, so it might not open() again, if it thought it was open already.
Daniel
On 08/06/2018 11:15 AM, You Me wrote:
Ganesha 2.5.1.
06/08/2018 10:51:18 : epoch 5b685fb2 : rhelindex : ganesha.nfsd-41167[work-195] file_open :FSAL :CRIT :file_open() fd = 1533189746
06/08/2018 10:51:18 : epoch 5b685fb2 : rhelindex : ganesha.nfsd-41167[work-193] file_close :FSAL :CRIT :file_close() fd = 1533189746
06/08/2018 10:51:18 : epoch 5b685fb2 : rhelindex : ganesha.nfsd-41167[work-191] file_close :FSAL :CRIT :file_close() fd = 1533189746
06/08/2018 10:51:18 : epoch 5b685fb2 : rhelindex : ganesha.nfsd-41167[work-196] file_close :FSAL :CRIT :file_close() fd = 1533189746
06/08/2018 10:51:18 : epoch 5b685fb2 : rhelindex : ganesha.nfsd-41167[work-195] file_close :FSAL :CRIT :file_close() fd = 1533189746
06/08/2018 10:51:18 : epoch 5b685fb2 : rhelindex : ganesha.nfsd-41167[work-197] file_close :FSAL :CRIT :file_close() fd = 1533189746
There was a read between open and first close.
Is this a known issue in that version of ganesha?
--Satish
On Mon, Aug 6, 2018 at 8:35 AM, Daniel Gryniewicz <dang@redhat.com <mailto:dang@redhat.com>> wrote:
No, there should be a single close for each open. There may be
multiple opens, but only a single close for each open.
Which version of Ganesha?
Daniel
On 08/03/2018 10:01 PM, You Me wrote:
When I write a lot of data to an NFS share using NFSv3 clients,
I see that Nfs-Ganesha opens file once but calls close on same
FD multiple times.
What is the reason behind that?
—You
_______________________________________________ <mailto:devel@lists.nfs-ganesh
Devel mailing list -- devel@lists.nfs-ganesha.orga.org >
To unsubscribe send an email to
devel-leave@lists.nfs-ganesha.org
<mailto:devel-leave@lists.nfs-ganesha.org >
_______________________________________________ <mailto:devel@lists.nfs-ganesh
Devel mailing list -- devel@lists.nfs-ganesha.orga.org >
To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org
<mailto:devel-leave@lists.nfs-ganesha.org >
_______________________________________________
Devel mailing list -- devel@lists.nfs-ganesha.org
To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org