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, suc
]] 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 inv
Duncan <1i5t5.dun...@cox.net> schrieb:
> 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 ex
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, "c
Lennart Poettering 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 is
> "journalctl -p
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 loo
Filipe Brandenburger schrieb:
> On Mon, Jun 16, 2014 at 6:13 PM, cwillu 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
>>
Chris Murphy 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 approach, again ass
Goffredo Baroncelli 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 thus def
On Jun 16, 2014, at 7:13 PM, cwillu 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.
> Another app
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
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 gi
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'
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 --
an
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] http://kreijack.blogspot.it/2014/
Andrey Borzenkov 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 COW file syst
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. Be
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 beha
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 2.5GH
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 allocati
On Mon, Jun 16, 2014 at 2:14 PM, 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
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
On Jun 15, 2014, at 4:34 PM, Lennart Poettering 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 amount of space
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 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
> > (controversial
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 t
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
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
Goffredo Baroncelli 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 interest
On 06/15/2014 12:50 PM, Kai Krakow wrote:
> Goffredo Baroncelli 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 i
Goffredo Baroncelli 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 you s
On 06/14/2014 11:37 PM, Kai Krakow wrote:
> Goffredo Baroncelli 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
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-2
Goffredo Baroncelli 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
>> "/usr/lib/systemd/systemd-reada
On 06/14/2014 10:13 PM, Kai Krakow wrote:
> Goffredo Baroncelli 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 so
Goffredo Baroncelli 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 is: where to
On 06/14/2014 04:03 PM, Kai Krakow wrote:
> Goffredo Baroncelli 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 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 (when used in
Goffredo Baroncelli 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 that I hea
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 e
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. Therefor
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
On Jun 11, 2014, at 7:21 PM, 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 time i
On Jun 11, 2014, at 3:28 PM, Goffredo Baroncelli 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 vouch for the beha
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
45 matches
Mail list logo
