Hi,
I have some 500GB/250GB HDDs. I want to use them to build a LVM so it is easier for browsing and managing data. Question is, will the HDD performance degrade by concurrent read/write operations since OS only sees a single volume? Appreciate for expert advice.
Does LVM suffer from concurrent access?
Moderators: NeilBlanchard, Ralf Hutter, sthayashi, Lawrence Lee
Re: Does LVM suffer from concurrent access?
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.
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.