On Monday, 7 January 2019 16:30:41 GMT Jack wrote: > On 2019.01.07 05:46, Dale wrote: > > Peter Humphrey wrote: > > > On Sunday, 6 January 2019 22:13:31 GMT Dale wrote: > > >> Even from my simple setup, LVM adds more benefits to managing data > > > > and > > > > >> drives than it does risk. The biggest thing, placing blame where > > > > it > > > > >> lies. Blaming LVM for a drive dying is placing the blame on > > > > something > > > > >> that wasn't the root of the problem. The dying drive was the > > > > problem, > > > > >> using LVM or not. > > > > > > He isn't doing that, though. As I read it, he recounted the tale of > > > > recovering > > > > > data from a failed drive, then imagined how much worse it would be > > > > if it were > > > > > in an LVM setup. [Reported speech and mixed-up tenses causing me a > > > > problem > > > > > here...] > > > > > > Thanks Gevisz, that was interesting. What we used to call a > > > > cautionary tale. > > > > > > From what I've read, that can be overcome. If you get say a SMART > > message that a drive is failing, just remove that drive or remove the > > whole LVM setup and use something else until a working drive setup can > > be made. Once ready, then move the data, if the drive still works, to > > the new drive. That is basically what I did when I swapped a smaller > > drive for a larger one. I moved the data from one drive to another. > > It > > did it fairly quickly. Someone posted that it may even be faster to > > do > > it with LVM's pvmove than it is with cp or rsync. I don't know how > > true > > that is but from what I've read, it moves the data really > > efficiently. > > If the drive has a very limited time before failure, speed is > > important. If the drive is completely dead, replace the drive and > > hope > > the backups are good. Either way, LVM or not, a failing drive is a > > failing drive. The data has to be moved if the drive still works or > > the > > data is gone if it just up and dies. The biggest thing, watching the > > SMART messages about the health of the drive. In the past when I've > > had > > a drive fail, I got error messages well ahead of time. On one drive, > > I > > removed the drive, set it aside, ordered a replacement drive, > > installed > > both drives and copied the data over. After I did all that, I played > > with the drive until it failed a day or so later. Lucky? Most > > likely. > > Still, it gave me time to transfer things over. > > > > While I get that LVM adds a layer to things, it also adds some options > > as well. Those options can prove helpful if one uses them. > > > > Just my thinking. > > > > Dale > > The only problem with all that is that SMART is far from completely > reliable. I recently had a drive fail, and the resulting fsck on the > next reboot messed up many files. (Not a Gentoo system, although I > don't think that made any difference.) After getting running again, I > did several SMART tests, including the full self-test, and it reported > ZERO errors. A few weeks later, it did the same thing, and shortly > after that, it failed totally. I had done a few more full self-tests > before final failure, and all came back clean. I'd really love to find > out there was something I did wrong in the testing, but I don't think > so. I have not yet completely given up on trying to recover stuff from > that drive, but as time goes on, there is less and less that I haven't > rebuilt or replaced by re-downloading or changing lost passwords, so > it's less and less important. (That was a different drive from the one > I messed up myself, as discussed in another recent thread here.) > > Jack
Depending on the type of errors reported by SMART, by the time you notice errors in tests the risk of losing data is already quite high. Checking deteriorating trends with smartctl won't hurt though. The filesystem problems you were getting may have been coincidental with the impending hardware failure, rather than their cause. -- Regards, Mick
signature.asc
Description: This is a digitally signed message part.
