On Mon, Jun 16, 2014 at 12:13:07AM +0200, Lennart Poettering wrote:
On Sat, 14.06.14 09:52, Goffredo Baroncelli (kreij...@libero.it) wrote:
Which effectively means that by the time the 8 MiB is filled, each 4 KiB
block has been rewritten to a new location and is now an extent unto
On 17/06/14 02:13, cwillu wrote:
It's not a mmap problem, it's a small writes with an msync or fsync
after each one problem.
And for logging, that is exactly what is wanted to see why whatever
crashed...
Except...
Whilst logging, hold off on the msync/fsync unless the next log message
to be
On Jun 16, 2014, at 7:13 PM, cwillu cwi...@cwillu.com wrote:
It's not a mmap problem, it's a small writes with an msync or fsync
after each one problem.
For the case of sequential writes (via write or mmap), padding writes
to page boundaries would help, if the wasted space isn't an issue.
On Mon, Jun 16, 2014 at 6:13 PM, cwillu cwi...@cwillu.com wrote:
For the case of sequential writes (via write or mmap), padding writes
to page boundaries would help, if the wasted space isn't an issue.
Another approach, again assuming all other writes are appends, would
be to periodically (but
On 06/17/2014 08:46 PM, Filipe Brandenburger wrote:
On Mon, Jun 16, 2014 at 6:13 PM, cwillu cwi...@cwillu.com wrote:
For the case of sequential writes (via write or mmap), padding writes
to page boundaries would help, if the wasted space isn't an issue.
Another approach, again assuming all
On Mon, 16.06.14 09:05, Josef Bacik (jba...@fb.com) wrote:
So you are doing all the right things from what I can tell, I'm just
a little confused about when you guys run fsync. From what I can
tell it's only when you open the journal file and when you switch it
to offline. I didn't look too
On Mon, 16.06.14 10:17, Russell Coker (russ...@coker.com.au) wrote:
I am not really following though why this trips up btrfs though. I am
not sure I understand why this breaks btrfs COW behaviour. I mean,
fallocate() isn't necessarily supposed to write anything really, it's
mostly about
On Mon, 16 Jun 2014 12:14:49 Lennart Poettering wrote:
On Mon, 16.06.14 10:17, Russell Coker (russ...@coker.com.au) wrote:
I am not really following though why this trips up btrfs though. I am
not sure I understand why this breaks btrfs COW behaviour. I mean,
fallocate() isn't
On 2014-06-16 06:35, Russell Coker wrote:
On Mon, 16 Jun 2014 12:14:49 Lennart Poettering wrote:
On Mon, 16.06.14 10:17, Russell Coker (russ...@coker.com.au) wrote:
I am not really following though why this trips up btrfs though. I am
not sure I understand why this breaks btrfs COW behaviour.
On Mon, Jun 16, 2014 at 2:14 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Mon, 16.06.14 10:17, Russell Coker (russ...@coker.com.au) wrote:
I am not really following though why this trips up btrfs though. I am
not sure I understand why this breaks btrfs COW behaviour. I mean,
On 06/16/2014 03:14 AM, Lennart Poettering wrote:
On Mon, 16.06.14 10:17, Russell Coker (russ...@coker.com.au) wrote:
I am not really following though why this trips up btrfs though. I am
not sure I understand why this breaks btrfs COW behaviour. I mean,
fallocate() isn't necessarily
Hi Lennart,
On 06/16/2014 12:13 AM, Lennart Poettering wrote:
I am not really following though why this trips up btrfs though. I am
not sure I understand why this breaks btrfs COW behaviour. I mean,
fallocate() isn't necessarily supposed to write anything really, it's
mostly about allocating
Hi all,
in this blog [1] I collected all the results of the tests which I performed in
order to investigate a bit this performance problem between systemd and btrfs.
I had to put these results in a blog, because there are several images. Below a
brief summary.
I took an old machine (a P4
On 16/06/14 17:05, Josef Bacik wrote:
On 06/16/2014 03:14 AM, Lennart Poettering wrote:
On Mon, 16.06.14 10:17, Russell Coker (russ...@coker.com.au) wrote:
I am not really following though why this trips up btrfs though. I am
not sure I understand why this breaks btrfs COW behaviour. I
On 06/16/2014 12:52 PM, Martin wrote:
On 16/06/14 17:05, Josef Bacik wrote:
On 06/16/2014 03:14 AM, Lennart Poettering wrote:
On Mon, 16.06.14 10:17, Russell Coker (russ...@coker.com.au) wrote:
I am not really following though why this trips up btrfs though. I am
not sure I understand why
On 06/16/2014 03:52 PM, Martin wrote:
On 16/06/14 17:05, Josef Bacik wrote:
On 06/16/2014 03:14 AM, Lennart Poettering wrote:
On Mon, 16.06.14 10:17, Russell Coker (russ...@coker.com.au) wrote:
I am not really following though why this trips up btrfs though. I am
not sure I understand why
It's not a mmap problem, it's a small writes with an msync or fsync
after each one problem.
For the case of sequential writes (via write or mmap), padding writes
to page boundaries would help, if the wasted space isn't an issue.
Another approach, again assuming all other writes are appends, would
On Sat, 14.06.14 09:52, Goffredo Baroncelli (kreij...@libero.it) wrote:
Which effectively means that by the time the 8 MiB is filled, each 4 KiB
block has been rewritten to a new location and is now an extent unto
itself. So now that 8 MiB is composed of 2048 new extents, each one a
On Wed, 11.06.14 20:32, Chris Murphy (li...@colorremedies.com) wrote:
systemd has a very stupid journal write pattern. It checks if there
is space in the file for the write, and if not it fallocates the
small amount of space it needs (it does *4 byte* fallocate calls!)
Not really the case.
On Sun, 15.06.14 05:43, Duncan (1i5t5.dun...@cox.net) wrote:
The base problem isn't fallocate per se, rather, tho it's the trigger in
this case. The base problem is that for COW-based filesystems, *ANY*
rewriting of existing file content results in fragmentation.
It just so happens that
On Sat, 14.06.14 12:59, Kai Krakow (hurikha...@gmail.com) wrote:
Duncan 1i5t5.dun...@cox.net schrieb:
As they say, Whoosh!
At least here, I interpreted that remark as primarily sarcastic
commentary on the systemd devs' apparent attitude, which can be
(controversially) summarized
On Mon, 16 Jun 2014 00:13:07 Lennart Poettering wrote:
On Sat, 14.06.14 09:52, Goffredo Baroncelli (kreij...@libero.it) wrote:
Which effectively means that by the time the 8 MiB is filled, each 4 KiB
block has been rewritten to a new location and is now an extent unto
itself. So now
On Sun, Jun 15, 2014 at 5:17 PM, Russell Coker russ...@coker.com.au wrote:
I just did some tests using fallocate(1). I did the tests both with and
without the -n option which appeared to make no difference.
I started by allocating a 24G file on a 106G filesystem that had 30G free
according
On Sun, 15 Jun 2014 18:06:34 John Williams wrote:
Why does it take 2 minutes? On XFS or ext4, fallocate is almost
instantaneous, even for multi-Terabyte allocations.
According the fallocate man page, preallocation should be quick and
require no IO:
fallocate is used to manipulate
On Jun 15, 2014, at 4:34 PM, Lennart Poettering lenn...@poettering.net wrote:
On Wed, 11.06.14 20:32, Chris Murphy (li...@colorremedies.com) wrote:
systemd has a very stupid journal write pattern. It checks if there
is space in the file for the write, and if not it fallocates the
small
Fallocate is a red herring except insofar as it's a hint that btrfs
isn't making much use of: you see the same behaviour with small writes
to an mmap'ed file that's msync'ed after each write, and likewise with
plain old appending small writes with an fsync after each write, with
or without
26 matches
Mail list logo
