Linux-CIFS Archive on lore.kernel.org
 help / color / Atom feed
* Search for advice on testing whether a local CIFS fd closed remotely
@ 2019-07-26  8:22 Gefei Li
  2019-07-28  0:08 ` Steve French
  0 siblings, 1 reply; 4+ messages in thread
From: Gefei Li @ 2019-07-26  8:22 UTC (permalink / raw)
  To: linux-cifs

Hi,

From some stack overflow result I know that on a local ext4/fat32
system, we can test whether a file descriptor is valid through
"fcntl(fd, F_GETFD)". But in cifs cases, a fd typically bind a local
fd to remote handle, do we have some c function/syscall that can test
whether the fd is remotely closed?

I've tried some windows way like "ioctl", which works well, and in
linux local file system "fcntl" works. Tried to use "fcntl" on kernel
5.1.15, found no server request is received.. Could you please give me
some advice on testing whether a fd is remoted closed in CIFS client?

Appreciate for your help!

Best Regards,
Gefei

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Search for advice on testing whether a local CIFS fd closed remotely
  2019-07-26  8:22 Search for advice on testing whether a local CIFS fd closed remotely Gefei Li
@ 2019-07-28  0:08 ` Steve French
  2019-07-29  3:03   ` Gefei Li
  0 siblings, 1 reply; 4+ messages in thread
From: Steve French @ 2019-07-28  0:08 UTC (permalink / raw)
  To: Gefei Li; +Cc: CIFS

On Fri, Jul 26, 2019 at 3:22 AM Gefei Li <gefeili.2013@gmail.com> wrote:
>
> Hi,
>
> From some stack overflow result I know that on a local ext4/fat32
> system, we can test whether a file descriptor is valid through
> "fcntl(fd, F_GETFD)". But in cifs cases, a fd typically bind a local
> fd to remote handle, do we have some c function/syscall that can test
> whether the fd is remotely closed?
>
> I've tried some windows way like "ioctl", which works well, and in
> linux local file system "fcntl" works. Tried to use "fcntl" on kernel
> 5.1.15, found no server request is received.. Could you please give me
> some advice on testing whether a fd is remoted closed in CIFS client?

both F_GETFD and F_GETFL look like they check in the local VFS only
(aren't passed down to the file system, whether ext4 or cifs or even nfs)
for the value of these flags (see do_fcntl function in fs/fcntl.c)

In general an open of a file (over an SMB3 mount) will result in a open
over a file on the server.   You can see the detailed information on
the network file handle ("PersistentFileID") open on the server by (on
the Linux client) doing:

       cat /proc/fs/cifs/open_files

If you were worried about a network crash temporarily closing remote handles
(in which case you might temporarily have a local handle which is not
open on the
server) you could (in theory) do:

      /proc/fs/cifs/Stats | grep "Open files"

but I did notice a bug (in the processing of one of those counters for
that /proc file)
in which we are leaking one of those two counters (the counter is
informational only
so presumably not a serious bug) and it can go negative so looking at the count
of open files on the server may not be as useful.

-- 
Thanks,

Steve

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Search for advice on testing whether a local CIFS fd closed remotely
  2019-07-28  0:08 ` Steve French
@ 2019-07-29  3:03   ` Gefei Li
  2019-07-29 16:07     ` Steve French
  0 siblings, 1 reply; 4+ messages in thread
From: Gefei Li @ 2019-07-29  3:03 UTC (permalink / raw)
  To: Steve French; +Cc: CIFS

Thanks a lot for the '/proc/fs/cifs/Stats | grep "Open files"' tip,
Steve. But it seems not working in my case(not crashing case).

I have an SMB server that is able to close handles from server side,
and if closed remotely I want to check from client side. I've done
several experiments:
1. CIFS client open, server side close
  -  both "/proc/fs/cifs/Stats" and "cat /proc/fs/cifs/open_files"
remain unchanged
2. CIFS client open, server side close, client side call "close"
function to check fd
  - "Closes" in "/proc/fs/cifs/Stats" changes "4 total 1 failed"    <-
1 failed due to server side closed?
3. CIFS client open, server side close, client side call "read"
function to check fd
  - EBADF returned while trying to "read", this is what I expect.  But
for dir handle and WR-only handles, which function should I use?

Regards,
Gefei

