Groups | Search | Server Info | Login | Register


Groups > comp.os.linux.networking > #8542

Re: (resolved) Re: very odd nfs behaviour

From pinnerite <pinnerite@gmail.com>
Newsgroups alt.os.linux.mint, comp.os.linux.networking, comp.unix.bsd.freebsd.misc
Subject Re: (resolved) Re: very odd nfs behaviour
Date 2025-01-28 22:58 +0000
Organization A noiseless patient Spider
Message-ID <20250128225845.7a56371ba042a64c9cb95c1b@gmail.com> (permalink)
References <vn0gn0$2ajlc$1@dont-email.me> <wwvldv0rt9i.fsf@LkoBDZeT.terraraq.uk> <vn89fh$10eh8$1@dont-email.me> <vn94jm$19o0q$9@dont-email.me> <vna35s$1maqb$1@dont-email.me>

Cross-posted to 3 groups.

Show all headers | View raw


On Tue, 28 Jan 2025 08:06:20 +0000
Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:

> On 27/01/2025 23:24, Lawrence D'Oliveiro wrote:
> > On Mon, 27 Jan 2025 15:41:37 +0000, Mike Scott wrote:
> > 
> >> In spite of my assertion (which I should have checked and didn't), the
> >> mount options differed. The working machines all specified rsize=8192.
> >> My box was using a much larger figure, of 131072 (ie 32 * 4096).
> >>
> >> It seems anything over 8192 causes this issue - that filenames get
> >> truncated.
> > 
> > I don’t understand why increasing rsize on its own would have any
> > effect: according to the docs, that only controls the maximum size of
> > packets that this end can receive; the maximum size the other end can
> > send is limited by that end’s wsize value. So increasing rsize on its
> > own should have no effect.
> > 
> > Looking up NFS mount options online, this page
> > <https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/4/html/reference_guide/s2-nfs-client-config-options#s2-nfs-client-config-options>
> > does say “be careful when changing these values; some older Linux
> > kernels and network cards do not work well with larger block sizes”.
> > 
> >> Whether that's a linux client issue or a freebsd server issue, or the
> >> result of interworking, I've no idea. Nor can I imagine why it should
> >> happen without errors being flagged up somewhere (I checked the logs at
> >> both ends) -- which is nasty, because I had a system that met the specs
> >> and mostly worked but very occasionally (< about 1 in 100k times, I
> >> reckon) failed silently. Ouch.
> > 
> > That really baffles me, that you don’t see any errors indicating there was
> > a problem.
> 
> Yes, it's an odd one in many ways. Not least because rsize/wsize are 
> supposed to be irrelevant for tcp mounts (which is all the server 
> provides anyway)
> 
> I've just tried a loopback NFS mount on the server (it's the only fbsd 
> box I have to hand) and can't force the problem to show. So presumably 
> it's something to do with the inter-system working, but I don't have the 
> knowledge to delve further :-{
> 
> So I'll have to settle for 'it works now'. But as I noted, I'm very 
> discomforted that such a problem is even possible without errors being 
> flagged somewhere.
> 
> Thanks again to all who've responded.
> 
> -- 
> Mike Scott
> Harlow, England
> 

I had a similar situation several months ago.
I tested the drive and tried repairs but in the end it was clear the drive had reached its "sell-by" date.
Then a second one went too.
Both were made by Seagate (in different countries) and manufactered five years apart.

Regards,

Alan

-- 
Linux Mint 21.3 kernel version 5.15.0-127-generic Cinnamon 6.0.4
AMD Ryzen 7 7700, Radeon RX 6600, 32GB DDR5, 1TB SSD, 2TB Barracuda

Back to comp.os.linux.networking | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

very odd nfs behaviour Mike Scott <usenet.16@scottsonline.org.uk.invalid> - 2025-01-24 16:56 +0000
  Re: very odd nfs behaviour Mike Scott <usenet.16@scottsonline.org.uk.invalid> - 2025-01-24 17:00 +0000
  Re: very odd nfs behaviour Edmund <nomail@hotmail.com> - 2025-01-24 18:01 +0100
    Re: very odd nfs behaviour Mike Scott <usenet.16@scottsonline.org.uk.invalid> - 2025-01-24 17:30 +0000
  Re: very odd nfs behaviour Richard Kettlewell <invalid@invalid.invalid> - 2025-01-24 17:55 +0000
    (resolved) Re: very odd nfs behaviour Mike Scott <usenet.16@scottsonline.org.uk.invalid> - 2025-01-27 15:41 +0000
      Re: (resolved) Re: very odd nfs behaviour Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-01-27 23:24 +0000
        Re: (resolved) Re: very odd nfs behaviour Mike Scott <usenet.16@scottsonline.org.uk.invalid> - 2025-01-28 08:06 +0000
          Re: (resolved) Re: very odd nfs behaviour "Carlos E.R." <robin_listas@es.invalid> - 2025-01-28 12:34 +0100
          Re: (resolved) Re: very odd nfs behaviour pinnerite <pinnerite@gmail.com> - 2025-01-28 22:58 +0000
  Re: very odd nfs behaviour "Carlos E.R." <robin_listas@es.invalid> - 2025-01-24 22:56 +0100
    Re: very odd nfs behaviour Paul <nospam@needed.invalid> - 2025-01-24 17:34 -0500
      Re: very odd nfs behaviour "Carlos E.R." <robin_listas@es.invalid> - 2025-01-25 01:45 +0100
    Re: very odd nfs behaviour Mike Scott <usenet.16@scottsonline.org.uk.invalid> - 2025-01-25 17:02 +0000
  Re: very odd nfs behaviour "Arti F. Idiot" <addr@is.invalid> - 2025-01-24 17:13 -0700
  Re: very odd nfs behaviour Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-01-26 00:01 +0000
  Re: very odd nfs behaviour Grant Taylor <gtaylor@tnetconsulting.net> - 2025-01-25 20:08 -0600

csiph-web