From: Eric Sandeen <sandeen@redhat.com>
To: Roger Binns <rogerb@rogerbinns.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs: document mount options in Documentation/fs/btrfs.txt
Date: Sat, 23 Mar 2013 17:40:41 -0500 [thread overview]
Message-ID: <514E2F69.1030204@redhat.com> (raw)
In-Reply-To: <kil9uq$210$1@ger.gmane.org>
On 3/23/13 5:22 PM, Roger Binns wrote:
> On 23/03/13 10:48, Eric Sandeen wrote:
>> Btrfs is a new copy on write filesystem for Linux aimed at
>
> How much longer does "new" get to be there as the filesystem has been
> going for well over half a decade.
;) well, I didn't write that. Could remove it on the next round I suppose.
>> + autodefrag + Detect small random writes into files and queue them up
>> for the + defrag process. Works best for small files; Not well suited
>> for + large database workloads.
>
> What is "large"? One man's large database is another's trivial database!
> Same applies to "small". Virtual machines are also in the category of
> large files with small random writes.
>
> Quantification would help a lot. Suggestions are "more than 10 random
> writes an hour to files larger than a gigabyte".
Fair enough. I was going by the original commitlog for that option:
> Btrfs: add mount -o auto_defrag
>
> This will detect small random writes into files and
> queue the up for an auto defrag process. It isn't well suited to
> database workloads yet, but works for smaller files such as rpm, sqlite
> or bdb databases.
I imagine it depends on the details of the workload & storage as well.
Quantifying it may be tough; it may be better to just add more description
of what happens when it autodefrags, with some indication of how file size
affects the process, and leave it up to the admin to determine whether
it's appropriate for a given environment.
Before I can do that I'll have to understand better how it works ;)
Thanks,
-Eric
> Roger
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2013-03-23 22:40 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-23 17:48 [PATCH] btrfs: document mount options in Documentation/fs/btrfs.txt Eric Sandeen
2013-03-23 18:33 ` Roman Mamedov
2013-03-23 18:45 ` Eric Sandeen
2013-03-26 13:23 ` Karel Zak
2013-03-23 20:35 ` Ilya Dryomov
2013-03-23 22:22 ` Roger Binns
2013-03-23 22:40 ` Eric Sandeen [this message]
2013-03-24 1:11 ` Roger Binns
2013-03-25 15:57 ` David Sterba
2013-03-25 13:59 ` Josef Bacik
2013-03-26 19:36 ` [PATCH V2] " Eric Sandeen
2013-03-29 16:48 ` David Sterba
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=514E2F69.1030204@redhat.com \
--to=sandeen@redhat.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=rogerb@rogerbinns.com \
/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