On Sun, Jul 28, 2019 at 8:08 AM Steve French <smfrench@gmail.com> wrote:
>
> On Fri, Jul 26, 2019 at 3:22 AM Gefei Li <gefeili.2013@gmail.com> wrote:
> >
> > Hi,
> >
> > From some stack overflow result I know that on a local ext4/fat32
> > system, we can test whether a file descriptor is valid through
> > "fcntl(fd, F_GETFD)". But in cifs cases, a fd typically bind a local
> > fd to remote handle, do we have some c function/syscall that can test
> > whether the fd is remotely closed?
> >
> > I've tried some windows way like "ioctl", which works well, and in
> > linux local file system "fcntl" works. Tried to use "fcntl" on kernel
> > 5.1.15, found no server request is received.. Could you please give me
> > some advice on testing whether a fd is remoted closed in CIFS client?
>
> both F_GETFD and F_GETFL look like they check in the local VFS only
> (aren't passed down to the file system, whether ext4 or cifs or even nfs)
> for the value of these flags (see do_fcntl function in fs/fcntl.c)
>
> In general an open of a file (over an SMB3 mount) will result in a open
> over a file on the server.   You can see the detailed information on
> the network file handle ("PersistentFileID") open on the server by (on
> the Linux client) doing:
>
>        cat /proc/fs/cifs/open_files
>
> If you were worried about a network crash temporarily closing remote handles
> (in which case you might temporarily have a local handle which is not
> open on the
> server) you could (in theory) do:
>
>       /proc/fs/cifs/Stats | grep "Open files"
>
> but I did notice a bug (in the processing of one of those counters for
> that /proc file)
> in which we are leaking one of those two counters (the counter is
> informational only
> so presumably not a serious bug) and it can go negative so looking at the count
> of open files on the server may not be as useful.
>
> --
> Thanks,
>
> Steve

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Search for advice on testing whether a local CIFS fd closed remotely
  2019-07-29  3:03   ` Gefei Li
@ 2019-07-29 16:07     ` Steve French
  0 siblings, 0 replies; 4+ messages in thread
From: Steve French @ 2019-07-29 16:07 UTC (permalink / raw)
  To: Gefei Li; +Cc: CIFS

Presumably the attempt to close a file (from the Linux client) which
the server has force closed on their side, would lead to
/proc/fs/cifs/Stats logging an error on close.   It is an unusual
situation to have a server force closed a handle in such a way that it
would return an error on an attempt by an SMB3 client to use it (more
typical would be for a resource constrained server to expire the
session and let the client reconnect its open handles as needed).

To test use of directory handles after a force close of server handles
(ie for the unusual case where the file handle is force closed on the
server side through some tool, but the client has the file still
open), you could try something similar to the "PASSTHRU_FSCTL" for
doing a query info (see e.g. the function fsctlgetobjid in cifs-utils
package smbinfo.c) after you have left a directory handle open long
enough for your force close on the server side to be done.

This is an unusual scenario though where you want to have the server
throw away state (network file handles open on a connection) without
killing the smb session (in which case the client can reconnect
transparently).

On Sun, Jul 28, 2019 at 10:03 PM Gefei Li <gefeili.2013@gmail.com> wrote:
>
> Thanks a lot for the '/proc/fs/cifs/Stats | grep "Open files"' tip,
> Steve. But it seems not working in my case(not crashing case).
>
> I have an SMB server that is able to close handles from server side,
> and if closed remotely I want to check from client side. I've done
> several experiments:
> 1. CIFS client open, server side close
>   -  both "/proc/fs/cifs/Stats" and "cat /proc/fs/cifs/open_files"
> remain unchanged
> 2. CIFS client open, server side close, client side call "close"
> function to check fd
>   - "Closes" in "/proc/fs/cifs/Stats" changes "4 total 1 failed"    <-
> 1 failed due to server side closed?
> 3. CIFS client open, server side close, client side call "read"
> function to check fd
>   - EBADF returned while trying to "read", this is what I expect.  But
> for dir handle and WR-only handles, which function should I use?
>
> Regards,
> Gefei
>
> On Sun, Jul 28, 2019 at 8:08 AM Steve French <smfrench@gmail.com> wrote:
> >
> > On Fri, Jul 26, 2019 at 3:22 AM Gefei Li <gefeili.2013@gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > From some stack overflow result I know that on a local ext4/fat32
> > > system, we can test whether a file descriptor is valid through
> > > "fcntl(fd, F_GETFD)". But in cifs cases, a fd typically bind a local
> > > fd to remote handle, do we have some c function/syscall that can test
> > > whether the fd is remotely closed?
> > >
> > > I've tried some windows way like "ioctl", which works well, and in
> > > linux local file system "fcntl" works. Tried to use "fcntl" on kernel
> > > 5.1.15, found no server request is received.. Could you please give me
> > > some advice on testing whether a fd is remoted closed in CIFS client?
> >
> > both F_GETFD and F_GETFL look like they check in the local VFS only
> > (aren't passed down to the file system, whether ext4 or cifs or even nfs)
> > for the value of these flags (see do_fcntl function in fs/fcntl.c)
> >
> > In general an open of a file (over an SMB3 mount) will result in a open
> > over a file on the server.   You can see the detailed information on
> > the network file handle ("PersistentFileID") open on the server by (on
> > the Linux client) doing:
> >
> >        cat /proc/fs/cifs/open_files
> >
> > If you were worried about a network crash temporarily closing remote handles
> > (in which case you might temporarily have a local handle which is not
> > open on the
> > server) you could (in theory) do:
> >
> >       /proc/fs/cifs/Stats | grep "Open files"
> >
> > but I did notice a bug (in the processing of one of those counters for
> > that /proc file)
> > in which we are leaking one of those two counters (the counter is
> > informational only
> > so presumably not a serious bug) and it can go negative so looking at the count
> > of open files on the server may not be as useful.
> >
> > --
> > Thanks,
> >
> > Steve



-- 
Thanks,

Steve

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, back to index

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-26  8:22 Search for advice on testing whether a local CIFS fd closed remotely Gefei Li
2019-07-28  0:08 ` Steve French
2019-07-29  3:03   ` Gefei Li
2019-07-29 16:07     ` Steve French

Linux-CIFS Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-cifs/0 linux-cifs/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-cifs linux-cifs/ https://lore.kernel.org/linux-cifs \
		linux-cifs@vger.kernel.org linux-cifs@archiver.kernel.org
	public-inbox-index linux-cifs


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-cifs


AGPL code for this site: git clone https://public-inbox.org/ public-inbox