Re: [gentoo-user] LVM and moving drive to another sata port.
On 12/14/18 7:57 AM, Rich Freeman wrote: Yes. At least by default LVM is going to scan all your drives looking for LVM PVs and will identify them regardless of what device they are on, as long as the device gets scanned. I wouldn't be surprised if LVM didn't scan all block devices. I think LVM always looks for /dev/sd* and /dev/hd* by default. (At least all the times I've used it.) I can't say the same for things like /dev/mpath* or other more intriguing block devices. Yes, in general. The only time you might have an issue is if you use something more exotic that creates a block device that might not get scanned by default, but I believe that is just a configuration fix. So, if you're using iSCSI or something maybe you might need to do a little work. Yes, there should be an entry of devices to scan and an entry of black listed devices. I think this is in /etc/lvm.conf or something like that. (It's been a number of years since I've changed it.) Bog standard PCs shouldn't need to worry about this. Servers or things with more exotic storage may have a problem in that the default might not work for them. ProTip: Be careful if you are using LVM on multipath devices. You want to make sure that LVM is scanning the multipath device and not the member path devices. LVM will happily use the first one that it finds. So scan order and / or black listing is important.
Re: [gentoo-user] LVM and moving drive to another sata port.
Rich Freeman wrote: > On Fri, Dec 14, 2018 at 9:13 AM Dale wrote: >> I'm planning to change some connections while swapping and wanted to be >> sure of something before I do any moves like this. Let's say I move sdc >> and it becomes sdb. Will LVM still see it the same way? > Yes. At least by default LVM is going to scan all your drives looking > for LVM PVs and will identify them regardless of what device they are > on, as long as the device gets scanned. > >> I suspect it >> tracks the drive by the UUID which stays the same no matter what port or >> sd letter it gets BUT I want to be sure. > It uses a UUID stored in the PV metadata. So, as long as you don't > confuse it by going and making copies of drives (which duplicates the > ID) without using the LVM tools you'll be fine. That's good to know. I thought it worked that way. >> Am I correct that changing what drive >> connects to what sata port won't matter to LVM and how it sees them? > Yes > >> Also, what if I connect one to the PCIe card I have? Will it still see >> it the same way? > Yes, in general. The only time you might have an issue is if you use > something more exotic that creates a block device that might not get > scanned by default, but I believe that is just a configuration fix. > So, if you're using iSCSI or something maybe you might need to do a > little work. It's just a plain sata card so nothing fancy. According to lspci, it sees the card. I haven't actually hooked a drive to it yet tho. >> Also, I found a wonderful guide for my upcoming move. It is located here: >> >> http://tldp.org/HOWTO/LVM-HOWTO/removeadisk.html >> >> Scroll down a bit to: 13.5.2. Distributing Old Extents to a New >> Replacement Disk >> >> That covers exactly what I am doing. Even tho Grant and others say it >> is that easy, I still find it hard to believe. O_0 I sure am glad I >> was talked into using LVM. I think it was Alan that first mentioned it >> but not sure. > You wouldn't do this if you're just moving physical disks from one > physical interface to another. > > However, if you wanted to migrate data off of one disk and onto > another, this is exactly what you would do, and this is exactly why > everybody always advises people to use LVM (or something like > zfs/btrfs with similar capabilities). It makes moving data around > almost trivial. You can migrate your data while your system is in-use > and it isn't a problem at all. I'm actually replacing a 3TB drive with a 6TB drive. So, while I'm also moving drives from one sata port to another, I'll also be replacing a hard drive as well. I'm at just over 70%. It won't be long until it starts getting to full. >> P. S. I'm still copying over my /home to the new 8TB backup drive. >> While it is copying at speeds of 20MBs/sec for some files to as high as >> 160MBs/sec for other files, it takes a long time with that much data. >> It is running at a much better speed than it was when I started the >> other thread. > LVM would migrate data more quickly than a filesystem copy, because it > is doing it at the block level. So, it doesn't matter whether a block > contains 1000 small files or part of one huge file, or filesystem > metadata. The only thing that should slow down LVM moves would be > disk activity, and I believe you can tune its priority (do you want to > slow down disk access, or LVM copying?). > > With a filesystem copy small files will kill your performance in most > cases, with some filesystems being better than others. > Well, I'm making a backup of /home just in case something goes wrong. While I don't plan to change anything, hardware wise, with the drive my OS is on, I plan to backup /etc and my world file as well. Just in case. ;-) Thanks for confirming how LVM works. At least I am reassured that I can move things around a bit. Dale :-) :-)
Re: [gentoo-user] LVM and moving drive to another sata port.
On Fri, Dec 14, 2018 at 9:13 AM Dale wrote: > > I'm planning to change some connections while swapping and wanted to be > sure of something before I do any moves like this. Let's say I move sdc > and it becomes sdb. Will LVM still see it the same way? Yes. At least by default LVM is going to scan all your drives looking for LVM PVs and will identify them regardless of what device they are on, as long as the device gets scanned. > I suspect it > tracks the drive by the UUID which stays the same no matter what port or > sd letter it gets BUT I want to be sure. It uses a UUID stored in the PV metadata. So, as long as you don't confuse it by going and making copies of drives (which duplicates the ID) without using the LVM tools you'll be fine. > Am I correct that changing what drive > connects to what sata port won't matter to LVM and how it sees them? Yes > Also, what if I connect one to the PCIe card I have? Will it still see > it the same way? Yes, in general. The only time you might have an issue is if you use something more exotic that creates a block device that might not get scanned by default, but I believe that is just a configuration fix. So, if you're using iSCSI or something maybe you might need to do a little work. > > Also, I found a wonderful guide for my upcoming move. It is located here: > > http://tldp.org/HOWTO/LVM-HOWTO/removeadisk.html > > Scroll down a bit to: 13.5.2. Distributing Old Extents to a New > Replacement Disk > > That covers exactly what I am doing. Even tho Grant and others say it > is that easy, I still find it hard to believe. O_0 I sure am glad I > was talked into using LVM. I think it was Alan that first mentioned it > but not sure. You wouldn't do this if you're just moving physical disks from one physical interface to another. However, if you wanted to migrate data off of one disk and onto another, this is exactly what you would do, and this is exactly why everybody always advises people to use LVM (or something like zfs/btrfs with similar capabilities). It makes moving data around almost trivial. You can migrate your data while your system is in-use and it isn't a problem at all. > P. S. I'm still copying over my /home to the new 8TB backup drive. > While it is copying at speeds of 20MBs/sec for some files to as high as > 160MBs/sec for other files, it takes a long time with that much data. > It is running at a much better speed than it was when I started the > other thread. LVM would migrate data more quickly than a filesystem copy, because it is doing it at the block level. So, it doesn't matter whether a block contains 1000 small files or part of one huge file, or filesystem metadata. The only thing that should slow down LVM moves would be disk activity, and I believe you can tune its priority (do you want to slow down disk access, or LVM copying?). With a filesystem copy small files will kill your performance in most cases, with some filesystems being better than others. -- Rich
[gentoo-user] LVM and moving drive to another sata port.
Howdy, I'm getting closer to swapping out a hard drive in one of my LVM groups. It has two drives in it. They are sdc and sdd as shown below. --- Physical volume --- PV Name /dev/sdc1 VG Name Home2 PV Size 2.73 TiB / not usable 3.44 MiB Allocatable yes (but full) PE Size 4.00 MiB Total PE 715396 Free PE 0 Allocated PE 715396 PV UUID ki26nc-pgTs-PCx9-qPBQ-RJNd-5Rd7-aj8sR4 --- Physical volume --- PV Name /dev/sdd1 VG Name Home2 PV Size 2.73 TiB / not usable 3.44 MiB Allocatable yes (but full) PE Size 4.00 MiB Total PE 715396 Free PE 0 Allocated PE 715396 PV UUID vg4f2b-1d6N-61hF-Adl7-0wzf-nxn6-Ol5ybJ I'm planning to change some connections while swapping and wanted to be sure of something before I do any moves like this. Let's say I move sdc and it becomes sdb. Will LVM still see it the same way? I suspect it tracks the drive by the UUID which stays the same no matter what port or sd letter it gets BUT I want to be sure. I've drawn out a diagram of how the drives are currently connected so I could go back if needed but still want to rearrange things. Am I correct that changing what drive connects to what sata port won't matter to LVM and how it sees them? Also, what if I connect one to the PCIe card I have? Will it still see it the same way? Also, I found a wonderful guide for my upcoming move. It is located here: http://tldp.org/HOWTO/LVM-HOWTO/removeadisk.html Scroll down a bit to: 13.5.2. Distributing Old Extents to a New Replacement Disk That covers exactly what I am doing. Even tho Grant and others say it is that easy, I still find it hard to believe. O_0 I sure am glad I was talked into using LVM. I think it was Alan that first mentioned it but not sure. Thanks much. Dale :-) :-) P. S. I'm still copying over my /home to the new 8TB backup drive. While it is copying at speeds of 20MBs/sec for some files to as high as 160MBs/sec for other files, it takes a long time with that much data. It is running at a much better speed than it was when I started the other thread.
