On 21 Jun 2017, Kai Krakow outgrape: > Am Wed, 21 Jun 2017 12:05:26 +0100 > schrieb Nix <nix@xxxxxxxxxxxxx>: >> The system in question is an oldie that restarts by mounting as much >> as it can readonly and then doing a reboot (when bcache would >> routinely whine about timeouts): the things it manages to remount >> readonly does not usually include / is bcache usually unhappy about >> this sort of thing? Would it prefer it if I was able to unmount it >> properly? If so, it's time to upgrade that machine... it's only that >> I've had an oops before now when stopping bcaches (early in test, not >> preserved because I thought I'd made a mistake), so I thought it >> might be unhappy about *that*, as well. > > Does your SSD support power loss protection (PLP)? It's an Intel DC3510, so one of the few that verifiably supports it and has been verified to have the damn thing actually work: it's quite new and its SMART logs report that the capacitors used to implement PLP work fine. I'm also keeping my XFS logs (journals) on there, and they were fine as well. (XFS routinely keeps stuff only in the log on a normal shutdown, on the assumption that it'll be able to replay them on remount without unnecessarily delaying the umount for a potentially huge metadata update: if the logs were corrupted, it would have told me so very loudly at startup.) I think we can rule out the SSD itself as a cause. > Having no PLP or enabling device write caching (e.g. by means of > hdparm) could result in unwanted data corruptions... This wasn't a powerdown, just a reboot. SMART reported no reset of the SSD across the reboot. -- NULL && (void) -- To unsubscribe from this list: send the line "unsubscribe linux-bcache" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
