Groups | Search | Server Info | Login | Register
Groups > alt.os.linux.mint > #43979
| 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.
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 alt.os.linux.mint | Previous | Next — Previous in thread | Next in thread | Find similar
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 azigni <azigni@yahoo.com> - 2025-01-24 19:38 +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 Gordon <Gordon@leaf.net.nz> - 2025-01-24 23:59 +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