Linux CIFS filesystem development
 help / color / mirror / Atom feed
From: Paulo Alcantara <pc@manguebit.com>
To: Nicolas Baranger <nicolas.baranger@3xo.fr>
Cc: Christoph Hellwig <hch@infradead.org>,
	hch@lst.de, David Howells <dhowells@redhat.com>,
	netfs@lists.linux.dev, linux-cifs@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	Steve French <smfrench@gmail.com>,
	Jeff Layton <jlayton@kernel.org>,
	Christian Brauner <brauner@kernel.org>
Subject: Re: [netfs/cifs - Linux 6.14] loop on file cat + file copy when files are on CIFS share
Date: Mon, 21 Apr 2025 20:45:04 -0300	[thread overview]
Message-ID: <53697288e2891aea51061c54a2e42595@manguebit.com> (raw)
In-Reply-To: <e63e7c7ec32e3014eb758fd6f8679f93@3xo.fr>

Nicolas Baranger <nicolas.baranger@3xo.fr> writes:

> If you need more traces or details on (both?) issues :
>
> - 1) infinite loop issue during 'cat' or 'copy' since Linux 6.14.0
>
> - 2) (don't know if it's related) the very high number of several bytes 
> TCP packets transmitted in SMB transaction (more than a hundred) for a 5 
> bytes file transfert under Linux 6.13.8

According to your mount options and network traces, cat(1) is attempting
to read 16M from 'toto' file, in which case netfslib will create 256
subrequests to handle 64K (rsize=65536) reads from 'toto' file.

The first 64K read at offset 0 succeeds and server returns 5 bytes, the
client then sets NETFS_SREQ_HIT_EOF to indicate that this subrequest hit
the EOF.  The next subrequests will still be processed by netfslib and
sent to the server, but they all fail with STATUS_END_OF_FILE.

So, the problem is with short DIO reads in netfslib that are not being
handled correctly.  It is returning a fixed number of bytes read to
every read(2) call in your cat command, 16711680 bytes which is the
offset of last subrequest.  This will make cat(1) retry forever as
netfslib is failing to return the correct number of bytes read,
including EOF.

While testing a potential fix, I also found other problems with DIO in
cifs.ko, so I'm working with Dave to get the proper fixes for both
netfslib and cifs.ko.

I've noticed that you disabled caching with 'cache=none', is there any
particular reason for that?

Have you also set rsize, wsize and bsize mount options?  If so, why?

If you want to keep 'cache=none', then a possible workaround for you
would be making rsize and wsize always greater than bsize.  The default
values (rsize=4194304,wsize=4194304,bsize=1048576) would do it.

  reply	other threads:[~2025-04-21 23:45 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-24 10:40 [netfs/cifs - Linux 6.14] loop on file cat + file copy when files are on CIFS share Nicolas Baranger
2025-03-27 11:15 ` Nicolas Baranger
2025-03-28 10:45   ` Christoph Hellwig
2025-04-04  8:50     ` Nicolas Baranger
2025-04-04 13:54       ` Paulo Alcantara
2025-04-10  8:43         ` Nicolas Baranger
2025-04-15 18:28           ` Paulo Alcantara
2025-04-17 10:10             ` Nicolas Baranger
2025-04-21 23:45               ` Paulo Alcantara [this message]
2025-04-23 16:28                 ` Nicolas Baranger
2025-04-24  7:40                   ` Nicolas Baranger
2025-04-24  8:39                     ` Nicolas Baranger
2025-04-24 14:25                       ` Paulo Alcantara
2025-05-06 22:53                         ` Paulo Alcantara
2025-05-07 15:58                           ` Nicolas Baranger
2025-04-24 13:58                     ` Steve French

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53697288e2891aea51061c54a2e42595@manguebit.com \
    --to=pc@manguebit.com \
    --cc=brauner@kernel.org \
    --cc=dhowells@redhat.com \
    --cc=hch@infradead.org \
    --cc=hch@lst.de \
    --cc=jlayton@kernel.org \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netfs@lists.linux.dev \
    --cc=nicolas.baranger@3xo.fr \
    --cc=smfrench@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox