From: Shridhar Daithankar <ghodechhap@ghodechhap.net>
To: Duncan <1i5t5.duncan@cox.net>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: unclean shutdown and space cache rebuild
Date: Tue, 02 Jul 2013 21:19:07 +0530 [thread overview]
Message-ID: <14300696.s96c8th5lD@bheem> (raw)
In-Reply-To: <pan$57f3a$a89b75ab$e2d2d0f4$5964d331@cox.net>
On Tuesday, July 02, 2013 01:00:29 PM Duncan wrote:
> Just to be clear, your system, your call. I'd never /dream/ of
> interfering with that due to the implications for my own system (which is
> certainly highly customized even matched against a peer-group of other
> gentoo installs =:^). That said...
>
> I'm guessing what you experiences with the autodefrag mount option was
> because you were not in stable-state yet. The original btrfs filesystem
> setup and fill was very likely without the flag on[2], so there's quite a
> lot of existing fragmentation what would have to be worked thru before
> the filesystem gets defragged and you reach stable-state, at which I'd
> expect the autodefrag mount option to have little overhead.
Yes, I suspect as much. One of the data parition I have is over an year old
and never defragged, /home about 3 months old.
and I can see the defragmentation working when run by hand. The initial run on
/var(only directories, to defrag metadata) was 6 min. Now that I am running it
daily by hand, entire /var(including files, that includes 1.8G pacman cache,
few tiny postgresql databases and /var/tmp where kde generates tons of IO)
takes about 6-7 min.
Despite of my experience with autodefrag, I want to use it because thats the
best solution(kinda like autovacuum in postgresql) that keeps things clean,
all the time.
>
> Tho if what you're saying is correct[1] then it may be that the
> background defrag thread isn't (io-)niced as I would have expected it to
> be.
>
> But I'd still expect there to be some better performance steady state
> after a few mounts gets the basic filesystem defragged. Tho if the
> fileystem is heavily fragmented[2], in practice it may well be easier to
> backup the filesystem content, do a clean mkfs and mount with autodefrag
> and restore from backup, thus ensuring autodefrag is on while filling the
> filesystem in the first place, than to wait for autodefrag to reach a
> stable system state in normal operation over many mounts.
well, I think I will bite the bullet and defrag entire / overnight and repeat
the autodefrag mount option. That should work too.
Thanks
--
Regards
Shridhar
next prev parent reply other threads:[~2013-07-02 15:42 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
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 [this message]
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=14300696.s96c8th5lD@bheem \
--to=ghodechhap@ghodechhap.net \
--cc=1i5t5.duncan@cox.net \
--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).