[kwlug-disc] Accessing recently-written NFS files

[Bob Jonkman]

I understand the phrase 'command1 && command2' to mean "execute command2 
if and only if command1 returns 0' -- so what does command1 return? And 
if that's not 0, then why?

--Bob.


On 2022-12-13 07:48, Adam Glauser wrote:
>     While I was trying to look up rpcdebug I ran into (what else?) the
>     ArchLinux wiki:
>     https://wiki.archlinux.org/title/NFS/Troubleshooting#Close-to-open/flush-on-close <https://wiki.archlinux.org/title/NFS/Troubleshooting#Close-to-open/flush-on-close>
> 
> 
> Thanks Paul. This is not something I'd come across as of yet.
> 
>       (Apologies if this is something you have already investigated. I
>     am aware you are also capable of using a search engine.)
> 
> 
> Not capable enough it seems!
> 
>     If 'mv' works after some time, then probably you may be right.
> 
>     NOTE: Depending on your current working directory, you may want to quote
>     the glob, like
>           -name 'test_file*'
> 
> 
> Thanks William, and good point on the quoting. In this instance the 
> working directory is mostly empty, but good practice is always worth it.
> 
> On Mon, Dec 12, 2022 at 7:25 PM Paul Nijjar via kwlug-disc 
> <kwlug-disc at kwlug.org <mailto:kwlug-disc at kwlug.org>> wrote:
> 
> 
>     I do not have direct experience with this. I was going to suggest
>     enabling logging with the "rpcdebug" command, but maybe that command
>     has been deprecated? It does not seem to exist on Debian any more.
> 
>     While I was trying to look up rpcdebug I ran into (what else?) the
>     ArchLinux wiki:
>     https://wiki.archlinux.org/title/NFS/Troubleshooting#Close-to-open/flush-on-close <https://wiki.archlinux.org/title/NFS/Troubleshooting#Close-to-open/flush-on-close>
> 
>     But do not think that 10 byte vs 10k files would be the difference
>     here? Do you get permission denied errors if you run the below loop
>     with 10 byte files, but run it 10000 times? Still, this seems like it
>     might be worth investigating if you haven't done so already.
> 
>     Windows also comes with its own logs, which can sometimes be helpful.
>     If the FS is being served by a Windows machine is it serving as the
>     NFS server, and RH7 is the client? You can look in Event Viewer for
>     logs on the Windows side:
>     https://techcommunity.microsoft.com/t5/storage-at-microsoft/server-for-nfs-diagnostics/ba-p/424632 <https://techcommunity.microsoft.com/t5/storage-at-microsoft/server-for-nfs-diagnostics/ba-p/424632>
> 
>     (Apologies if this is something you have already investigated. I am
>     aware you are also capable of using a search engine.)
> 
>     - Paul
> 
>     On Mon, Dec 12, 2022 at 05:45:04PM -0500, Adam Glauser wrote:
>      > I've got a bit of a head-scratcher on my hands.
>      >
>      > I have a filesystem on my application's host (Oracle/RH Linux 7)
>     that is
>      > mounted via NFS. I believe the FS is served by a Windows machine.
>      >
>      > If I do something like this, everything is fine
>      > $ for i in {1..100};
>      > do
>      > head -c 10 </dev/urandom >"/nfs_share/tmp/test_file${i}";
>      > done && find /nfs_share/tmp/ -name test_file* -exec mv {}
>      > /nfs_share/final_location
>      > \;
>      >
>      > However, if I bump up the file size to 10K, suddenly they all
>     fail to mv
>      > with "Permission denied" errors. Waiting some time and retrying
>     the 'mv'
>      > causes it to complete successfully.
>      >
>      > I think this means that there is some kind of client-side caching
>      > happening, so that the file appears to be written, while NFS is still
>      > working away on transferring it to the storage location. Trying
>     to unlink
>      > the file before the cache is emptied is disallowed, presumably to
>     avoid
>      > data loss.
>      >
>      > Am I headed in the right direction by trying to delve into the
>     details of
>      > NFS caching and file locking? Any other avenues that someone can
>     suggest?
>      >
>      > Thanks,
>      > Adam
> 
>      > _______________________________________________
>      > kwlug-disc mailing list
>      > To unsubscribe, send an email to kwlug-disc-leave at kwlug.org
>     <mailto:kwlug-disc-leave at kwlug.org>
>      > with the subject "unsubscribe", or email
>      > kwlug-disc-owner at kwlug.org <mailto:kwlug-disc-owner at kwlug.org> to
>     contact a human being.
> 
> 
>     -- 
>     Events: https://feeds.off-topic.kwlug.org
>     <https://feeds.off-topic.kwlug.org>
>     Housing: https://unionsd.coop <https://unionsd.coop>
>     Blog: http://pnijjar.freeshell.org <http://pnijjar.freeshell.org>
> 
>     _______________________________________________
>     kwlug-disc mailing list
>     To unsubscribe, send an email to kwlug-disc-leave at kwlug.org
>     <mailto:kwlug-disc-leave at kwlug.org>
>     with the subject "unsubscribe", or email
>     kwlug-disc-owner at kwlug.org <mailto:kwlug-disc-owner at kwlug.org> to
>     contact a human being.
> 
> 
> _______________________________________________
> kwlug-disc mailing list
> To unsubscribe, send an email to kwlug-disc-leave at kwlug.org
> with the subject "unsubscribe", or email
> kwlug-disc-owner at kwlug.org to contact a human being.

-- 
Bob Jonkman <bjonkman at sobac.com>          Phone: +1-519-635-9413
SOBAC Microcomputer Services             http://sobac.com/sobac/
Software   ---   Office & Business Automation   ---   Consulting
GnuPG Fngrprnt:04F7 742B 8F54 C40A E115 26C2 B912 89B0 D2CC E5EA