From: David Brown <david.brown@hesbynett.no>
To: linux-raid@vger.kernel.org
Subject: Re: mdadm does not create partition devices whatsoever, "partitionable" functionality broken
Date: Sat, 14 May 2011 12:10:56 +0200 [thread overview]
Message-ID: <iqlkfg$1s9$1@dough.gmane.org> (raw)
In-Reply-To: <20110514013221.552dc8ef@natsu>
On 13/05/11 21:32, Roman Mamedov wrote:
> On Fri, 13 May 2011 15:22:09 -0400
> Phil Turmel<philip@turmel.org> wrote:
>
>> I always use LVM. While the lack of attention to MD partitions might
>> justify that, the real reason is the sheer convenience of creating,
>> manipulating, and deleting logical volumes on the fly. While you may not
>> need it *now*, when you discover that you *do* need it, you won't be able to
>> use it. Online resizing of any of your LVs is the killer feature.
>
> Can it defragment non-contiguous LVs yet?
>
What is perhaps more relevant, is can filesystems see the fragmentation
of the LV's? I don't know the answer.
Fragmentation of files is not a problem unless files are split into
/lots/ of small pieces. The bad reputation of fragmentation has come
from the DOS/Windows world, where poor filesystems combined with
shotgun-style allocators give you much slower performance than necessary.
Modern Linux filesystems have various techniques to keep fragmentation
to a minimum. But (AFAIK) they make the assumption that the underlying
device is contiguous. If the filesystem /knows/ that the device is in
bits, then it could take that into account in its allocation policy (in
the same way that it takes raid stripes into account).
Still, you don't usually have many segments in an LV - if you want the
LV to be fast, you can request it to be contiguous when creating it.
Then you only get a fragment for each time it is grown. It's a price
often worth paying for the flexibility.
next prev parent reply other threads:[~2011-05-14 10:10 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-13 15:13 mdadm does not create partition devices whatsoever, "partitionable" functionality broken Christopher White
2011-05-13 16:49 ` Phil Turmel
2011-05-13 17:18 ` Christopher White
2011-05-13 17:32 ` Christopher White
2011-05-13 17:40 ` Roman Mamedov
2011-05-13 18:04 ` Christopher White
2011-05-13 18:18 ` Phil Turmel
2011-05-13 18:54 ` Christopher White
2011-05-13 19:01 ` Rudy Zijlstra
2011-05-13 19:49 ` Christopher White
2011-05-13 20:00 ` Rudy Zijlstra
2011-05-13 19:49 ` Christopher White
2011-05-13 19:22 ` Phil Turmel
2011-05-13 19:32 ` Roman Mamedov
2011-05-13 19:39 ` Phil Turmel
2011-05-14 10:10 ` David Brown [this message]
2011-05-14 10:24 ` Roman Mamedov
2011-05-14 12:56 ` David Brown
2011-05-14 13:27 ` Drew
2011-05-14 18:21 ` David Brown
2011-05-13 17:43 ` Phil Turmel
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='iqlkfg$1s9$1@dough.gmane.org' \
--to=david.brown@hesbynett.no \
--cc=linux-raid@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).