All of lore.kernel.org
 help / color / mirror / Atom feed
From: George Mitchell <george@chinilu.com>
To: Shridhar Daithankar <ghodechhap@ghodechhap.net>
Cc: Duncan <1i5t5.duncan@cox.net>, linux-btrfs@vger.kernel.org
Subject: Re: autodefrag by default, was: Lots of harddrive chatter
Date: Sun, 21 Jul 2013 20:53:42 -0700	[thread overview]
Message-ID: <51ECACC6.1090104@chinilu.com> (raw)
In-Reply-To: <5436903.bmHYcuMpfJ@bheem>

On 07/21/2013 08:37 PM, Shridhar Daithankar wrote:
> On Sunday, July 21, 2013 04:44:09 PM George Mitchell wrote:
>> Unless auto-defrag can work around the
>> in-use file issue, that could be a problem since some heavily used
>> system files are open virtually all the time the system is up and
>> running.  Has this issue been investigated and if so are there any
>> system files that don't get defragmented that matter?  Or is this a
>> non-issue in that any constantly in use system files don't really matter
>> anyway?  That is really the only question I have before moving away from
>> my current offline approach to the auto-defrag mount option for system
>> filesystems (/, /boot, /usr, /opt, /var, etc).
> AFAIK, defragmentation is proportional to amount of writes to a file or
> direcotries.
>
> system files typically are installed once and never rewritten in place, so
> they should not be much fragmented to begin with.
>
> now their directory objects, is a different story and so is things like
> systemd journal, log files, or database files.
Never rewritten in place?  I wouldn't go that far.  In the case of many 
distros there is a continual flow of updates which results in some 
degree of data churning throughout the system filesystems. Just a kernel 
update, for example, can affect a rather large number of files and 
directories with new writes while application updates (KDE or even Gnome 
for example) can cause a large number of files to be rewritten in place.

  reply	other threads:[~2013-07-22  3:53 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-20 15:15 Lots of harddrive chatter on after booting with btrfs on root (slow boot) Jason Russell
2013-07-20 15:52 ` George Mitchell
2013-07-20 22:14 ` Lukas Martini
2013-07-20 22:47 ` Gabriel de Perthuis
2013-07-21 10:38   ` Duncan
2013-07-21 16:20     ` autodefrag by default, was: Lots of harddrive chatter Chris Murphy
     [not found]   ` < pan$3c802$83940fc4$86279b1e$4ddf0e4e@cox.net>
     [not found]     ` < 09A15D35-4874-4650-93F1-1E151076C498@colorremedies.com>
2013-07-21 22:01       ` Duncan
2013-07-21 23:44         ` George Mitchell
2013-07-22  3:37           ` Shridhar Daithankar
2013-07-22  3:53             ` George Mitchell [this message]
2013-07-22  4:11               ` Shridhar Daithankar
     [not found]   ` < pan$7e18b$b2c36a61$b1f22c8c$6c61ba6e@cox.net>
     [not found]     ` <51EC7249.3010005@chinilu.com >
2013-07-22 12:09       ` Duncan

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=51ECACC6.1090104@chinilu.com \
    --to=george@chinilu.com \
    --cc=1i5t5.duncan@cox.net \
    --cc=ghodechhap@ghodechhap.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.