Joined: Thu Jul 03, 2008 4:27 am Posts: 1579 Location: Switzerland
|
|
It seems no experts are forthcoming.
I can only give you my experience and logic. I haven't had any major issues with LVM performance but it's obviously not magic and I have never had to configure commits to the physical disk all the time (on data safety grounds) so RAM has been helping a lot.
If you're talking about a scenario like: -you have drive A (500G) and B (250G) -you run services Y and Z which require 300 G and 150G respectively. -you're currently using A for Y andB for Z -you're looking to move to LVM (in the common, simple striping mode) and expect it to "just work" without any figuring and fiddling Then you're going to have more concurrency issues because Y and Z are likely going to end up running both from A whereas before Y and Z each had their own mechanical arm in a different drive. Whether these new concurrency issues would add up to a material decrease in performance depends of course on the exact load the services put on the drive. I don't know that any software is much more clever when it comes to allocating volumes to physical drives. But maybe some expose an interface which makes it easier for you to fiddle with allocation in order to optimize performance.
If on the other ahnd you're talking about a scenario like: -you have drive A (500G) and B (250G) -you have your OS, apps and so on on A and files you rarely use on B -you're looking to move to LVM blah blah blah (see above) but this time with a single volume Then the effect on performance will not be straightforward but on the whole I'd expect less concurrency issues and better performance. It will probably depend in no small part on the order in which files are copied to the new large volume.
|
|