F18 partitioning LVM Question....

[Chris Murphy]

On Dec 30, 2012, at 7:36 AM, Richard Ryniker <ryniker at alum.mit.edu> wrote:

> It has to be technically possible, but I have not heard about any utility
> to defragment a logical volume... to modify the mapping of logical
> extents to physical extents (simultaneously, for all the logical volumes
> in a volume group) in order to optimize physical contiguity of logical
> data.  This is a very scary thing, because optimum results would require 
> understanding and possible adjustment of individual files' allocations
> within the file systems in logical volumes.

Apple is now sorta doing what you describe with their LVM equivalent, called Core Storage. The tools are seriously weak compared to LVM, but a distinct advantage of Apple's implementation is if you put an SSD and HDD into a volume group, then create an LV, the actual physical allocation is not first come first served (at LV create time) like LVM2. It is based on hot and cold files. Hot files are migrated automatically to the SSD, and cold files to the HDD. I do not know if this is file based migration or extent based migration.


> Conclusion:  this is an interesting topic for discussion, but so many
> factors may affect actual results that only careful instrumentation and
> measurement of a specific application is likely to show what factors are
> significant for that case.

While I agree there may not be any meaningful latency as a result of weird partitioning arrangements, at a minimum one can say there's no efficacy in doing so. Instead of organizing by VG and LV on a single disk it makes more sense to come up with a better LV naming scheme, in order to use a single VG, and allocate the LV's in order of speed and proximal usage to each other.

Medium term, once matured, Btrfs's subvols are a better way of doing this than LVs.


Chris Murphy