Objet : Developers list for StarPU
Archives de la liste
- From: Samuel Thibault <samuel.thibault@inria.fr>
- To: barbier@imacs.polytechnique.fr
- Cc: starpu-devel@inria.fr
- Subject: Re: [starpu-devel] Corrupted large ooc files with unistd backend
- Date: Mon, 5 Dec 2022 18:31:18 +0100
- Authentication-results: mail3-relais-sop.national.inria.fr; dkim=none (message not signed) header.i=none; spf=SoftFail smtp.mailfrom=samuel.thibault@inria.fr; dmarc=fail (p=none dis=none) d=inria.fr
- Organization: I am not organized
barbier@imacs.polytechnique.fr, le lun. 05 déc. 2022 09:45:16 +0100, a ecrit:
> write.2 manpage constains this note on Linux:
>
> On Linux, write() (and similar system calls) will transfer at most
> 0x7ffff000 (2,147,479,552) bytes, returning the number of bytes actually
> transferred. (This is true on both 32-bit and 64-bit systems.)
Oh :/
> As a result, files contain only zeros after offset 0x7ffff000.
> This is pretty easy to fix in
> starpu_unistd_global_read/write with a loop, but I do not see how to deal
> with asynchronous IO; I discarded AIO when size is too large in attached
> patch.
Ok, I have pushed that for a start. I have noted in the code
that we could make starpu_unistd_global_test_request and
starpu_unistd_global_test_request resubmit an updated request.
Thanks!
Samuel
- [starpu-devel] Corrupted large ooc files with unistd backend, barbier, 05/12/2022
- Re: [starpu-devel] Corrupted large ooc files with unistd backend, Samuel Thibault, 05/12/2022
Archives gérées par MHonArc 2.6.19+.