Rich Freeman wrote: > On Fri, Dec 14, 2018 at 9:13 AM Dale <[email protected]> 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 :-) :-)
