1 |
On Fri, Dec 14, 2018 at 9:13 AM Dale <rdalek1967@×××××.com> wrote: |
2 |
> |
3 |
> I'm planning to change some connections while swapping and wanted to be |
4 |
> sure of something before I do any moves like this. Let's say I move sdc |
5 |
> and it becomes sdb. Will LVM still see it the same way? |
6 |
|
7 |
Yes. At least by default LVM is going to scan all your drives looking |
8 |
for LVM PVs and will identify them regardless of what device they are |
9 |
on, as long as the device gets scanned. |
10 |
|
11 |
> I suspect it |
12 |
> tracks the drive by the UUID which stays the same no matter what port or |
13 |
> sd letter it gets BUT I want to be sure. |
14 |
|
15 |
It uses a UUID stored in the PV metadata. So, as long as you don't |
16 |
confuse it by going and making copies of drives (which duplicates the |
17 |
ID) without using the LVM tools you'll be fine. |
18 |
|
19 |
> Am I correct that changing what drive |
20 |
> connects to what sata port won't matter to LVM and how it sees them? |
21 |
|
22 |
Yes |
23 |
|
24 |
> Also, what if I connect one to the PCIe card I have? Will it still see |
25 |
> it the same way? |
26 |
|
27 |
Yes, in general. The only time you might have an issue is if you use |
28 |
something more exotic that creates a block device that might not get |
29 |
scanned by default, but I believe that is just a configuration fix. |
30 |
So, if you're using iSCSI or something maybe you might need to do a |
31 |
little work. |
32 |
|
33 |
> |
34 |
> Also, I found a wonderful guide for my upcoming move. It is located here: |
35 |
> |
36 |
> http://tldp.org/HOWTO/LVM-HOWTO/removeadisk.html |
37 |
> |
38 |
> Scroll down a bit to: 13.5.2. Distributing Old Extents to a New |
39 |
> Replacement Disk |
40 |
> |
41 |
> That covers exactly what I am doing. Even tho Grant and others say it |
42 |
> is that easy, I still find it hard to believe. O_0 I sure am glad I |
43 |
> was talked into using LVM. I think it was Alan that first mentioned it |
44 |
> but not sure. |
45 |
|
46 |
You wouldn't do this if you're just moving physical disks from one |
47 |
physical interface to another. |
48 |
|
49 |
However, if you wanted to migrate data off of one disk and onto |
50 |
another, this is exactly what you would do, and this is exactly why |
51 |
everybody always advises people to use LVM (or something like |
52 |
zfs/btrfs with similar capabilities). It makes moving data around |
53 |
almost trivial. You can migrate your data while your system is in-use |
54 |
and it isn't a problem at all. |
55 |
|
56 |
> P. S. I'm still copying over my /home to the new 8TB backup drive. |
57 |
> While it is copying at speeds of 20MBs/sec for some files to as high as |
58 |
> 160MBs/sec for other files, it takes a long time with that much data. |
59 |
> It is running at a much better speed than it was when I started the |
60 |
> other thread. |
61 |
|
62 |
LVM would migrate data more quickly than a filesystem copy, because it |
63 |
is doing it at the block level. So, it doesn't matter whether a block |
64 |
contains 1000 small files or part of one huge file, or filesystem |
65 |
metadata. The only thing that should slow down LVM moves would be |
66 |
disk activity, and I believe you can tune its priority (do you want to |
67 |
slow down disk access, or LVM copying?). |
68 |
|
69 |
With a filesystem copy small files will kill your performance in most |
70 |
cases, with some filesystems being better than others. |
71 |
|
72 |
-- |
73 |
Rich |