On Tue, 2016-10-25 at 15:56 +0300, Ian Ray wrote:
> Any news on this? f48b0534f110397246809d279225afedb28aa233 does not
> resolve the EINTR on slow systems.
Merged:
remote: I: patch #89032 updated using rev
4cfee398726adf89db4b632ade7d6cab8b78282e.
remote: I: 1 patch(es) updated to state
On Thu, May 26, 2016 at 04:43:44PM +0100, Daniel Stone wrote:
> On 25 May 2016 at 08:41, Ian Ray wrote:
> > posix_fallocate() does an explicit rollback if it gets EINTR, and
> > this is a problem on slow systems because when the allocation size
> > is sufficiently large
On 25 May 2016 at 08:41, Ian Ray wrote:
> posix_fallocate() does an explicit rollback if it gets EINTR, and
> this is a problem on slow systems because when the allocation size
> is sufficiently large posix_fallocate() will always be interrupted
> by the smart scheduler's SIGALRM.
On Wed, 25 May 2016 10:41:53 +0300
Ian Ray wrote:
> posix_fallocate() does an explicit rollback if it gets EINTR, and
> this is a problem on slow systems because when the allocation size
> is sufficiently large posix_fallocate() will always be interrupted
> by the smart
posix_fallocate() does an explicit rollback if it gets EINTR, and
this is a problem on slow systems because when the allocation size
is sufficiently large posix_fallocate() will always be interrupted
by the smart scheduler's SIGALRM.
Changes since v1 - big comment in the code to explain what is