* 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, other threads:[~2019-07-29 16:07 UTC | newest] 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).