linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).