[issue43743] BlockingIOError: [Errno 11] Resource temporarily unavailable: on GPFS.

Marvin Poul added the comment: Here's the small patch. Sadly I have no overview what the affected linux kernel version are. I guess technically you can all this "working around a bug in specific linux version", but since it's a very minor change that saves one syscall even for

[issue43743] BlockingIOError: [Errno 11] Resource temporarily unavailable: on GPFS.

Marvin Poul added the comment: I hope you don't mind me necro posting, but I ran into this issue again and have a small patch to solve it. I attached an MWE that triggers the BlockingIOError reliably on ext4 filesystems in linux 4.12.14 and python 3.8.12. Running under strace -e sendfile

[issue43743] BlockingIOError: [Errno 11] Resource temporarily unavailable: on GPFS.

Change by Giampaolo Rodola' : -- pull_requests: +24674 pull_request: https://github.com/python/cpython/pull/26024 ___ Python tracker ___

[issue43743] BlockingIOError: [Errno 11] Resource temporarily unavailable: on GPFS.

Giampaolo Rodola' added the comment: > The question seems to be is if it should be okay to _GiveUpOnFastCopy after a > partial (incomplete) copy has already occurred via sendfile. I think it should not. For posterity: my rationale for introducing _USE_CP_SENDFILE was to allow monkey

[issue43743] BlockingIOError: [Errno 11] Resource temporarily unavailable: on GPFS.

Gregory P. Smith added the comment: The logic for bailing out to a slow copy is currently: https://github.com/python/cpython/blob/main/Lib/shutil.py#L158 that condition appears to not be happening in Alexei's test. Suggesting that either at least one sendfile call succeeded and thus offset

[issue43743] BlockingIOError: [Errno 11] Resource temporarily unavailable: on GPFS.

Pablo Conesa added the comment: So, is it ok, when the fast copy fails, not to _GiveupOnFastCopy(err)? I can understand that fast copy might fail, but then the Giveup part should happen and it wasn't. Additionally, _USE_CP_SENDFILE could be taken, optionally from an environment variable to

[issue43743] BlockingIOError: [Errno 11] Resource temporarily unavailable: on GPFS.

Gregory P. Smith added the comment: I don't believe CPython should be working around a bug in specific Linux kernel versions in the standard library unless they are extremely pernicious and not considered to be a bug and thus ever be fixed in the OS kernel. As the sendfile system call

[issue43743] BlockingIOError: [Errno 11] Resource temporarily unavailable: on GPFS.

PEAR added the comment: Most probably related: https://www.ibm.com/support/pages/apar/IJ28891 -- ___ Python tracker ___ ___

[issue43743] BlockingIOError: [Errno 11] Resource temporarily unavailable: on GPFS.

Change by PEAR : -- nosy: +PEAR ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43743] BlockingIOError: [Errno 11] Resource temporarily unavailable: on GPFS.

Change by Alexei Colin : -- versions: +Python 3.8 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43743] BlockingIOError: [Errno 11] Resource temporarily unavailable: on GPFS.

Change by Alexei Colin : -- versions: +Python 3.10 -Python 3.8 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue43743] BlockingIOError: [Errno 11] Resource temporarily unavailable: on GPFS.

Alexei Colin added the comment: Can confirm that this BlockingIOError happens on GPFS (alpine) on Summit supercomputer, tested with Python 3.8 and 3.10a7. I found that it happens only for file sizes above 65536. Minimal example: This filesize works: $ rm -f srcfile dstfile && truncate

[issue43743] BlockingIOError: [Errno 11] Resource temporarily unavailable: on GPFS.

New submission from Pablo Conesa : Hi, one of our users is reporting this starting to happen in a GPFS. All has been working fine for NTFS so far for many years. I had a look at my shutil code, and I can see the try/except code trying to fall back to the "slower" copyfileobj(fsrc, fdst).