linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Garry T. Williams" <gtwilliams@gmail.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: unclean shutdown and space cache rebuild
Date: Sun, 30 Jun 2013 13:53:48 -0400	[thread overview]
Message-ID: <4774295.3Q3X7zsTmb@vfr> (raw)
In-Reply-To: <11441914.sRzrmH57Vq@bheem>

On 6-30-13 19:26:16 Shridhar Daithankar wrote:
> Whenever there is a unclean shutdown(which happens a lot in my
> case), the next reboot, system comes up relatively at the same speed
> but as systemd is starting up daemons, the disk is continuously (and
> unusally long) grinding.

[snip]

> How can I confirm that it is the space cache rebuild thats taking
> time?
> 
> if space cache rebuild is the reason, is there any way to improve
> it?
> 
> I am running archlinux/systemd/kde

I suspect this is, at least in part, related to severe fragmentation
in /home.

There are large files in these directories that are updated frequently
by various components of KDE and the Chrome browser.  (Firefox has its
own databases that are frequently updated, too.)

    ~/.local/share/akonadi
    ~/.kde/share/apps/nepomuk/repository/main/data/virtuosobackend
    ~/.cache/chromium/Default/Cache
    ~/.cache/chromium/Default/Media\ Cache

I improved performance dramatically (orders of magnitude) by copying
the database files into an empty file that was modified with:

    chattr -C

and renaming to make the files no COW.  (Note that this is the only
way to change an existing file to no COW.)  I also set the same
attribute on the owning directories so that all new files inherit the
no COW attribute.

I suspect there are other files that fragment badly since I see
periods of high disk activity coming back slowly over a few weeks of
use after making the modifications above.  I intend to track them down
and do the same.

Also, see these:

    https://btrfs.wiki.kernel.org/index.php/Problem_FAQ#Defragmenting_a_directory_doesn.27t_work 
    https://btrfs.wiki.kernel.org/index.php/UseCases#How_do_I_defragment_many_files.3F 

    $ uname -r
    3.9.6-200.fc18.x86_64
    $

-- 
Garry T. Williams


  reply	other threads:[~2013-06-30 17:53 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-30 13:56 unclean shutdown and space cache rebuild Shridhar Daithankar
2013-06-30 17:53 ` Garry T. Williams [this message]
2013-06-30 19:58   ` Pete
2013-06-30 20:10   ` Clemens Eisserer
2013-06-30 21:20   ` Duncan
2013-06-30 23:12   ` Roger Binns
2013-07-01  2:50   ` Shridhar Daithankar
2013-07-01  9:10     ` Duncan
2013-07-01 16:19       ` Shridhar Daithankar
2013-07-02 13:00         ` Duncan
2013-07-02 15:49           ` Shridhar Daithankar
2013-07-05  3:45             ` Shridhar Daithankar

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=4774295.3Q3X7zsTmb@vfr \
    --to=gtwilliams@gmail.com \
    --cc=linux-btrfs@vger.kernel.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).