[kwlug-disc] Accessing recently-written NFS files

[Adam Glauser]

>
> 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


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> 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
>
> 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
>
> (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
> > with the subject "unsubscribe", or email
> > kwlug-disc-owner at kwlug.org to contact a human being.
>
>
> --
> Events: https://feeds.off-topic.kwlug.org
> Housing: https://unionsd.coop
> Blog: http://pnijjar.freeshell.org
>
> _______________________________________________
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20221213/4744aff0/attachment.htm>