From: "Alexander E. Patrakov" <patrakov@gmail.com>
To: Diego Calleja <diegocg@gmail.com>
Cc: "Kok, Auke-jan H" <auke-jan.h.kok@intel.com>,
Peeters Simon <peeters.simon@gmail.com>,
systemd-devel@lists.freedesktop.org, linux-btrfs@vger.kernel.org
Subject: Re: [systemd-devel] systemd-udevd: excessive I/O usage
Date: Tue, 5 Jun 2012 20:59:27 +0600 [thread overview]
Message-ID: <CAN_LGv1G7AoAEUcEVhrw3OreSNwRsdBJrM6455C=LS2SpEXDEA@mail.gmail.com> (raw)
In-Reply-To: <1791638.Q7YQnvvX5y@fedora16>
2012/6/5 Diego Calleja <diegocg@gmail.com>:
> [resend, for some reason kmail formatted the previous message with html]
>
> On Martes, 5 de junio de 2012 09:50:56 Alexander E. Patrakov escribió:
>> Result: boot from ext4 takes less than 15 seconds, while boot from
>> btrfs takes 9 minutes (or 5 minutes if I disable readahead - the data
>> file is not valid anyway on btrfs).
>
> I also had this problem. It turns out that btrfs was creating the
> space cache from scratch (which takes several minutes) on each boot,
> for some reason. I added the space_cache mount option to fstab,
> and now my system boots fast. I suggest trying it.
It helped me, too - but ext4 is still faster under the typical
"startup under systemd" load type. The difference manifests itself as
GDM login screen sometimes timing out some components of its fancy
version (due to something resembling kernel bug 12309) and falling
back to the simple non-gnome-shell version.
Sorry for hijacking the thread, but the amount of parallelization
achieved by systemd is way too much for a rotating drive from 2007,
especially since some system components like gdm have aggressive
timeouts easily triggered by disk i/o.
--
Alexander E. Patrakov
next prev parent reply other threads:[~2012-06-05 14:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAKyAS7vw6pPz56Y9DeyUQLVeuXq4G2WogEWm+5gANesC0ME35g@mail.gmail.com>
[not found] ` <CABsxX9+uRN0rCY-Qo5gpRirvv6orWKdsVEKD=duuCGUj+xndXg@mail.gmail.com>
[not found] ` <CAKyAS7uKKz_MsPeiLa7QorkjPqm16K0RmCy3eDcuTTxOkvBYuw@mail.gmail.com>
[not found] ` <CABsxX9LQkytRk6xZfEkw7QM24ghiM75WY0wVwiAouh+WWPBT=Q@mail.gmail.com>
[not found] ` <CAKyAS7stmJrYMHWf_eWX1htLOZRu3M7gmGMJ9ZMSzne+81yBpA@mail.gmail.com>
[not found] ` <CAKyAS7sdL9qWLOCyj7y5HeJda=WhsWsQu_Pke22AOspT-ES1Tg@mail.gmail.com>
[not found] ` <CABsxX9+Msqdjp_y1xWRQe=QJ9ALPBqx7H62ZosfN9QZc0f1hRg@mail.gmail.com>
[not found] ` <CAKyAS7sy-923hm-uo1_SiP3XC4tbmqOaR_NgZk4S1rmJ+x8LBQ@mail.gmail.com>
[not found] ` <CABsxX9JBsOX7sFYvmSjdq5N8pXPDrSv3V4DaRszKdpnBK_KxEA@mail.gmail.com>
2012-06-05 3:50 ` [systemd-devel] systemd-udevd: excessive I/O usage Alexander E. Patrakov
2012-06-05 13:49 ` Diego Calleja
2012-06-05 14:59 ` Alexander E. Patrakov [this message]
2012-06-05 17:19 ` Kok, Auke-jan H
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAN_LGv1G7AoAEUcEVhrw3OreSNwRsdBJrM6455C=LS2SpEXDEA@mail.gmail.com' \
--to=patrakov@gmail.com \
--cc=auke-jan.h.kok@intel.com \
--cc=diegocg@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=peeters.simon@gmail.com \
--cc=systemd-devel@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).