<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=Content-Type content="text/html; charset=us-ascii"> <meta name=Generator content="Microsoft Word 12 (filtered medium)"> <style>  </style>  </head> <body lang=EN-US link=blue vlink=purple> <div class=WordSection1> <p class=MsoNormal><span style='font-size:14.0pt;font-family:"Tahoma","sans-serif"; color:blue'>Consider me set straight.<o:p></o:p></span></p> <p class=MsoNormal><span style='font-size:14.0pt;font-family:"Tahoma","sans-serif"; color:blue'><o:p> </o:p></span></p> <p class=MsoNormal><span style='font-size:14.0pt;font-family:"Tahoma","sans-serif"; color:blue'>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).<o:p></o:p></span></p> <p class=MsoNormal><span style='font-size:14.0pt;font-family:"Tahoma","sans-serif"; color:blue'><o:p> </o:p></span></p> <p class=MsoNormal><span style='font-size:14.0pt;font-family:"Tahoma","sans-serif"; color:blue'>How, or does, the concept of LVM interrelate with btrfs, given btrfs can handle redundancy - and therefore multiple physical disks?<o:p></o:p></span></p> <p class=MsoNormal><span style='font-size:14.0pt;font-family:"Tahoma","sans-serif"; color:blue'><o:p> </o:p></span></p> <p class=MsoNormal><span style='font-size:14.0pt;font-family:"Tahoma","sans-serif"; color:blue'>Thanks,<o:p></o:p></span></p> <p class=MsoNormal><span style='font-size:14.0pt;font-family:"Tahoma","sans-serif"; color:blue'>Bill Watson<o:p></o:p></span></p> <p class=MsoNormal><span style='font-size:14.0pt;font-family:"Tahoma","sans-serif"; color:blue'>bill@magicdigits.com<o:p></o:p></span></p> <p class=MsoNormal><span style='font-size:14.0pt;font-family:"Tahoma","sans-serif"; color:blue'><o:p> </o:p></span></p> <div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'> <p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> rhelv6-beta-list-bounces@redhat.com [mailto:rhelv6-beta-list-bounces@redhat.com] <b>On Behalf Of </b>John Haxby<br> <b>Sent:</b> Wednesday, June 16, 2010 11:37 AM<br> <b>To:</b> Red Hat Enterprise Linux 6 (Santiago) Beta releases discussion mailing-list<br> <b>Subject:</b> Re: [rhelv6-beta-list] Volume management with btrfs (and LVM) --WAS: My first experiences with RHEL6 beta<o:p></o:p></span></p> </div> <p class=MsoNormal><o:p> </o:p></p> <p class=MsoNormal><o:p> </o:p></p> <div> <p class=MsoNormal>On 16 June 2010 18:26, Bill Watson <<a href="mailto:bill@magicdigits.com">bill@magicdigits.com</a>> wrote:<o:p></o:p></p> <p class=MsoNormal style='margin-bottom:12.0pt'>So, with LVM's if I create 1,000 1 meg files, then add 1 meg to each of<br> those files once a day, the files will be physically automagically<br> contiguous? That is soooo coool!!!<o:p></o:p></p> <div> <p class=MsoNormal><o:p> </o:p></p> </div> <div> <p class=MsoNormal>Create files in what? LVM deals with extents in volumes, you don't create a file in a logical volume.<o:p></o:p></p> </div> <div> <p class=MsoNormal><o:p> </o:p></p> </div> <div> <p class=MsoNormal>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.<o:p></o:p></p> </div> <div> <p class=MsoNormal><o:p> </o:p></p> </div> <div> <p class=MsoNormal>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).<o:p></o:p></p> </div> <div> <p class=MsoNormal><o:p> </o:p></p> </div> <div> <p class=MsoNormal>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.<o:p></o:p></p> </div> <div> <p class=MsoNormal><o:p> </o:p></p> </div> <div> <p class=MsoNormal>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.<o:p></o:p></p> </div> <div> <p class=MsoNormal><o:p> </o:p></p> </div> <div> <p class=MsoNormal>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).<o:p></o:p></p> </div> <div> <p class=MsoNormal><o:p> </o:p></p> </div> <div> <p class=MsoNormal>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.<o:p></o:p></p> </div> <div> <p class=MsoNormal><o:p> </o:p></p> </div> <div> <p class=MsoNormal>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.<o:p></o:p></p> </div> <div> <p class=MsoNormal><o:p> </o:p></p> </div> <div> <p class=MsoNormal>Now can we get back to some sanity without all the misinformation and confusion about logical volumes and file systems?<o:p></o:p></p> </div> <div> <p class=MsoNormal><o:p> </o:p></p> </div> <div> <p class=MsoNormal>Please.<o:p></o:p></p> </div> <div> <p class=MsoNormal><o:p> </o:p></p> </div> <div> <p class=MsoNormal>Pretty please.<o:p></o:p></p> </div> <div> <p class=MsoNormal><o:p> </o:p></p> </div> <div> <p class=MsoNormal>jch<o:p></o:p></p> </div> <div> <p class=MsoNormal> <o:p></o:p></p> </div> </div> </div> </body> </html>