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