Path: csiph.com!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: pinnerite 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> References: 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 On Tue, 28 Jan 2025 08:06:20 +0000 Mike Scott 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 > > > > 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