1 |
On 2019.01.07 05:46, Dale wrote: |
2 |
> Peter Humphrey wrote: |
3 |
> > On Sunday, 6 January 2019 22:13:31 GMT Dale wrote: |
4 |
> > |
5 |
> >> Even from my simple setup, LVM adds more benefits to managing data |
6 |
> and |
7 |
> >> drives than it does risk. The biggest thing, placing blame where |
8 |
> it |
9 |
> >> lies. Blaming LVM for a drive dying is placing the blame on |
10 |
> something |
11 |
> >> that wasn't the root of the problem. The dying drive was the |
12 |
> problem, |
13 |
> >> using LVM or not. |
14 |
> > He isn't doing that, though. As I read it, he recounted the tale of |
15 |
> recovering |
16 |
> > data from a failed drive, then imagined how much worse it would be |
17 |
> if it were |
18 |
> > in an LVM setup. [Reported speech and mixed-up tenses causing me a |
19 |
> problem |
20 |
> > here...] |
21 |
> > |
22 |
> > Thanks Gevisz, that was interesting. What we used to call a |
23 |
> cautionary tale. |
24 |
> > |
25 |
> |
26 |
> From what I've read, that can be overcome. If you get say a SMART |
27 |
> message that a drive is failing, just remove that drive or remove the |
28 |
> whole LVM setup and use something else until a working drive setup can |
29 |
> be made. Once ready, then move the data, if the drive still works, to |
30 |
> the new drive. That is basically what I did when I swapped a smaller |
31 |
> drive for a larger one. I moved the data from one drive to another. |
32 |
> It |
33 |
> did it fairly quickly. Someone posted that it may even be faster to |
34 |
> do |
35 |
> it with LVM's pvmove than it is with cp or rsync. I don't know how |
36 |
> true |
37 |
> that is but from what I've read, it moves the data really |
38 |
> efficiently. |
39 |
> If the drive has a very limited time before failure, speed is |
40 |
> important. If the drive is completely dead, replace the drive and |
41 |
> hope |
42 |
> the backups are good. Either way, LVM or not, a failing drive is a |
43 |
> failing drive. The data has to be moved if the drive still works or |
44 |
> the |
45 |
> data is gone if it just up and dies. The biggest thing, watching the |
46 |
> SMART messages about the health of the drive. In the past when I've |
47 |
> had |
48 |
> a drive fail, I got error messages well ahead of time. On one drive, |
49 |
> I |
50 |
> removed the drive, set it aside, ordered a replacement drive, |
51 |
> installed |
52 |
> both drives and copied the data over. After I did all that, I played |
53 |
> with the drive until it failed a day or so later. Lucky? Most |
54 |
> likely. |
55 |
> Still, it gave me time to transfer things over. |
56 |
> |
57 |
> While I get that LVM adds a layer to things, it also adds some options |
58 |
> as well. Those options can prove helpful if one uses them. |
59 |
> |
60 |
> Just my thinking. |
61 |
> |
62 |
> Dale |
63 |
The only problem with all that is that SMART is far from completely |
64 |
reliable. I recently had a drive fail, and the resulting fsck on the |
65 |
next reboot messed up many files. (Not a Gentoo system, although I |
66 |
don't think that made any difference.) After getting running again, I |
67 |
did several SMART tests, including the full self-test, and it reported |
68 |
ZERO errors. A few weeks later, it did the same thing, and shortly |
69 |
after that, it failed totally. I had done a few more full self-tests |
70 |
before final failure, and all came back clean. I'd really love to find |
71 |
out there was something I did wrong in the testing, but I don't think |
72 |
so. I have not yet completely given up on trying to recover stuff from |
73 |
that drive, but as time goes on, there is less and less that I haven't |
74 |
rebuilt or replaced by re-downloading or changing lost passwords, so |
75 |
it's less and less important. (That was a different drive from the one |
76 |
I messed up myself, as discussed in another recent thread here.) |
77 |
|
78 |
Jack |