On 02/02/15 17:49, Kevin Wolf wrote:
Am 02.02.2015 um 15:20 hat Peter Lieven geschrieben:
Am 02.02.2015 um 15:16 schrieb Kevin Wolf:
Am 02.02.2015 um 15:12 hat Peter Lieven geschrieben:
Am 02.02.2015 um 15:04 schrieb Kevin Wolf:
Am 02.02.2015 um 14:55 hat Peter Lieven geschrieben:
Am 02.02.2
Am 02.02.2015 um 15:20 hat Peter Lieven geschrieben:
> Am 02.02.2015 um 15:16 schrieb Kevin Wolf:
> >Am 02.02.2015 um 15:12 hat Peter Lieven geschrieben:
> >>Am 02.02.2015 um 15:04 schrieb Kevin Wolf:
> >>>Am 02.02.2015 um 14:55 hat Peter Lieven geschrieben:
> Am 02.02.2015 um 14:23 schrieb Kev
On 02/02/15 17:20, Peter Lieven wrote:
Am 02.02.2015 um 15:16 schrieb Kevin Wolf:
Am 02.02.2015 um 15:12 hat Peter Lieven geschrieben:
Am 02.02.2015 um 15:04 schrieb Kevin Wolf:
Am 02.02.2015 um 14:55 hat Peter Lieven geschrieben:
Am 02.02.2015 um 14:23 schrieb Kevin Wolf:
Am 30.01.2015 um 0
Am 02.02.2015 um 15:16 schrieb Kevin Wolf:
Am 02.02.2015 um 15:12 hat Peter Lieven geschrieben:
Am 02.02.2015 um 15:04 schrieb Kevin Wolf:
Am 02.02.2015 um 14:55 hat Peter Lieven geschrieben:
Am 02.02.2015 um 14:23 schrieb Kevin Wolf:
Am 30.01.2015 um 09:42 hat Denis V. Lunev geschrieben:
fa
Am 02.02.2015 um 15:12 hat Peter Lieven geschrieben:
> Am 02.02.2015 um 15:04 schrieb Kevin Wolf:
> >Am 02.02.2015 um 14:55 hat Peter Lieven geschrieben:
> >>Am 02.02.2015 um 14:23 schrieb Kevin Wolf:
> >>>Am 30.01.2015 um 09:42 hat Denis V. Lunev geschrieben:
> fallocate() works fine and could
Am 02.02.2015 um 15:04 schrieb Kevin Wolf:
Am 02.02.2015 um 14:55 hat Peter Lieven geschrieben:
Am 02.02.2015 um 14:23 schrieb Kevin Wolf:
Am 30.01.2015 um 09:42 hat Denis V. Lunev geschrieben:
fallocate() works fine and could handle properly with arbitrary size
requests. There is no sense to
Am 02.02.2015 um 14:55 hat Peter Lieven geschrieben:
> Am 02.02.2015 um 14:23 schrieb Kevin Wolf:
> >Am 30.01.2015 um 09:42 hat Denis V. Lunev geschrieben:
> >>fallocate() works fine and could handle properly with arbitrary size
> >>requests. There is no sense to reduce the amount of space to fallo
Am 02.02.2015 um 14:23 schrieb Kevin Wolf:
Am 30.01.2015 um 09:42 hat Denis V. Lunev geschrieben:
fallocate() works fine and could handle properly with arbitrary size
requests. There is no sense to reduce the amount of space to fallocate.
The bigger is the size, the better is the performance as
Am 30.01.2015 um 09:42 hat Denis V. Lunev geschrieben:
> fallocate() works fine and could handle properly with arbitrary size
> requests. There is no sense to reduce the amount of space to fallocate.
> The bigger is the size, the better is the performance as the amount of
> journal updates is reduc
fallocate() works fine and could handle properly with arbitrary size
requests. There is no sense to reduce the amount of space to fallocate.
The bigger is the size, the better is the performance as the amount of
journal updates is reduced.
The patch changes behavior for both generic filesystem and
On 2015-01-28 at 13:38, Denis V. Lunev wrote:
fallocate() works fine and could handle properly with arbitrary size
requests. There is no sense to reduce the amount of space to fallocate.
The bigger is the size, the better is the performance as the amount of
journal updates is reduced.
The patch
fallocate() works fine and could handle properly with arbitrary size
requests. There is no sense to reduce the amount of space to fallocate.
The bigger is the size, the better is the performance as the amount of
journal updates is reduced.
The patch changes behavior for both generic filesystem and
On 27/01/15 21:05, Max Reitz wrote:
On 2015-01-27 at 08:51, Denis V. Lunev wrote:
fallocate() works fine and could handle properly with arbitrary size
requests.
Maybe "could properly handle arbitrary size requests" (or
"...arbitrarily sized requests")?
There is no sense to reduce the amoun
On 2015-01-27 at 08:51, Denis V. Lunev wrote:
fallocate() works fine and could handle properly with arbitrary size
requests.
Maybe "could properly handle arbitrary size requests" (or
"...arbitrarily sized requests")?
There is no sense to reduce the amount of space to fallocate.
The bigger i
On 27/01/15 21:05, Max Reitz wrote:
On 2015-01-27 at 08:51, Denis V. Lunev wrote:
fallocate() works fine and could handle properly with arbitrary size
requests.
Maybe "could properly handle arbitrary size requests" (or
"...arbitrarily sized requests")?
There is no sense to reduce the amoun
fallocate() works fine and could handle properly with arbitrary size
requests. There is no sense to reduce the amount of space to fallocate.
The bigger is the size, the better is the performance as the amount of
journal updates is reduced.
Signed-off-by: Denis V. Lunev
CC: Kevin Wolf
CC: Stefan
16 matches
Mail list logo