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
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
