[rhelv6-beta-list] Volume management with btrfs (and LVM) --WAS: My first experiences with RHEL6 beta

[Bill Watson]

Consider me set straight.

 

Yes, hopefully interleaving many segments of 2 LVM's on one physical drive
is nonsensical, unless such fragmentation is a good thing for your situation
(seen one real world example of this in last 34 years).

 

How, or does, the concept of LVM interrelate with btrfs, given btrfs can
handle redundancy - and therefore multiple physical disks?

 

Thanks,

Bill Watson

bill at magicdigits.com

 

From: rhelv6-beta-list-bounces at redhat.com
[mailto:rhelv6-beta-list-bounces at redhat.com] On Behalf Of John Haxby
Sent: Wednesday, June 16, 2010 11:37 AM
To: Red Hat Enterprise Linux 6 (Santiago) Beta releases discussion
mailing-list
Subject: Re: [rhelv6-beta-list] Volume management with btrfs (and LVM)
--WAS: My first experiences with RHEL6 beta

 

 

On 16 June 2010 18:26, Bill Watson <bill at magicdigits.com> wrote:

So, with LVM's if I create 1,000 1 meg files, then add 1 meg to each of
those files once a day, the files will be physically automagically
contiguous? That is soooo coool!!!

 

Create files in what?  LVM deals with extents in volumes, you don't create a
file in a logical volume.

 

What you could do is create 1000 logical volumes and put data in each of
those 1000 logical volumes, but that doesn't make sense.  The smallest
possible size of a logical volume is a physical extent, the size of a
physical extent depends on the size of the physical volume, but on my 180GB
disk the physical extent is 4MB; I seem to recall on a rather larger disk on
another system its 32MB.

 

So you could put 1MB data in each of those 1000 minimum size logical
volumes, and add another 1MB data at the end until you've filled up the
logical volume.  At that stage you can add another physical extent to the
logical volume and put data in that.   If you're starting with nice big
physical volumes then you've got, say, 64MB in two physical extents.  That's
two 32MB physically contiguous areas of disk (subject to the drive not
remapping bad sectors under you).

 

The whole point about logical volumes is that they are mostly physically
contiguous on the disk (subject to remapping, striping, etc),   You have a
lot of choice about the physical layout.  "lvdisplay -m" will show you the
physical extents used by the logical volume.  Whether data is linearly
arranged through those or striped across multiple physical volumes or
mirrored or whatever is a property of the physical volume.

 

Now, if you shrink, grow, allocate, delete and generally mess with logical
volumes enough then you _can_, given sufficient determination, fragment your
logical volumes so that they're spread through the physical volumes.   It
takes some doing, it's possible, and I"m sure some people have managed it.

 

Whether that fragmentation matters depends on your disks.   If you're
allocating logical volumes on a SAN which has a few hundred disk drives it
won't make any difference at all.   If you've managed to fragment a logical
volume on a single physical volume (and it's not especially easy) then it
will make a small difference and this (and only this) is where you would
want to consider defragmenting your logical volumes.  You can do it on-line
and it a few commands if you have a second disk handy (it's merely tricky
otherwise).

 

No, on the other hand, if you have ext3 file system and you abuse it by
running it almost full almost all the time then you'll get fragmentation
problems and you'll see a marked drop in performance.  Especially when
you're doing a backup (I speak from experience here).   That, of course, is
nothing to do with whether the file system is on a bare disk, a logical
volume or carried by a flock of carrier pigeons.

 

btrfs unifies the physical volumes with the file system to provide striping,
redundancy, snapshots  and all that good stuff at -- and this is important
-- an object level, not a volumelevel.  Because it's dealing with files
which are dynamic and often titchy and because btrfs is an extent-based file
system (with variable size extents) then fragmentation is a fact of life and
you can't get away from it.  Which is why btrfs has on-line defragmentation.

 

Now can we get back to some sanity without all the misinformation and
confusion about logical volumes and file systems?

 

Please.

 

Pretty please.

 

jch

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/rhelv6-beta-list/attachments/20100616/ae040f04/attachment.htm>