On Wed, 18.06.14 07:51, Tollef Fog Heen (tfh...@err.no) wrote:
]] Lennart Poettering
(trimming Ccs)
I am invoking fallocate() in advance, because we write those files with
mmap() and that of course would normally triggered SIGBUS already on the
most boring of reasons, such as disk
Goffredo Baroncelli posted on Mon, 16 Jun 2014 20:47:49 +0200 as
excerpted:
The test #6 and #7 suggested that the fsync(2) amd posix_fallocate(3)
calls aren't the root cause of the problem. Even without these the
system.journal file still fragments.
[1]
Lennart Poettering posted on Mon, 16 Jun 2014 00:39:39 +0200 as excerpted:
Well, quite frankly I am not entirely sure why fallocate()
I was barking up the wrong tree with fallocate(). Sorry.
--
Duncan - List replies preferred. No HTML msgs.
Every nonfree program has a lord, a master --
and
Lennart Poettering posted on Mon, 16 Jun 2014 00:43:34 +0200 as excerpted:
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.
On 17/06/14 09:17, Duncan wrote:
[...]
But never-the-less I can see the viewpoint from both sides now, and do
try to maintain a reasonable neutrality. I guess I should have made that
more explicit in the original post, but as they say, hindsight is 20/20.
=:^\
Hey! All good for a giggle
Hi Kai,
I investigate a bit why readahead doesn't defrag the journal.
I put in CC also the mailing list for the record.
On 06/17/2014 03:33 AM, Kai Krakow wrote:
[...]
Instead, for me, the readahead collector catches access to my system
journal and thus defragments it. That's not the case for
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.
Goffredo Baroncelli kreij...@libero.it schrieb:
I investigate a bit why readahead doesn't defrag the journal.
I put in CC also the mailing list for the record.
On 06/17/2014 03:33 AM, Kai Krakow wrote:
[...]
Instead, for me, the readahead collector catches access to my system
journal and
Chris Murphy li...@colorremedies.com schrieb:
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
Filipe Brandenburger filbran...@google.com schrieb:
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
Lennart Poettering lenn...@poettering.net schrieb:
[...] Finally, if something is logged
at priorities EMERG, ALERT or CRIT we will sync immediately (which
actually should never happen in real-life, unless something is really
broken -- a simple way to check if anything like this got written
Kai Krakow posted on Tue, 17 Jun 2014 23:02:14 +0200 as excerpted:
I'm pretty sure it really
doesn't matter if your 500G image file is split across 1 extents -
as long as at least chunks of extents are kept together and rebuilt as
one extent.
It's worth noting that in btrfs terms, chunk
]] Lennart Poettering
(trimming Ccs)
I am invoking fallocate() in advance, because we write those files with
mmap() and that of course would normally triggered SIGBUS already on the
most boring of reasons, such as disk full/quota full or so. Hence,
before we do anything like that, we invoke
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, 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,
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 16/06/14 19:47, Goffredo Baroncelli wrote:
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
Andrey Borzenkov arvidj...@gmail.com schrieb:
journald's write pattern looks something like this: append something to
the end, make sure it is written, then update a few offsets stored at
the beginning of the file to point to the newly appended data. This is
of course not easy to handle for
On 06/14/2014 11:37 PM, Kai Krakow wrote:
Goffredo Baroncelli kreij...@libero.it schrieb:
On 06/14/2014 10:13 PM, Kai Krakow wrote:
Take care to enable all needed services to enable defrag... If your
services make use of journal file loading these files should also become
part of the
Goffredo Baroncelli kreij...@libero.it schrieb:
I have enabled all the services (collect, replay, done), but I was
unable to see any gain.
I don't think you can actually enable the done service because it is
static... But if it placed a symlink in /etc/systemd that is probably
wrong and
On 06/15/2014 12:50 PM, Kai Krakow wrote:
Goffredo Baroncelli kreij...@libero.it schrieb:
I have enabled all the services (collect, replay, done), but I was
unable to see any gain.
I don't think you can actually enable the done service because it is
static... But if it placed a symlink in
Goffredo Baroncelli kreij...@libero.it schrieb:
To get back to your performance problem: Did you try systemctl enable
bootchart and then (after a reboot) look at the png generated in
/run/log (at least in my system it is placed there, look at the configs
if in doubt). It can give some
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 Sun, Jun 15, 2014 at 11:40:42AM +0200, Goffredo Baroncelli wrote:
Unfortunately bootchart doesn't work on fedora, because
CONFIG_SCHEDSTATS is not enabled in the kernel.
It's being investigated, unfortunatly with no progress since April:
https://bugzilla.redhat.com/show_bug.cgi?id=1013225
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
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
On 06/14/2014 12:59 PM, Kai Krakow wrote:
[...]
I think that systemd is even one of the early supporters of btrfs because it
will defragment readahead files on boot from btrfs.
In know that systemd does readahead, but it is the first time that I heard that
it does defrag too. Could you
Goffredo Baroncelli kreij...@libero.it schrieb:
On 06/14/2014 12:59 PM, Kai Krakow wrote:
[...]
I think that systemd is even one of the early supporters of btrfs because
it will defragment readahead files on boot from btrfs.
In know that systemd does readahead, but it is the first time
Goffredo Baroncelli kreij...@libero.it schrieb:
First, I've set the journal directories nocow.
If you use nocow, you lost the btrfs ability to rebuild a RAID array
discarding the wrong sector. With the systemd journal checksum, you can
say that a data is wrong, but BTRFS with its checksum
On 06/14/2014 04:03 PM, Kai Krakow wrote:
Goffredo Baroncelli kreij...@libero.it schrieb:
On 06/14/2014 12:59 PM, Kai Krakow wrote:
[...]
I think that systemd is even one of the early supporters of btrfs because
it will defragment readahead files on boot from btrfs.
In know that systemd
Goffredo Baroncelli kreij...@libero.it schrieb:
I am looking at the source, and yes, it does. To be honest it seems to
defragment only on btrfs.
Oh that seems true... Then defragmenting and relocating is probably a todo
item. I'm sure I've read about it somewhere.
If it
does, the question
On 06/14/2014 10:13 PM, Kai Krakow wrote:
Goffredo Baroncelli kreij...@libero.it schrieb:
I am looking at the source, and yes, it does. To be honest it seems to
defragment only on btrfs.
Oh that seems true... Then defragmenting and relocating is probably a todo
item. I'm sure I've read
Goffredo Baroncelli kreij...@libero.it schrieb:
On 06/14/2014 10:13 PM, Kai Krakow wrote:
Take care to enable all needed services to enable defrag... If your
services make use of journal file loading these files should also become
part of the process. You can check with
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 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 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
44 matches
Mail list logo
