Groups | Search | Server Info | Login | Register
Groups > alt.os.linux.mint > #43979
| Path | csiph.com!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail |
|---|---|
| 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 | Tue, 28 Jan 2025 22:58:45 +0000 |
| Organization | A noiseless patient Spider |
| Lines | 66 |
| 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> |
| MIME-Version | 1.0 |
| Content-Type | text/plain; charset=UTF-8 |
| Content-Transfer-Encoding | 8bit |
| Injection-Date | Tue, 28 Jan 2025 23:58:46 +0100 (CET) |
| Injection-Info | dont-email.me; posting-host="7473b8a4b4a8c20f1c5082ab9ab04018"; logging-data="2137436"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX197tSBTT6Gl2diosI8hEiLfP5/XX6h5IFE=" |
| Cancel-Lock | sha1:36uuO/enYmjfIdP5n3hrSkF9tJ0= |
| X-Newsreader | Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) |
| Xref | csiph.com alt.os.linux.mint:43979 comp.os.linux.networking:8542 comp.unix.bsd.freebsd.misc:4158 |
Cross-posted to 3 groups.
Show key headers only | 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 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