Editing Logical volume management (section)

== Disadvantages ==
Logical volumes can suffer from [[Fragmentation (computer)#External fragmentation|external fragmentation]] when the underlying storage devices do not allocate their PEs contiguously.  This can reduce I/O performance on slow-seeking media such as magnetic disks and other rotational media. Volume managers that use fixed-size PEs, however, typically make PEs relatively large (for example, [[Logical Volume Manager (Linux)|Linux LVM]] uses 4&nbsp;MB by default) in order to [[Amortization (accounting)|amortize]] the cost of these seeks.

With implementations that are solely volume management, such as [[Core Storage]] and Linux LVM, separating and abstracting away volume management from the file system loses the ability to easily make storage decisions for particular files or directories. For example, if  a certain directory (but not the entire file system) is to be permanently moved to faster storage, both the file system layout and the underlying volume management layer need to be traversed. For example, on Linux it would be needed to manually determine the offset of a file's contents within a file system and then manually {{dfn|<code>pvmove</code>|Moves the allocated physical extents (PEs) on a source PV to one or more destination PVs}} the extents (along with data not related to that file) to the faster storage. Having volume and file management implemented within the same subsystem, instead of having them implemented as separate subsystems, makes the overall process theoretically simpler.