When I saw some ugly I/O errors on one of the drives in my LVM volume, I immediately looked into how to move whatever data I could off of that drive and onto another free drive. Luckily, I happened have a few free drives.
After some quick reading online, and the lovely tab-completion available in bash, I found the pvmove command, and decided to put it to use. After not receiving any output for several hours, I decided that the process had hung and killed it. When running pvmove --abort, I got a few instances of the following error.
reload ioctl failed: Invalid argument
So I hit the books internet again, and happened upon a similar bug report on Debian’s bug tracker where it was suggested that perhaps the version of the kernel drivers for lvm2 and the versions of the userspace utilities/libraries were out of sync. Since I’m running almost the latest kernel (2.6.17; 2.6.18 was just released), I decided to upgrade to the latest released lvm2 utilities and libraries. Once this was done, everything worked like a charm!
| Software | Old (Broken) Configuration | New (Working) Configuration |
|---|---|---|
| Kernel | 2.6.17-gentoo-r8 | |
| Userspace Library (libdevicemapper) | 1.02.07 | 1.02.10 |
| lvm2 | 2.02.06 | 2.02.10 |
Oddly enough, the old configuration reflects the latest available packages as keyworded stable for amd64. The new configuration reflects the latest packages as keyworded testing for amd64, excepting the kernel. I’ll probably go about upgrading my kernel very soon, but since LVM with pvmove works just fine, I have no strong pressure to do so. Besides, my box is still busy moving data hither and thither.
greetings! I use lvm to manage virtual machine storage on my cluster of xen host machines, for several reasons: it abstracts nicely from the underlying media, is inherently well supported by xen, and is easily migrated from host to host. However, under high i/o load, it sometimes appears that the kernel module is a (slight) bottleneck. This is not a major issue, but perplexing nonetheless, given that - while expected to be marginally slower than raw disk access - lvm is fairly speedy. I’m using sata II and a tyan server board; I do not expect the hardware to be a limitation. Have you by any chance noticed similar issues?
No such similar issues here yet, though I haven’t really taken a close look at it (will do so and report any relevant findings here, if there are any). What’s the CPU in your server?