From: Drew <drew.kay@gmail.com>
To: linux-raid@vger.kernel.org
Subject: Re: mdadm does not create partition devices whatsoever, "partitionable" functionality broken
Date: Sat, 14 May 2011 06:27:14 -0700 [thread overview]
Message-ID: <BANLkTin0qRZXYzWBTXUJqdHmaQR_p1VfUA@mail.gmail.com> (raw)
In-Reply-To: <iqlu6n$duh$1@dough.gmane.org>
> I'm sure that LV's could be defragmented - there is already code to move
> them around on the disks (such as to move them out of a PV before deleting
> the PV). I don't know why it hasn't been implemented - maybe there are too
> few people working on LVM, or that it is a low priority, or that LV
> fragmentation makes very little measurable difference in practice.
I've always figured it was because fragmentation in the LV's caused
little performance degradation. If we were talking about LV's composed
of hundreds of fragments I would expect to see degradation but I've
never come across a scenario where LV's have been that bad.
Someone refered to DOS in an earlier post and I think that's a good
example of relevance. I maintain a bunch of Windows based machines at
work and I did some performance benchmarking between a traditional
defrag utility and some of the "professional" versions. Bells and
whistles aside, what set most of the Pro versions apart from the
standard defrag utilities was the concept of "good enough" defrag,
which basically puts files into several larger fragments as opposed to
a complete defrag. I ran tests on filesystem performance before and
after defraging drives with both options and the change in performance
between a full defrag and a "good enough" defrag was minimal.
--
Drew
"Nothing in life is to be feared. It is only to be understood."
--Marie Curie
"This started out as a hobby and spun horribly out of control."
-Unknown
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" 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:[~2011-05-14 13:27 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
2011-05-14 10:24 ` Roman Mamedov
2011-05-14 12:56 ` David Brown
2011-05-14 13:27 ` Drew [this message]
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=BANLkTin0qRZXYzWBTXUJqdHmaQR_p1VfUA@mail.gmail.com \
--to=drew.kay@gmail.com \
--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).