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
Martin Steigerwald posted on Sun, 15 Jun 2014 23:31:07 +0200 as excerpted:
I always thought that the whole point of fallocate is that it *doesn´t*
write out anything, but just reserves the space. Thus I don´t see how
COW can have any adverse effect here.
Tying up loose ends... I was wrong on
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
Duncan 1i5t5.dun...@cox.net schrieb:
Back to the extents counts: What I did next was implementing a defrag
job that regularly defrags the journal (actually, the complete log
directory as other log files suffer the same problem):
$ cat /usr/local/sbin/defrag-logs.rb #!/bin/sh exec btrfs
Am Samstag, 14. Juni 2014, 02:53:20 schrieb Duncan:
I am reaching the conclusion that fallocate is not the problem. The
fallocate increase the filesize of about 8MB, which is enough for some
logging. So it is not called very often.
But...
If a file isn't (properly[1]) set NOCOW (and
On Sun, Jun 15, 2014 at 11:31:07PM +0200, Martin Steigerwald wrote:
Am Samstag, 14. Juni 2014, 02:53:20 schrieb Duncan:
I am reaching the conclusion that fallocate is not the problem. The
fallocate increase the filesize of about 8MB, which is enough for some
logging. So it is not called
Am Samstag, 14. Juni 2014, 12:59:31 schrieb Kai Krakow:
Well, how did I accomblish that?
Setting no cow and defragmenting regularily?
Quite a complex setup for a casual Linux user.
Any solution should be automatic. I´d suggest by a combination of sane
application behaviour and measures within
On Sun, Jun 15, 2014 at 11:45:37PM +0200, Martin Steigerwald wrote:
Am Samstag, 14. Juni 2014, 12:59:31 schrieb Kai Krakow:
Well, how did I accomblish that?
Setting no cow and defragmenting regularily?
Quite a complex setup for a casual Linux user.
Any solution should be automatic. I´d
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
On 06/14/2014 04:53 AM, Duncan wrote:
Goffredo Baroncelli posted on Sat, 14 Jun 2014 00:19:31 +0200 as
excerpted:
On 06/13/2014 01:24 AM, Dave Chinner wrote:
On Thu, Jun 12, 2014 at 12:37:13PM +, Duncan wrote:
FWIW, either 4 byte or 8 MiB fallocate calls would be bad, I think
actually
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 as: Systemd doesn't have problems because
it's perfect. Therefore, any
Kai Krakow posted on Sat, 14 Jun 2014 12:59:31 +0200 as excerpted:
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 as:
Goffredo Baroncelli posted on Sat, 14 Jun 2014 09:52:39 +0200 as
excerpted:
On 06/14/2014 04:53 AM, Duncan wrote:
Goffredo Baroncelli posted on Sat, 14 Jun 2014 00:19:31 +0200 as
excerpted:
thanks for pointing that. However I am performing my tests on a fedora
20 with systemd-208, which
Hi Dave
On 06/13/2014 01:24 AM, Dave Chinner wrote:
On Thu, Jun 12, 2014 at 12:37:13PM +, Duncan wrote:
Goffredo Baroncelli kreij...@libero.it posted on Thu, 12 Jun 2014
13:13:26 +0200 as excerpted:
systemd has a very stupid journal write pattern. It checks if there is
space in the file
Goffredo Baroncelli posted on Sat, 14 Jun 2014 00:19:31 +0200 as
excerpted:
On 06/13/2014 01:24 AM, Dave Chinner wrote:
On Thu, Jun 12, 2014 at 12:37:13PM +, Duncan wrote:
FWIW, either 4 byte or 8 MiB fallocate calls would be bad, I think
actually pretty much equally bad without NOCOW
Messaggio originale
Da: li...@colorremedies.com
Data: 12/06/2014 2.40
A: kreij...@inwind.it, Goffredo Baroncellikreij...@libero.it
Cc: systemd Mailing Listsystemd-de...@lists.freedesktop.org, linux-btrfs
linux-btrfs@vger.kernel.org
Ogg: Re: Slow startup of systemd-journal on BTRFS
Messaggio originale
Da: russ...@coker.com.au
Data: 12/06/2014 3.18
A: kreij...@inwind.it
Cc: systemd Mailing Listsystemd-de...@lists.freedesktop.org, linux-btrfs
linux-btrfs@vger.kernel.org
Ogg: Re: Slow startup of systemd-journal on BTRFS
On Wed, 11 Jun 2014 23:28:54 Goffredo
Da: da...@fromorbit.com
Data: 12/06/2014 3.21
A: kreij...@inwind.it
Cc: systemd Mailing Listsystemd-de...@lists.freedesktop.org, linux-btrfs
linux-btrfs@vger.kernel.org
Ogg: Re: Slow startup of systemd-journal on BTRFS
On Wed, Jun 11, 2014 at 11:28:54PM +0200, Goffredo Baroncelli wrote:
Hi all
Goffredo Baroncelli kreij...@libero.it posted on Thu, 12 Jun 2014
13:13:26 +0200 as excerpted:
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!)
Hi all,
I would like to share a my experience about a slowness of systemd when used on
BTRFS.
My boot time was very high (about ~50 seconds); most of time it was due to
NetworkManager which took about 30-40 seconds to start (this data came from
systemd-analyze plot).
I make several attempts
On Jun 11, 2014, at 3:28 PM, Goffredo Baroncelli kreij...@libero.it wrote:
If someone is able to suggest me how FRAGMENT the log file, I can try to
collect more scientific data.
So long as you're not using compression, filefrag will show you fragments of
systemd-journald journals. I can
On Wed, 11 Jun 2014 23:28:54 Goffredo Baroncelli wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=1006386
suggested me that the problem could be due to a bad interaction between
systemd and btrfs. NetworkManager was innocent. It seems that
systemd-journal create a very hight
On Wed, Jun 11, 2014 at 11:28:54PM +0200, Goffredo Baroncelli wrote:
Hi all,
I would like to share a my experience about a slowness of systemd when used
on BTRFS.
My boot time was very high (about ~50 seconds); most of time it was due to
NetworkManager which took about 30-40 seconds to
On Thu, Jun 12, 2014 at 11:21:04AM +1000, Dave Chinner wrote:
On Wed, Jun 11, 2014 at 11:28:54PM +0200, Goffredo Baroncelli wrote:
Hi all,
I would like to share a my experience about a slowness of systemd when used
on BTRFS.
My boot time was very high (about ~50 seconds); most of
On Jun 11, 2014, at 7:21 PM, Dave Chinner da...@fromorbit.com wrote:
On Wed, Jun 11, 2014 at 11:28:54PM +0200, Goffredo Baroncelli wrote:
Hi all,
I would like to share a my experience about a slowness of systemd when used
on BTRFS.
My boot time was very high (about ~50 seconds); most of
Russell Coker posted on Thu, 12 Jun 2014 11:18:37 +1000 as excerpted:
On Wed, 11 Jun 2014 23:28:54 Goffredo Baroncelli wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=1006386
suggested me that the problem could be due to a bad interaction between
systemd and btrfs. NetworkManager
49 matches
Mail list logo
