[Top] [All Lists]

Re: posix_fallocate

To: Krzysztof Błaszkowski <kb@xxxxxxxxxxxxxxx>
Subject: Re: posix_fallocate
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Mon, 10 May 2010 09:39:48 -0500
Cc: xfs@xxxxxxxxxxx
In-reply-to: <201005100911.52491.kb@xxxxxxxxxxxxxxx>
References: <201005071022.37863.kb@xxxxxxxxxxxxxxx> <4BE43F34.40309@xxxxxxxxxxx> <4BE44587.6090603@xxxxxxxxxxx> <201005100911.52491.kb@xxxxxxxxxxxxxxx>
User-agent: Thunderbird (Macintosh/20100228)
Krzysztof Błaszkowski wrote:
> On Friday 07 May 2010 18:53, Eric Sandeen wrote:
>> Eric Sandeen wrote:
>>> Krzysztof Błaszkowski wrote:
>>>> Hello,
>>>> I use this to preallocate large space but found an issue.
>>>> Posix_fallocate works right with sizes like 100G, 1T and even 10T on
>>>> some boxes (on some other can fail after e.g. 7T threshold) but if i
>>>> tried e.g. 16T the user space process would be "R"unning forever and it
>>>> is not interruptible. Furthermore some other not related processes like
>>>> sshd, bash enter D state. There is nothing in kernel log.
>> Oh, one thing you should know is that depending on your version of glibc,
>> posix_fallocate may be writing 0s and not using preallocation calls.
> I am absolutely sure that recent libc doesn't emulate this syscall 

right, recent glibc does not (unless the underlying fs doesn't support it)


> We stick with which seems to be good for us. We do not change 
> kernels 
> easily, as soon as higher revision arrives because it doesn't make sense from 
> stability point of view. We have seen too many times regression bugs so if we 
> are confident with some revision then there is no point to change this.

It was just a testing suggestion, but I already tested upstream and the problem
persists, now just need to find the time to dig into it.


<Prev in Thread] Current Thread [Next in Thread>