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

[Bill Watson]

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!!! 

If not, then after a year, to read a file the disks will have to land on 365
different locations. Maybe I'm too old school, but how exactly would a disk
file defragmenter (or equiv) be of no use here? How would a smart
(informed?) LVM programmer handle this better?

If all you are saying is that with LVM's, the disk *appears* to be
contiguous, why is that important? We pay so doggone much money for speed,
why fool the system into thinking it is organized well?

Bill Watson
bill at magicdigits.com

-----Original Message-----
From: rhelv6-beta-list-bounces at redhat.com
[mailto:rhelv6-beta-list-bounces at redhat.com] On Behalf Of Bryan J Smith

PEs are never fragmented, wholly unlike filesystems.
PEs are always contiguous, possibly not physically linear,
but they are always contiguous.
This is yet another meta-argument that is non-real-world.

Now if someone doesn't know what they are doing with LVM,
and starts doing things that are laughable, then yes, we consulants
coming in and having to move around PEs to correct the issues
can be a PITA.  E.g., adding a PV to a VG that is striped and
allocated into LVs, and then extending into the non-striped PV.

LVM is cake to use in replace of legacy, hardware-specific disk
labels and offers numerous advantages.  But the more performance
features one takes advantage in with LVM, the more one has to
ensure they allocate correctly for optimal performance.
But even if they don't, in the overwhelming majority of cases
the "worst case scenario" is "as slow as legacy disk labels."

Any more fringe, hypothetical scenarios based on (incorrect)
assumptions?  (did I respond to another meta-discussion comment)?


--  
Bryan J Smith - mailto:b.j.smith at ieee.org  
http://www.linkedin.com/in/bjsmith
Sent via BlackBerry from T-Mobile