• filesystem damage

    From Eben King@21:1/5 to All on Sun Mar 2 17:00:02 2025
    I backed up my system on Saturday (yesterday), and pulled a stupid. 
    I'll explain.


    Normally I hibernate, and while it's hibernated, boot off a thumb drive
    and back up (either by partition or the whole drive) to a dedicated
    drive.  The idea is if my main drive takes a dump, I could replace it
    with the backup drive, boot, and be on my merry way.  After the backup
    has completed, I resume and it's right where I left off.


    So.  This time, while the backup was in process, I mounted /home
    read-only to check something out.  Apparently that's not good enough to
    keep the filesystem intact, because at the end when I resumed, several
    things in $HOME didn't work right.  E.G., some widgets in the panel were misconfigured, T-bird had lost its configuration, and Firefox plugins
    didn't work.  I fixed the panel widgets, T-bird appears to be *mostly*
    fixed (we'll see if this gets sent as text), but the Firefox plugins are
    still a mess.  The Noscript icon shows up in the row with the hamburger
    menu, but doesn't show up in Tools → Addons & Themes.  Adblocker for Youtube, I'm not sure it's doing anything because I still see ads before
    a video and I didn't before.  So what can I do to fix this, while still keeping my history, cookies, tabs, etc?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Charles Curley@21:1/5 to Eben King on Sun Mar 2 18:10:01 2025
    On Sun, 2 Mar 2025 10:49:41 -0500
    Eben King <[email protected]> wrote:

    So what can I do to fix this, while still
    keeping my history, cookies, tabs, etc?

    I smell a rat. I wonder if the corruption is because your hard drive is failing. I would first boot to a live CD and run smartctl tests on it.

    How did you do the backup? Per file (e.g. rsnapshot or amanda), or per
    block device (e.g. dd if=/dev/sda1 of=…)?

    If you know the relevant files and have a per file backup, restoring
    them should be a matter of selecting the correct file.

    If you don't know the relevant files (likely with modern GUIs),
    consider saving off the whole kazoo (e.g. mv /home/name /home/name.old)
    and then restoring from backup. That means you loose everything since
    the last backup, except for files you can identify in the saved copy. Be
    sure the ownership and permissions on the new /home/name are correct.

    I am assuming that the corruption is all in /home and that it is
    included in your backups. If either one of those is false, you may be
    in deep yogurt.

    --
    Does anybody read signatures any more?

    https://charlescurley.com
    https://charlescurley.com/blog/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stefan Monnier@21:1/5 to All on Sun Mar 2 18:20:01 2025
    So.� This time, while the backup was in process, I mounted /home
    read-only to check something out.� Apparently that's not good enough to
    keep the filesystem intact,

    Indeed, with ext4 (and maybe other journaled filesystems as well), even
    if you mount read-only the system starts by (re)playing the end of the
    journal to make sure the filesystem is in a consistent state.

    because at the end when I resumed, several
    things in $HOME didn't work right.

    So apparently the resumed system then went on to "unconsistentify" the
    file system somehow, due to it not knowing that the journal had been
    (re)played behind its back. I don't know enough of the details to know
    why that happens (playing the journal is conceptually something that
    should be idempotent, but obviously things are more subtle than that).

    So what can I do to fix this, while still keeping my history, cookies,
    tabs, etc?

    I'd start by unmounting the file system (might require a reboot) and
    forcing an `fsck`. After that, you might want to compare the files
    between your fsck'd partition and its backup. The sooner you do it,
    the fewer changes there are, so the easier it will be to spot the
    relevant (i.e. undesired) changes.


    Stefan

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael Stone@21:1/5 to Eben King on Sun Mar 2 18:20:01 2025
    On Sun, Mar 02, 2025 at 10:49:41AM -0500, Eben King wrote:
    So.� This time, while the backup was in process, I mounted /home
    read-only to check something out.� Apparently that's not good enough to
    keep the filesystem intact, because at the end when I resumed, several
    things in $HOME didn't work right.

    Correct. Even mounted read-only, the driver will replay the journal and
    resolve any outstanding actions--but the hibernated system doesn't know
    that, and will proceed without taking any changes into account. You
    could have mounted with "-o ro,norecovery" which will prevent the
    journal replay and make the mount truly read-only. Your best bet at this
    point is to force an fsck to at least ensure that the filesystem is
    consistent, but if there was any data corruption that won't uncorrupt
    it. To be certain that all the data is ok you'll have to restore to the
    last backup made before this happened.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Eben King@21:1/5 to All on Sun Mar 2 19:00:01 2025
    DQpPbiAzLzIvMjUgMTI6MDMsIENoYXJsZXMgQ3VybGV5IHdyb3RlOg0KPiBPbiBTdW4sIDIgTWFy IDIwMjUgMTA6NDk6NDEgLTA1MDANCj4gRWJlbiBLaW5nIDxlYmVuQGdteC51cz4gd3JvdGU6DQo+ DQo+PiBTbyB3aGF0IGNhbiBJIGRvIHRvIGZpeCB0aGlzLCB3aGlsZSBzdGlsbA0KPj4ga2VlcGlu ZyBteSBoaXN0b3J5LCBjb29raWVzLCB0YWJzLCBldGM/DQoNCj4gSSBzbWVsbCBhIHJhdC4gSSB3 b25kZXIgaWYgdGhlIGNvcnJ1cHRpb24gaXMgYmVjYXVzZSB5b3VyIGhhcmQgZHJpdmUgaXMNCj4g ZmFpbGluZy4gSSB3b3VsZCBmaXJzdCBib290IHRvIGEgbGl2ZSBDRCBhbmQgcnVuIHNtYXJ0Y3Rs IHRlc3RzIG9uIGl0Lg0KDQpBdCB0aGUgZW5kIG9mIHRoaXMgbWVzc2FnZS4NCg0KDQo+IEhvdyBk aWQgeW91IGRvIHRoZSBiYWNrdXA/IFBlciBmaWxlIChlLmcuIHJzbmFwc2hvdCBvciBhbWFuZGEp LCBvciBwZXINCj4gYmxvY2sgZGV2aWNlIChlLmcuIGRkIGlmPS9kZXYvc2RhMSBvZj3igKYpPw0K DQoNCkJsb2NrIGRldmljZS7CoCBJZiBJJ3ZlIHJlc2l6ZSAvIG1vdmVkIGEgcGFydGl0aW9uIHNp bmNlIHRoZSBsYXN0IGJhY2t1cCANCkknbGwgZG8gYSBmdWxsIChkZCBpZj0vZGV2L3NkYSBvZj0v ZGV2L3NkYyksIGlmIG5vdCBJJ2xsIGRvIGl0IGJ5IA0KcGFydGl0aW9uIChkZCBpZj0vZGV2L3Nk YVggb2Y9L2Rldi9zZGNYKS7CoCBTaW5jZSBvbmx5IG1heWJlIDcwJSBvZiB0aGUgDQpkcml2ZSBp cyBpbiBwYXJ0aXRpb25zLCBpdCdzIGZhc3RlciB0aGF0IHdheS4NCg0KDQpJIGp1c3Qgc2h1dCBk b3duIGFuZCBib290ZWQgb2ZmIGEgdGh1bWIgZHJpdmUsIGFuZCByYW4gImZzY2sgLWYiIG9uIGVh Y2ggDQpleHQ0IHBhcnRpdGlvbi7CoCBNb3N0IGhhZCBubyBlcnJvcnMsIGJ1dCBhIGZldyBoYWQg InRoaXMgaW5vZGUgaXMgdG9vIA0Kd2lkZSIgZXJyb3JzLsKgIFRoZXJlIG1heSBoYXZlIGJlZW4g b25lIG9yIHR3byBvdGhlcnMuwqAgQW55aG93LCBJJ2xsIA0KY2hlY2sgYWdhaW4gaW4gYSBmZXcg ZGF5cyBhbmQgc2VlIGlmIHRob3NlIChvciBvdGhlcikgZXJyb3JzIHJlY3VyLg0KDQoNCj4gSWYg eW91IGtub3cgdGhlIHJlbGV2YW50IGZpbGVzIGFuZCBoYXZlIGEgcGVyIGZpbGUgYmFja3VwLCBy ZXN0b3JpbmcNCj4gdGhlbSBzaG91bGQgYmUgYSBtYXR0ZXIgb2Ygc2VsZWN0aW5nIHRoZSBjb3Jy ZWN0IGZpbGUuDQoNCg0KVGhlIG1vc3Qgb2Jub3hpb3VzIGVycm9ycyBhcmUgZGVmaW5pdGVseSB1 bmRlciB+Ly5tb3ppbGxhL2ZpcmVmb3ggYW5kIA0KcHJvYmFibHkgfi8ubW96aWxsYS9maXJlZm94 Lzxwcm9maWxlPi9leHRlbnNpb24qIC4NCg0KPiBJIGFtIGFzc3VtaW5nIHRoYXQgdGhlIGNvcnJ1 cHRpb24gaXMgYWxsIGluIC9ob21lIGFuZCB0aGF0IGl0IGlzDQo+IGluY2x1ZGVkIGluIHlvdXIg YmFja3Vwcy4gSWYgZWl0aGVyIG9uZSBvZiB0aG9zZSBpcyBmYWxzZSwgeW91IG1heSBiZQ0KPiBp biBkZWVwIHlvZ3VydC4NCg0KDQpZZWFoLCBJIGRvbid0IGtub3cgaG93IG11Y2ggSSB0cnVzdCB0 aGUgYmFja3VwIG9mIC9ob21lIHJpZ2h0IG5vdy4NCg0KDQplYmVuQGNlcmJlcnVzOi8kIHN1ZG8g c21hcnRjdGwgLWEgL2Rldi9zZGENCnNtYXJ0Y3RsIDcuMyAyMDIyLTAyLTI4IHI1MzM4IFt4ODZf NjQtbGludXgtNi4xLjAtMzEtYW1kNjRdIChsb2NhbCBidWlsZCkNCkNvcHlyaWdodCAoQykgMjAw Mi0yMiwgQnJ1Y2UgQWxsZW4sIENocmlzdGlhbiBGcmFua2UsIHd3dy5zbWFydG1vbnRvb2xzLm9y Zw0KDQo9PT0gU1RBUlQgT0YgSU5GT1JNQVRJT04gU0VDVElPTiA9PT0NCk1vZGVsIEZhbWlseTrC oMKgwqDCoCBTZWFnYXRlIEJhcnJhQ3VkYSAzLjUgKFNNUikNCkRldmljZSBNb2RlbDrCoMKgwqDC oCBTVDIwMDBETTAwOC0yVUIxMDINClNlcmlhbCBOdW1iZXI6wqDCoMKgIFpLMjBOV0swDQpMVSBX V04gRGV2aWNlIElkOiA1IDAwMGM1MCAwZTdmMDk5MDUNCkZpcm13YXJlIFZlcnNpb246IDAwMDEN ClVzZXIgQ2FwYWNpdHk6wqDCoMKgIDIsMDAwLDM5OCw5MzQsMDE2IGJ5dGVzIFsyLjAwIFRCXQ0K U2VjdG9yIFNpemVzOsKgwqDCoMKgIDUxMiBieXRlcyBsb2dpY2FsLCA0MDk2IGJ5dGVzIHBoeXNp Y2FsDQpSb3RhdGlvbiBSYXRlOsKgwqDCoCA3MjAwIHJwbQ0KRm9ybSBGYWN0b3I6wqDCoMKgwqDC oCAzLjUgaW5jaGVzDQpUUklNIENvbW1hbmQ6wqDCoMKgwqAgQXZhaWxhYmxlDQpEZXZpY2UgaXM6 wqDCoMKgwqDCoMKgwqAgSW4gc21hcnRjdGwgZGF0YWJhc2UgNy4zLzUzMTkNCkFUQSBWZXJzaW9u IGlzOsKgwqAgQUNTLTMgVDEzLzIxNjEtRCByZXZpc2lvbiA1DQpTQVRBIFZlcnNpb24gaXM6wqAg U0FUQSAzLjEsIDYuMCBHYi9zIChjdXJyZW50OiA2LjAgR2IvcykNCkxvY2FsIFRpbWUgaXM6wqDC oMKgIFN1biBNYXLCoCAyIDEyOjM2OjQwIDIwMjUgRVNUDQpTTUFSVCBzdXBwb3J0IGlzOiBBdmFp bGFibGUgLSBkZXZpY2UgaGFzIFNNQVJUIGNhcGFiaWxpdHkuDQpTTUFSVCBzdXBwb3J0IGlzOiBF bmFibGVkDQoNCj09PSBTVEFSVCBPRiBSRUFEIFNNQVJUIERBVEEgU0VDVElPTiA9PT0NClNNQVJU IG92ZXJhbGwtaGVhbHRoIHNlbGYtYXNzZXNzbWVudCB0ZXN0IHJlc3VsdDogUEFTU0VEDQoNCkdl bmVyYWwgU01BUlQgVmFsdWVzOg0KT2ZmbGluZSBkYXRhIGNvbGxlY3Rpb24gc3RhdHVzOsKgICgw eDAwKcKgwqDCoCBPZmZsaW5lIGRhdGEgY29sbGVjdGlvbiBhY3Rpdml0eQ0KIMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHdhcyBuZXZlciBzdGFydGVkLg0KIMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIEF1dG8gT2ZmbGluZSBEYXRhIENvbGxlY3Rp b246IERpc2FibGVkLg0KU2VsZi10ZXN0IGV4ZWN1dGlvbiBzdGF0dXM6wqDCoMKgwqDCoCAowqDC oCAwKcKgwqDCoCBUaGUgcHJldmlvdXMgc2VsZi10ZXN0IA0Kcm91dGluZSBjb21wbGV0ZWQNCiDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB3aXRob3V0IGVycm9yIG9yIG5v IHNlbGYtdGVzdCBoYXMgZXZlcg0KIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgIGJlZW4gcnVuLg0KVG90YWwgdGltZSB0byBjb21wbGV0ZSBPZmZsaW5lDQpkYXRhIGNvbGxl Y3Rpb246wqDCoMKgwqDCoMKgwqDCoCAowqDCoMKgIDApIHNlY29uZHMuDQpPZmZsaW5lIGRhdGEg Y29sbGVjdGlvbg0KY2FwYWJpbGl0aWVzOsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICgweDcz KSBTTUFSVCBleGVjdXRlIE9mZmxpbmUgaW1tZWRpYXRlLg0KIMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIEF1dG8gT2ZmbGluZSBkYXRhIGNvbGxlY3Rpb24gb24vb2ZmIHN1 cHBvcnQuDQogwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgU3VzcGVuZCBP ZmZsaW5lIGNvbGxlY3Rpb24gdXBvbiBuZXcNCiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCBjb21tYW5kLg0KIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgIE5vIE9mZmxpbmUgc3VyZmFjZSBzY2FuIHN1cHBvcnRlZC4NCiDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBTZWxmLXRlc3Qgc3VwcG9ydGVkLg0KIMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIENvbnZleWFuY2UgU2VsZi10ZXN0IHN1cHBvcnRl ZC4NCiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBTZWxlY3RpdmUgU2Vs Zi10ZXN0IHN1cHBvcnRlZC4NClNNQVJUIGNhcGFiaWxpdGllczrCoMKgwqDCoMKgwqDCoMKgwqDC oMKgICgweDAwMDMpwqDCoMKgIFNhdmVzIFNNQVJUIGRhdGEgYmVmb3JlIGVudGVyaW5nDQogwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgcG93ZXItc2F2aW5nIG1vZGUuDQog wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgU3VwcG9ydHMgU01BUlQgYXV0 byBzYXZlIHRpbWVyLg0KRXJyb3IgbG9nZ2luZyBjYXBhYmlsaXR5OsKgwqDCoMKgwqDCoMKgICgw eDAxKcKgwqDCoCBFcnJvciBsb2dnaW5nIHN1cHBvcnRlZC4NCiDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCBHZW5lcmFsIFB1cnBvc2UgTG9nZ2luZyBzdXBwb3J0ZWQuDQpT aG9ydCBzZWxmLXRlc3Qgcm91dGluZQ0KcmVjb21tZW5kZWQgcG9sbGluZyB0aW1lOsKgwqDCoMKg wqAgKMKgwqAgMSkgbWludXRlcy4NCkV4dGVuZGVkIHNlbGYtdGVzdCByb3V0aW5lDQpyZWNvbW1l bmRlZCBwb2xsaW5nIHRpbWU6wqDCoMKgwqDCoCAoIDIwNCkgbWludXRlcy4NCkNvbnZleWFuY2Ug c2VsZi10ZXN0IHJvdXRpbmUNCnJlY29tbWVuZGVkIHBvbGxpbmcgdGltZTrCoMKgwqDCoMKgICjC oMKgIDIpIG1pbnV0ZXMuDQpTQ1QgY2FwYWJpbGl0aWVzOsKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg KDB4MzBhNSnCoMKgwqAgU0NUIFN0YXR1cyBzdXBwb3J0ZWQuDQogwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqAgU0NUIERhdGEgVGFibGUgc3VwcG9ydGVkLg0KDQpTTUFSVCBB dHRyaWJ1dGVzIERhdGEgU3RydWN0dXJlIHJldmlzaW9uIG51bWJlcjogMTANClZlbmRvciBTcGVj aWZpYyBTTUFSVCBBdHRyaWJ1dGVzIHdpdGggVGhyZXNob2xkczoNCklEIyBBVFRSSUJVVEVfTkFN RcKgwqDCoMKgwqDCoMKgwqDCoCBGTEFHwqDCoMKgwqAgVkFMVUUgV09SU1QgVEhSRVNIIFRZUEUg VVBEQVRFRMKgIA0KV0hFTl9GQUlMRUQgUkFXX1ZBTFVFDQogwqAgMSBSYXdfUmVhZF9FcnJvcl9S YXRlwqDCoMKgwqAgMHgwMDBmwqDCoCAwODLCoMKgIDA2NMKgwqAgMDA2wqDCoMKgIFByZS1mYWls IA0KQWx3YXlzwqDCoMKgwqDCoMKgIC3CoMKgwqDCoMKgwqAgMTQ2MzY5MjYyDQogwqAgMyBTcGlu X1VwX1RpbWXCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDB4MDAwM8KgwqAgMDk1wqDCoCAwOTXCoMKg IDAwMMKgwqDCoCBQcmUtZmFpbCANCkFsd2F5c8KgwqDCoMKgwqDCoCAtwqDCoMKgwqDCoMKgIDAN CiDCoCA0IFN0YXJ0X1N0b3BfQ291bnTCoMKgwqDCoMKgwqDCoCAweDAwMzLCoMKgIDEwMMKgwqAg MTAwwqDCoCAwMjDCoMKgwqAgT2xkX2FnZSANCkFsd2F5c8KgwqDCoMKgwqDCoCAtwqDCoMKgwqDC oMKgIDcyMw0KIMKgIDUgUmVhbGxvY2F0ZWRfU2VjdG9yX0N0wqDCoCAweDAwMzPCoMKgIDEwMMKg wqAgMTAwwqDCoCAwMTDCoMKgwqAgUHJlLWZhaWwgDQpBbHdheXPCoMKgwqDCoMKgwqAgLcKgwqDC oMKgwqDCoCAwDQogwqAgNyBTZWVrX0Vycm9yX1JhdGXCoMKgwqDCoMKgwqDCoMKgIDB4MDAwZsKg wqAgMDg0wqDCoCAwNjDCoMKgIDA0NcKgwqDCoCBQcmUtZmFpbCANCkFsd2F5c8KgwqDCoMKgwqDC oCAtwqDCoMKgwqDCoMKgIDIzMjM4MjU3MA0KIMKgIDkgUG93ZXJfT25fSG91cnPCoMKgwqDCoMKg wqDCoMKgwqAgMHgwMDMywqDCoCAwOTPCoMKgIDA5M8KgwqAgMDAwwqDCoMKgIE9sZF9hZ2UgDQpB bHdheXPCoMKgwqDCoMKgwqAgLcKgwqDCoMKgwqDCoCA2MzQ2aCsyMG0rNDYuMjk3cw0KIMKgMTAg U3Bpbl9SZXRyeV9Db3VudMKgwqDCoMKgwqDCoMKgIDB4MDAxM8KgwqAgMTAwwqDCoCAxMDDCoMKg IDA5N8KgwqDCoCBQcmUtZmFpbCANCkFsd2F5c8KgwqDCoMKgwqDCoCAtwqDCoMKgwqDCoMKgIDAN CiDCoDEyIFBvd2VyX0N5Y2xlX0NvdW50wqDCoMKgwqDCoMKgIDB4MDAzMsKgwqAgMTAwwqDCoCAx MDDCoMKgIDAyMMKgwqDCoCBPbGRfYWdlIA0KQWx3YXlzwqDCoMKgwqDCoMKgIC3CoMKgwqDCoMKg wqAgNTQxDQoxODMgUnVudGltZV9CYWRfQmxvY2vCoMKgwqDCoMKgwqAgMHgwMDMywqDCoCAxMDDC oMKgIDEwMMKgwqAgMDAwwqDCoMKgIE9sZF9hZ2UgDQpBbHdheXPCoMKgwqDCoMKgwqAgLcKgwqDC oMKgwqDCoCAwDQoxODQgRW5kLXRvLUVuZF9FcnJvcsKgwqDCoMKgwqDCoMKgIDB4MDAzMsKgwqAg MTAwwqDCoCAxMDDCoMKgIDA5OcKgwqDCoCBPbGRfYWdlIA0KQWx3YXlzwqDCoMKgwqDCoMKgIC3C oMKgwqDCoMKgwqAgMA0KMTg3IFJlcG9ydGVkX1VuY29ycmVjdMKgwqDCoMKgwqAgMHgwMDMywqDC oCAxMDDCoMKgIDEwMMKgwqAgMDAwwqDCoMKgIE9sZF9hZ2UgDQpBbHdheXPCoMKgwqDCoMKgwqAg LcKgwqDCoMKgwqDCoCAwDQoxODggQ29tbWFuZF9UaW1lb3V0wqDCoMKgwqDCoMKgwqDCoCAweDAw MzLCoMKgIDEwMMKgwqAgMTAwwqDCoCAwMDDCoMKgwqAgT2xkX2FnZSANCkFsd2F5c8KgwqDCoMKg wqDCoCAtwqDCoMKgwqDCoMKgIDAgMCAwDQoxODkgSGlnaF9GbHlfV3JpdGVzwqDCoMKgwqDCoMKg wqDCoCAweDAwM2HCoMKgIDEwMMKgwqAgMTAwwqDCoCAwMDDCoMKgwqAgT2xkX2FnZSANCkFsd2F5 c8KgwqDCoMKgwqDCoCAtwqDCoMKgwqDCoMKgIDANCjE5MCBBaXJmbG93X1RlbXBlcmF0dXJlX0Nl bCAweDAwMjLCoMKgIDA2MMKgwqAgMDUzwqDCoCAwNDDCoMKgwqAgT2xkX2FnZSANCkFsd2F5c8Kg wqDCoMKgwqDCoCAtwqDCoMKgwqDCoMKgIDQwIChNaW4vTWF4IDI3LzQwKQ0KMTkxIEctU2Vuc2Vf RXJyb3JfUmF0ZcKgwqDCoMKgwqAgMHgwMDMywqDCoCAxMDDCoMKgIDEwMMKgwqAgMDAwwqDCoMKg IE9sZF9hZ2UgDQpBbHdheXPCoMKgwqDCoMKgwqAgLcKgwqDCoMKgwqDCoCAwDQoxOTIgUG93ZXIt T2ZmX1JldHJhY3RfQ291bnQgMHgwMDMywqDCoCAxMDDCoMKgIDEwMMKgwqAgMDAwwqDCoMKgIE9s ZF9hZ2UgDQpBbHdheXPCoMKgwqDCoMKgwqAgLcKgwqDCoMKgwqDCoCAxNTUNCjE5MyBMb2FkX0N5 Y2xlX0NvdW50wqDCoMKgwqDCoMKgwqAgMHgwMDMywqDCoCAxMDDCoMKgIDEwMMKgwqAgMDAwwqDC oMKgIE9sZF9hZ2UgDQpBbHdheXPCoMKgwqDCoMKgwqAgLcKgwqDCoMKgwqDCoCAxMDQwDQoxOTQg VGVtcGVyYXR1cmVfQ2Vsc2l1c8KgwqDCoMKgIDB4MDAyMsKgwqAgMDQwwqDCoCAwNDfCoMKgIDAw MMKgwqDCoCBPbGRfYWdlIA0KQWx3YXlzwqDCoMKgwqDCoMKgIC3CoMKgwqDCoMKgwqAgNDAgKDAg MjUgMCAwIDApDQoxOTUgSGFyZHdhcmVfRUNDX1JlY292ZXJlZMKgIDB4MDAxYcKgwqAgMDgywqDC oCAwNjTCoMKgIDAwMMKgwqDCoCBPbGRfYWdlIA0KQWx3YXlzwqDCoMKgwqDCoMKgIC3CoMKgwqDC oMKgwqAgMTQ2MzY5MjYyDQoxOTcgQ3VycmVudF9QZW5kaW5nX1NlY3RvcsKgIDB4MDAxMsKgwqAg MTAwwqDCoCAxMDDCoMKgIDAwMMKgwqDCoCBPbGRfYWdlIA0KQWx3YXlzwqDCoMKgwqDCoMKgIC3C oMKgwqDCoMKgwqAgMA0KMTk4IE9mZmxpbmVfVW5jb3JyZWN0YWJsZcKgwqAgMHgwMDEwwqDCoCAx MDDCoMKgIDEwMMKgwqAgMDAwwqDCoMKgIE9sZF9hZ2UgDQpPZmZsaW5lwqDCoMKgwqDCoCAtwqDC oMKgwqDCoMKgIDANCjE5OSBVRE1BX0NSQ19FcnJvcl9Db3VudMKgwqDCoCAweDAwM2XCoMKgIDIw MMKgwqAgMjAwwqDCoCAwMDDCoMKgwqAgT2xkX2FnZSANCkFsd2F5c8KgwqDCoMKgwqDCoCAtwqDC oMKgwqDCoMKgIDANCjI0MCBIZWFkX0ZseWluZ19Ib3Vyc8KgwqDCoMKgwqDCoCAweDAwMDDCoMKg IDEwMMKgwqAgMjUzwqDCoCAwMDDCoMKgwqAgT2xkX2FnZSANCk9mZmxpbmXCoMKgwqDCoMKgIC3C oMKgwqDCoMKgwqAgNjMyMGgrMTJtKzI2Ljc5N3MNCjI0MSBUb3RhbF9MQkFzX1dyaXR0ZW7CoMKg wqDCoMKgIDB4MDAwMMKgwqAgMTAwwqDCoCAyNTPCoMKgIDAwMMKgwqDCoCBPbGRfYWdlIA0KT2Zm bGluZcKgwqDCoMKgwqAgLcKgwqDCoMKgwqDCoCAxODY1NzM0MjMyMA0KMjQyIFRvdGFsX0xCQXNf UmVhZMKgwqDCoMKgwqDCoMKgwqAgMHgwMDAwwqDCoCAxMDDCoMKgIDI1M8KgwqAgMDAwwqDCoMKg IE9sZF9hZ2UgDQpPZmZsaW5lwqDCoMKgwqDCoCAtwqDCoMKgwqDCoMKgIDkyMzc5NjIwMjQyDQoN ClNNQVJUIEVycm9yIExvZyBWZXJzaW9uOiAxDQpObyBFcnJvcnMgTG9nZ2VkDQoNClNNQVJUIFNl bGYtdGVzdCBsb2cgc3RydWN0dXJlIHJldmlzaW9uIG51bWJlciAxDQpObyBzZWxmLXRlc3RzIGhh dmUgYmVlbiBsb2dnZWQuwqAgW1RvIHJ1biBzZWxmLXRlc3RzLCB1c2U6IHNtYXJ0Y3RsIC10XQ0K DQpTTUFSVCBTZWxlY3RpdmUgc2VsZi10ZXN0IGxvZyBkYXRhIHN0cnVjdHVyZSByZXZpc2lvbiBu dW1iZXIgMQ0KIMKgU1BBTsKgIE1JTl9MQkHCoCBNQVhfTEJBwqAgQ1VSUkVOVF9URVNUX1NUQVRV Uw0KIMKgwqDCoCAxwqDCoMKgwqDCoMKgwqAgMMKgwqDCoMKgwqDCoMKgIDDCoCBOb3RfdGVzdGlu Zw0KIMKgwqDCoCAywqDCoMKgwqDCoMKgwqAgMMKgwqDCoMKgwqDCoMKgIDDCoCBOb3RfdGVzdGlu Zw0KIMKgwqDCoCAzwqDCoMKgwqDCoMKgwqAgMMKgwqDCoMKgwqDCoMKgIDDCoCBOb3RfdGVzdGlu Zw0KIMKgwqDCoCA0wqDCoMKgwqDCoMKgwqAgMMKgwqDCoMKgwqDCoMKgIDDCoCBOb3RfdGVzdGlu Zw0KIMKgwqDCoCA1wqDCoMKgwqDCoMKgwqAgMMKgwqDCoMKgwqDCoMKgIDDCoCBOb3RfdGVzdGlu Zw0KU2VsZWN0aXZlIHNlbGYtdGVzdCBmbGFncyAoMHgwKToNCiDCoCBBZnRlciBzY2FubmluZyBz ZWxlY3RlZCBzcGFucywgZG8gTk9UIHJlYWQtc2NhbiByZW1haW5kZXIgb2YgZGlzay4NCklmIFNl bGVjdGl2ZSBzZWxmLXRlc3QgaXMgcGVuZGluZyBvbiBwb3dlci11cCwgcmVzdW1lIGFmdGVyIDAg bWludXRlIGRlbGF5Lg0KDQoNCkp1c3QgZm9yIGtpY2tzLCB0aGlzIGxpbmUgaGFzIGEgc3BhY2Ug YXQgdGhlIGVuZC4NCg0KVGhpcyBsaW5lIGhhcyB0d28uDQoNCg==

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anssi Saari@21:1/5 to Eben King on Sun Mar 2 20:30:02 2025
    Eben King <[email protected]> writes:

    Normally I hibernate, and while it's hibernated, boot off a thumb drive
    and back up (either by partition or the whole drive) to a dedicated
    drive.� The idea is if my main drive takes a dump, I could replace it
    with the backup drive, boot, and be on my merry way.� After the backup
    has completed, I resume and it's right where I left off.

    So you actually back up the hibernated / partition? Is that really a
    sound backup strategy? Seems risky to me but if it works I guess it's
    fine.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Chris Green@21:1/5 to Anssi Saari on Sun Mar 2 21:00:02 2025
    Anssi Saari <[email protected]> wrote:
    Eben King <[email protected]> writes:

    Normally I hibernate, and while it's hibernated, boot off a thumb drive
    and back up (either by partition or the whole drive) to a dedicated drive.  The idea is if my main drive takes a dump, I could replace it
    with the backup drive, boot, and be on my merry way.  After the backup
    has completed, I resume and it's right where I left off.

    So you actually back up the hibernated / partition? Is that really a
    sound backup strategy? Seems risky to me but if it works I guess it's
    fine.

    With modern systems booting so fast I wonder why anyone bothers with
    hibernate or sleep.

    --
    Chris Green
    ·

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Eben King@21:1/5 to Anssi Saari on Sun Mar 2 20:50:01 2025
    On 3/2/25 14:23, Anssi Saari wrote:
    Eben King <[email protected]> writes:

    Normally I hibernate, and while it's hibernated, boot off a thumb drive
    and back up (either by partition or the whole drive) to a dedicated
    drive.  The idea is if my main drive takes a dump, I could replace it
    with the backup drive, boot, and be on my merry way.  After the backup
    has completed, I resume and it's right where I left off.
    So you actually back up the hibernated / partition? Is that really a
    sound backup strategy? Seems risky to me but if it works I guess it's
    fine.


    It normally works fine.  I haven't had to do a full restore, but I have restored / and /usr , and that worked without noticeable error.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Christensen@21:1/5 to Eben King on Sun Mar 2 20:40:02 2025
    On 3/2/25 07:49, Eben King wrote:
    I backed up my system on Saturday (yesterday), and pulled a stupid.
    I'll explain.


    Normally I hibernate, and while it's hibernated, boot off a thumb drive
    and back up (either by partition or the whole drive) to a dedicated
    drive.  The idea is if my main drive takes a dump, I could replace it
    with the backup drive, boot, and be on my merry way.  After the backup
    has completed, I resume and it's right where I left off.


    So.  This time, while the backup was in process, I mounted /home
    read-only to check something out.  Apparently that's not good enough to
    keep the filesystem intact, because at the end when I resumed, several
    things in $HOME didn't work right.  E.G., some widgets in the panel were misconfigured, T-bird had lost its configuration, and Firefox plugins
    didn't work.  I fixed the panel widgets, T-bird appears to be *mostly*
    fixed (we'll see if this gets sent as text), but the Firefox plugins are still a mess.  The Noscript icon shows up in the row with the hamburger menu, but doesn't show up in Tools → Addons & Themes.  Adblocker for Youtube, I'm not sure it's doing anything because I still see ads before
    a video and I didn't before.  So what can I do to fix this, while still keeping my history, cookies, tabs, etc?


    On 3/2/25 09:17, Michael Stone wrote:
    Even mounted read-only, the driver will replay the journal and resolve
    any outstanding actions--but the hibernated system doesn't know that,
    and will proceed without taking any changes into account. You could have mounted with "-o ro,norecovery" which will prevent the journal replay
    and make the mount truly read-only. Your best bet at this point is to
    force an fsck to at least ensure that the filesystem is consistent, but
    if there was any data corruption that won't uncorrupt it. To be certain
    that all the data is ok you'll have to restore to the last backup made before this happened.


    On 3/2/25 09:51, Eben King wrote:

    On 3/2/25 12:03, Charles Curley wrote:
    On Sun, 2 Mar 2025 10:49:41 -0500
    Eben King <[email protected]> wrote:
    ...
    How did you do the backup? Per file (e.g. rsnapshot or amanda), or per
    block device (e.g. dd if=/dev/sda1 of=…)?


    Block device. If I've resize / moved a partition since the last backup
    I'll do a full (dd if=/dev/sda of=/dev/sdc), if not I'll do it by
    partition (dd if=/dev/sdaX of=/dev/sdcX). Since only maybe 70% of the
    drive is in partitions, it's faster that way.


    I just shut down and booted off a thumb drive, and ran "fsck -f" on each ext4 partition. Most had no errors, but a few had "this inode is too
    wide" errors. There may have been one or two others. Anyhow, I'll
    check again in a few days and see if those (or other) errors recur.


    If you know the relevant files and have a per file backup, restoring
    them should be a matter of selecting the correct file.


    The most obnoxious errors are definitely under ~/.mozilla/firefox and probably ~/.mozilla/firefox/<profile>/extension* .

    I am assuming that the corruption is all in /home and that it is
    included in your backups. If either one of those is false, you may be
    in deep yogurt.


    Yeah, I don't know how much I trust the backup of /home right now.


    I am glad I do not do hibernation -- I power down before taking images
    of the raw device.


    At this point, I am uncertain if the /home ext4 file systems are correct
    on either the OS disc or the copied image disc (?). I would start
    thinking about doing a backup/ wipe/ fresh install/ restore procedure.


    The "norecovery" option for mount(8) seems like a dangerous design
    choice. "readonly" is supposed to mean "do not write to disk". I must remember that land mine if and when I want to do forensic work.


    eben@cerberus:/$ sudo smartctl -a /dev/sda
    smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.0-31-amd64] (local build) Copyright (C) 2002-22, Bruce Allen, Christian Franke,
    www.smartmontools.org

    === START OF INFORMATION SECTION ===
    Model Family: Seagate BarraCuda 3.5 (SMR)
    Device Model: ST2000DM008-2UB102


    AIUI SMR does not work well for OS (e.g. /tmp, swap) and general-purpose
    (e.g. /home) disks that see frequent small random write workloads. I
    prefer small high-quality 2.5" SSD's (Intel SSD 520 Series 60 GB) for my
    OS and /home disks, and put my bulk data on a file server. I would
    re-purpose that HDD for images -- CMR should be okay for large
    sequential write workloads.


    ...
    === START OF READ SMART DATA SECTION ===
    SMART overall-health self-assessment test result: PASSED


    Good.


    ...
    SMART Attributes Data Structure revision number: 10
    Vendor Specific SMART Attributes with Thresholds:
    ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
    1 Raw_Read_Error_Rate 0x000f 082 064 006 Pre-fail
    Always - 146369262
    3 Spin_Up_Time 0x0003 095 095 000 Pre-fail
    Always - 0
    4 Start_Stop_Count 0x0032 100 100 020 Old_age
    Always - 723
    5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail
    Always - 0
    7 Seek_Error_Rate 0x000f 084 060 045 Pre-fail
    Always - 232382570
    9 Power_On_Hours 0x0032 093 093 000 Old_age
    Always - 6346h+20m+46.297s
    10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail
    Always - 0
    12 Power_Cycle_Count 0x0032 100 100 020 Old_age
    Always - 541
    183 Runtime_Bad_Block 0x0032 100 100 000 Old_age
    Always - 0
    184 End-to-End_Error 0x0032 100 100 099 Old_age
    Always - 0
    187 Reported_Uncorrect 0x0032 100 100 000 Old_age
    Always - 0
    188 Command_Timeout 0x0032 100 100 000 Old_age
    Always - 0 0 0
    189 High_Fly_Writes 0x003a 100 100 000 Old_age
    Always - 0
    190 Airflow_Temperature_Cel 0x0022 060 053 040 Old_age
    Always - 40 (Min/Max 27/40)
    191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age
    Always - 0
    192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age
    Always - 155
    193 Load_Cycle_Count 0x0032 100 100 000 Old_age
    Always - 1040
    194 Temperature_Celsius 0x0022 040 047 000 Old_age
    Always - 40 (0 25 0 0 0)
    195 Hardware_ECC_Recovered 0x001a 082 064 000 Old_age
    Always - 146369262
    197 Current_Pending_Sector 0x0012 100 100 000 Old_age
    Always - 0
    198 Offline_Uncorrectable 0x0010 100 100 000 Old_age
    Offline - 0
    199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age
    Always - 0
    240 Head_Flying_Hours 0x0000 100 253 000 Old_age
    Offline - 6320h+12m+26.797s
    241 Total_LBAs_Written 0x0000 100 253 000 Old_age
    Offline - 18657342320
    242 Total_LBAs_Read 0x0000 100 253 000 Old_age
    Offline - 92379620242


    Those statistics look acceptable for a used desktop HDD. All of the
    most worrisome statistics are 100%:

    Reallocated_Sector_Ct
    Reported_Uncorrect
    Current_Pending_Sector
    Offline_Uncorrectable


    SMART Error Log Version: 1
    No Errors Logged


    Good.


    SMART Self-test log structure revision number 1
    No self-tests have been logged. [To run self-tests, use: smartctl -t]


    Are you running tests periodically?


    David

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Eben King@21:1/5 to Chris Green on Sun Mar 2 21:50:01 2025
    On 3/2/25 14:46, Chris Green wrote:
    Anssi Saari <[email protected]> wrote:
    Eben King <[email protected]> writes:

    Normally I hibernate, and while it's hibernated, boot off a thumb drive
    and back up (either by partition or the whole drive) to a dedicated
    drive.  The idea is if my main drive takes a dump, I could replace it
    with the backup drive, boot, and be on my merry way.  After the backup
    has completed, I resume and it's right where I left off.

    So you actually back up the hibernated / partition? Is that really a
    sound backup strategy? Seems risky to me but if it works I guess it's
    fine.

    With modern systems booting so fast I wonder why anyone bothers with hibernate or sleep.

    I would just shut down, except that certain sites I frequent (*ahem*
    youtube) insist on this "infinite scrolling" thing. If you're two dozen
    "end"s into a channel's back catalog and you restart Firefox, it doesn't
    start where you were, it starts you at the top. If they had real pages
    with separate URLs for each one, then it'd be a non-issue. Reddit does
    it too, but at least for that there's a browser plugin that gives you
    the option of disabling it.

    --
    History proves again and again how Nature points up the folly of men.
    -- Godzilla

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Charles Curley@21:1/5 to Eben King on Mon Mar 3 01:00:01 2025
    On Sun, 2 Mar 2025 12:51:03 -0500
    Eben King <[email protected]> wrote:

    I smell a rat. I wonder if the corruption is because your hard
    drive is failing. I would first boot to a live CD and run smartctl
    tests on it.

    At the end of this message.

    Nothing there jumps out at me, but maybe someone else will spot
    something. You might go ahead and do a test ("smartctl -t").



    How did you do the backup? Per file (e.g. rsnapshot or amanda), or
    per block device (e.g. dd if=/dev/sda1 of=…)?


    Block device.  If I've resize / moved a partition since the last
    backup I'll do a full (dd if=/dev/sda of=/dev/sdc), if not I'll do it
    by partition (dd if=/dev/sdaX of=/dev/sdcX).  Since only maybe 70% of
    the drive is in partitions, it's faster that way.

    Ah. If you back up the partitions, you should be able to mount the
    images as loopback devices and recover from those. I guess from remarks
    you made elsewhere in this thread that that is what you have done.
    Diffing should identify the changes.

    I have no idea how to get at a disk image. I think I did it some ten
    years ago, but don't recall how.



    If you know the relevant files and have a per file backup, restoring
    them should be a matter of selecting the correct file.


    The most obnoxious errors are definitely under ~/.mozilla/firefox and probably ~/.mozilla/firefox/<profile>/extension* .

    diff is your friend.


    I am assuming that the corruption is all in /home and that it is
    included in your backups. If either one of those is false, you may
    be in deep yogurt.


    Yeah, I don't know how much I trust the backup of /home right now.

    Yeah. Sigh. This is why I run rsnapshot and amanda backups, and
    syncthing transfers to other machines.

    --
    Does anybody read signatures any more?

    https://charlescurley.com
    https://charlescurley.com/blog/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From George at Clug@21:1/5 to All on Mon Mar 3 07:20:01 2025
    On Monday, 03-03-2025 at 06:46 Chris Green wrote:
    Anssi Saari <[email protected]> wrote:
    Eben King <[email protected]> writes:

    Normally I hibernate, and while it's hibernated, boot off a thumb drive and back up (either by partition or the whole drive) to a dedicated drive.  The idea is if my main drive takes a dump, I could replace it with the backup drive, boot, and be on my merry way.  After the backup has completed, I resume and it's right where I left off.

    So you actually back up the hibernated / partition? Is that really a
    sound backup strategy? Seems risky to me but if it works I guess it's
    fine.

    With modern systems booting so fast I wonder why anyone bothers with hibernate or sleep.

    WHY? I can answer that for you. People often have several programs open, all working together, using various folders, files, etc. To set up such a working environment can take 5 to 15 minutes. To save time, people often just hibernate, so when they start
    working again, they can just restore from hibernate.

    I will use "pause" for test environments made up of virtual machines.

    However maybe like yourself, when I have finished using my primary (physical) computer, I power off even if it means I have to set up my working environment all over again, as I have experienced to many times I been unable to restore from hibernate when
    using Windows.

    Time and timing of packets are important for many of the things I do and for the running OS, hence pause/hibernate/sleep may cause issues.

    I just do not trust hibernate or sleep, even though I know many people use it daily.


    --
    Chris Green
    ·



    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anssi Saari@21:1/5 to Chris Green on Mon Mar 3 10:10:01 2025
    Chris Green <[email protected]> writes:

    With modern systems booting so fast I wonder why anyone bothers with hibernate or sleep.

    I guess my modern systems are different from yours, boot times are long.

    Also, in my life software has state and that is kept by sleep and
    hibernate. So when the computer wakes up, apps are in the same state as
    before, the same files open at the same location. Boot time doesn't
    really matter when starting up apps and opening files takes a lot
    longer.

    And yes, waking up from hibernate isn't particularly fast with modern
    systems but it's also a very low power mode which becomes relevant with
    a laptop.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dan Purgert@21:1/5 to Eben King on Mon Mar 3 11:10:01 2025
    On Mar 02, 2025, Eben King wrote:
    [...]
    ID# ATTRIBUTE_NAME��������� FLAG���� VALUE WORST THRESH TYPE UPDATED� WHEN_FAILED RAW_VALUE
    � 1 Raw_Read_Error_Rate���� 0x000f�� 082�� 064�� 006��� Pre-fail
    Always������ -������ 146369262

    146 million read-errors.
    � 7 Seek_Error_Rate�������� 0x000f�� 084�� 060�� 045��� Pre-fail
    Always������ -������ 232382570

    230 million seek errors
    � 9 Power_On_Hours��������� 0x0032�� 093�� 093�� 000��� Old_age
    Always���� -������ 6346h+20m+46.297s

    ~9 years on-time

    195 Hardware_ECC_Recovered� 0x001a�� 082�� 064�� 000��� Old_age
    Always����� -������ 146369262

    Well, at least those read errors were all corrected ;)

    None of the first three bits are absolute proof that the drive is going,
    but they're certainly cause for suspicion.

    --
    |_|O|_|
    |_|_|O| Github: https://github.com/dpurgert
    |O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

    -----BEGIN PGP SIGNATURE-----

    iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmfFfmoACgkQbWVw5Uzn KGAkyg/+Ij//f0ajFBvE1roXlLEBif5E/ZyGna4sgzneBScq9cjLfLUABEdHobPd dV7fgfcjsp740ijGC/xcPOadBkxRiPPuJrbcVH7qAW06+vHExNa9GzcgcoBrtkn7 N72+9vrFYiC6wUVx7eUjpX6iDT/joadaeHxLmv0n4mlsW1HoK4tXXvnBmzTbZPu5 7zJCYDROI3pes5tPN2ilz5IpKOe8GfneL6OCO0WKM5SjDAasaGDYDouu1alCdAyt 0BzhI+wRXTVKzCxq4Nm1YuKGFnP3dEYifasCFiBlBsBKFebkCZt58WQcRpJ0x1ta r2Mp53ONrzbaVVcsjvc3ps3aQ2Lw/WUkmLFFOzDzDNsSSgcqQwl+JdYIaMIBAsdS DgJiJtQ+ginACnENY8PgBn6Xiptsqn40sDHM9YaJbM4dAQsreou905jPdrzl5r4m G2W8uZAyigorzvjqW5VV+KgCkKMtju2lZjD6fdJnqw+f8gfsRDYcHgocsY2gxsr0 hcowfEPj9QVrkcqW5AKqYwhZuNVXdmF0f4w2/Iea6A1CyHE65Wkyhu3rTaU7Zs8T pr+4/OL8YF0bh8Rlw3dRgc0iPtxG1FMhiGNGU/pCGO/hN4RtaSDD5ZWUH04H7kYF vu3aqFi+4K/GVsabiI4GSAlFTKwl+sTCVRZIGeFdJj8Aq7PMyrU=
    =ZgBi
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Us
  • From Eben King@21:1/5 to Dan Purgert on Mon Mar 3 19:40:01 2025
    On 3/3/25 05:03, Dan Purgert wrote:
    Well, at least those read errors were all corrected ;)

    None of the first three bits are absolute proof that the drive is going,
    but they're certainly cause for suspicion.

    Is there a way of seeing how many spare blocks are left?

    The "space at the end of a line" worked, so I'm going to try a signature
    and see how it works.

    --
    "First, Do No Harm.

    Always do harm second, after the user has proven that they earned it."
    -- ObscureRefence on reddit

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dan Ritter@21:1/5 to Eben King on Tue Mar 4 00:10:01 2025
    Eben King wrote:


    On 3/3/25 05:03, Dan Purgert wrote:
    Well, at least those read errors were all corrected ;)

    None of the first three bits are absolute proof that the drive is going, but they're certainly cause for suspicion.

    Is there a way of seeing how many spare blocks are left?

    Spinning disks don't do that (these days). SSDs do, because they
    know they have a limited write lifetime.

    If there's data on that disk you value, back it up now.

    -dsr-

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Christensen@21:1/5 to Dan Purgert on Tue Mar 4 03:10:01 2025
    On 3/3/25 02:03, Dan Purgert wrote:
    On Mar 02, 2025, Eben King wrote:
    [...]
    ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE UPDATED
    WHEN_FAILED RAW_VALUE
      1 Raw_Read_Error_Rate     0x000f   082   064   006    Pre-fail
    Always       -       146369262

    146 million read-errors.
      7 Seek_Error_Rate         0x000f   084   060   045    Pre-fail
    Always       -       232382570

    230 million seek errors
      9 Power_On_Hours          0x0032   093   093   000    Old_age
    Always     -       6346h+20m+46.297s

    ~9 years on-time


    6346 hours / 24 hours/day = 264.42 days

    6346 hours / 24 hours/day / 365.2425 days/year = 0.72395 years


    195 Hardware_ECC_Recovered  0x001a   082   064   000    Old_age
    Always      -       146369262

    Well, at least those read errors were all corrected ;)

    None of the first three bits are absolute proof that the drive is going,
    but they're certainly cause for suspicion.


    I have been watching my HDD's and SSD's with smartctl(8) intermittently
    over the years, and am still confused. HDD's with "bad" statistics can
    still work, while failed drives can produce statistics above the "bad"
    drive values (!). It's a conundrum.


    I have always wondered if the decimal numbers in the smartctl(8)
    "RAW_VALUE" column are actual event counts, or a decimal representation
    of some binary bit field whose correct interpretation only the
    manufacturer knows (?).


    I typically look at the "VALUE" column, as it usually represents an
    integer percentage that starts at 100 (%) and diminishes towards 0 (%)
    as the drive degrades. That said, I have seen starting values of 120,
    200, and possibly 255 (?). So, again, only the manufacturer knows.


    I own about a dozen and a half 2.5" SSD's, and one M.2 PCIe NVMe SSD.
    None have failed (yet). AIUI, SDD's go from working to choppy to brick
    in rapid succession.


    I awoke one night to the smell of fried electronics. I quickly found
    the source -- a USB flash drive connected to a MacBook Pro as a Time
    Machine backup drive. I did a little testing on a Debian machine the
    next day. The drive was marginally readable at a very slow transfer
    rate (timeouts?). I did not want to damage my computer, so I smashed
    the USB flash drive and recycled the husk.


    David

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nicolas George@21:1/5 to All on Wed Mar 5 15:20:01 2025
    Greg (HE12025-03-05):
    I thought the whole point of running the SMART tests was to detect a failing disk, so color me confused.

    Maybe apply some common sense.

    If you have a device that is on the verge of breaking down, using it intensively is likely to push it over the edge, of course.

    The point of the test is: if it succeeds, you can reasonably hope that
    the device will continue working for some time.

    Regards,

    --
    Nicolas George

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stefan Monnier@21:1/5 to All on Wed Mar 5 16:40:01 2025
    I thought the whole point of running the SMART tests was to detect
    a failing disk, so color me confused.

    If we knew how to detect a failing (as opposed to failed) disk, then
    things would be easy. SMART is an attempt to provide relevant
    information, but that's all. AFAIK, it's still "the best we have", but
    it's not a reliable way to answer the question (I'm not even sure the
    question is well-defined, to be honest).


    Stefan

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Eben King@21:1/5 to Max Nikulin on Wed Mar 5 18:10:02 2025
    On 3/4/25 21:59, Max Nikulin wrote:

    In this particular case I do not think it is a drive failure. I suspect mounting /home was a mistake.

    Indeed. "-ro" is not read only when a journal is in play.

    Booting a live image may destroy hibernation data since live system may
    mount the same swap partition and reinitialize it. Eben, have you find a reliable way to avoid swap reuse?

    The environment from which I do the backups is system-rescue.org .
    AFAICT it doesn't mount anything automatically. I don't generally mount
    a source partition, but this time I needed some info from it.

    My impression is that some device drivers do not save complete state
    during hibernation, so booting other OS may cause some problems after resuming.

    Yup. In fact sometimes just hibernate / resume is enough to cause
    failure. Thankfully all my devices use well-behaved drivers.

    I considered it as a reason why Windows does not allow booting
    other OS when it is hibernated (at least with BIOS namely shutdown was required, I am unsure concerning UEFI).

    Huh, I was not aware.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Wright@21:1/5 to David Christensen on Thu Mar 6 07:00:01 2025
    On Mon 03 Mar 2025 at 17:55:59 (-0800), David Christensen wrote:

    I have always wondered if the decimal numbers in the smartctl(8)
    "RAW_VALUE" column are actual event counts, or a decimal
    representation of some binary bit field whose correct interpretation
    only the manufacturer knows (?).

    One where that is true is 188, Command_Timeout. I don't think I recall
    seeing any others.

    kirk:188 Command_Timeout -O--CK 100 096 000 - 137441116198 '0x2000210026' kirk:188 Command_Timeout -O--CK 100 096 000 - 154621313067 '0x240026002b' kirk:188 Command_Timeout -O--CK 100 096 000 - 167506411567 '0x270029002f' kirk:188 Command_Timeout -O--CK 100 096 000 - 167506411569 '0x2700290031' lulu:188 Command_Timeout -O--CK 100 099 000 - 12885098499 '0x300030003' toto:188 Command_Timeout -O--CK 100 099 000 - 8590065705 '0x200020029'

    Some people on the list have reported raw value triples, but all the
    singleton values that I've encountered have decomposed to simple hex
    triples like those (of my disks) above.

    I have no idea what they mean.

    I typically look at the "VALUE" column, as it usually represents an
    integer percentage that starts at 100 (%) and diminishes towards 0 (%)
    as the drive degrades. That said, I have seen starting values of 120,
    200, and possibly 255 (?). So, again, only the manufacturer knows.

    I've read that 254 is the maximum. Presumably 255 has some reserved significance.

    Cheers,
    David.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dan Purgert@21:1/5 to David on Fri Mar 7 01:50:01 2025
    On Mar 07, 2025, David wrote:
    On Mon, 3 Mar 2025 at 10:03, Dan Purgert <[email protected]> wrote:
    On Mar 02, 2025, Eben King wrote:

    [...]
    ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
    1 Raw_Read_Error_Rate 0x000f 082 064 006 Pre-fail
    Always - 146369262

    146 million read-errors.
    7 Seek_Error_Rate 0x000f 084 060 045 Pre-fail
    Always - 232382570

    230 million seek errors
    9 Power_On_Hours 0x0032 093 093 000 Old_age
    Always - 6346h+20m+46.297s

    ~9 years on-time

    195 Hardware_ECC_Recovered 0x001a 082 064 000 Old_age
    Always - 146369262

    Well, at least those read errors were all corrected ;)

    None of the first three bits are absolute proof that the drive is going, but they're certainly cause for suspicion.

    I see no cause for concern in that data.

    The wikipedia page [1] regarding "1 Raw_Read_Error_Rate" says:
    The raw value has different structure for different vendors and is often
    not meaningful as a decimal number. For some drives, this number
    may increase during normal operation without necessarily signifying errors.

    I've never seen spinning rust just increase read-errors for no reason,
    but since they were all ECC corrected, it's less concerning.
    [...]
    Why do you write that the "9 Power_On_Hours" data represents
    "~9 years on-time"? It looks to me that it says 6346 hours.
    There are 365 * 24 = 8760 hours / year.
    So 6346 hours is less than one year.

    Yeah, that's my bad, I read it as 63k hours.


    --
    |_|O|_|
    |_|_|O| Github: https://github.com/dpurgert
    |O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

    -----BEGIN PGP SIGNATURE-----

    iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmfKQKkACgkQbWVw5Uzn KGAeOg/8DS0pXy0SEzTrRKWxy+/lm3rDbncKMcKLatqM2P9qFnY5Na1v7GCvxsjG p04MCApXLwL63fR5QLKhgH7kFbRDMOS5W3/LEJicvK5KhNNUMiqNcJRo/nVxSruw nYMRiarV90sSkXCVqCMFMN+ordWn2bRGcFecuvWwvGkRs/q3kepBzBt/OHUNsjCi deg+naxg3lsxIcNNfS971/Gld+zdpXjq4g/p1lW1Dwrajs4w/KaDE8oqki0iv5mv OOJYmki3rA1rNLshHAfEc+Wcc/qwY2g7K4tUtLyIoaUCgL+qqs8T3i9Zd8kU8+ME cTr//IqoqjMAV214/Oir0+wlm+cbJ5uqJG0jzL6bZLO65MSm79quATOzI6rV2cbb 2EOUST5h0BUEBgkeTIZcmyKSVKFpSAkXIU9Gd7XYylLCjvbL9rmbXgajKFMu5POH pw0sUVJJcgKqL82LhtD1/e1rTLyMjL8nxJqhY9fHokaQDM5Toj8CNqiNJco7Z+xY 4XRJ4tWo4WFAQ2AbqZ4B9a+egpS8OtXnnEYGojM/jswXs3q6yAyBEVKOUWeDlTlh 7RIzoqwSmrvsKwk4HQV1qnKMHqJ0K+Dx4G4HswLy/BF3+EdFTQKzBdy/TdOH58nN 0IK+n6CdMCWbaORzohv4nslPsR3wHEGtGfsQcdA1s2fdyPKyfNU=
    =MlqA
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Us
  • From Christopher David Howie@21:1/5 to Anssi Saari on Sun Mar 9 06:50:01 2025
    On 3/2/25 2:23 PM, Anssi Saari wrote:
    So you actually back up the hibernated / partition? Is that really a
    sound backup strategy?

    It is effectively like yanking the power cord and then taking a backup. (Effects of the voltage dropping on the storage controller/disk are
    another matter, but in that regard hibernation is *safer* than yanking
    the power.) Assuming the filesystem can recover from a power cut, it
    can recover from this situation as well.

    Indeed, I use this approach to backup production databases. Databases
    are, in many ways, like filesystems of their own, and any database with
    some kind of a journal can be backed up this way provided you have a way
    to create an atomic snapshot of the filesystem (LVM snapshots, btrfs
    snapshots, etc.).

    Anything that semantically looks identical to "the machine suddenly
    powered off" is safe provided the data structure being backed up is
    designed to recover from that scenario. ext4 with a journal certainly qualifies.

    --
    Chris Howie
    http://www.chrishowie.com
    http://en.wikipedia.org/wiki/User:Crazycomputers

    If you correspond with me on a regular basis, please read this document: http://www.chrishowie.com/email-preferences/

    PGP fingerprint: 2B7A B280 8B12 21CC 260A DF65 6FCE 505A CF83 38F5

    ------------------------------------------------------------------------
    IMPORTANT INFORMATION/DISCLAIMER

    This document should be read only by those persons to whom it is
    addressed. If you have received this message it was obviously addressed
    to you and therefore you can read it.

    Additionally, by sending an email to ANY of my addresses or to ANY
    mailing lists to which I am subscribed, whether intentionally or
    accidentally, you are agreeing that I am "the intended recipient," and
    that I may do whatever I wish with the contents of any message received
    from you, unless a pre-existing agreement prohibits me from so doing.

    This overrides any disclaimer or statement of confidentiality that may
    be included on your message.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Christopher David Howie@21:1/5 to David Christensen on Sun Mar 9 06:50:01 2025
    On 3/2/25 2:35 PM, David Christensen wrote:
    The "norecovery" option for mount(8) seems like a dangerous design
    choice.  "readonly" is supposed to mean "do not write to disk".  I must remember that land mine if and when I want to do forensic work.

    To be fair, the first step of forensic work is "make an image of the
    drive and save it somewhere read-only." This way if you attempt to
    mount the image without norecovery, it barks at you because the
    underlying medium is read-only.

    You then work either with copies of the image. (Or thin layered images
    using the original as a backing image, which will redirect writes to the
    higher layer, leaving the original image untouched. Semantically the
    same as making a copy but without wasting a bunch of space.)

    --
    Chris Howie
    http://www.chrishowie.com
    http://en.wikipedia.org/wiki/User:Crazycomputers

    If you correspond with me on a regular basis, please read this document: http://www.chrishowie.com/email-preferences/

    PGP fingerprint: 2B7A B280 8B12 21CC 260A DF65 6FCE 505A CF83 38F5

    ------------------------------------------------------------------------
    IMPORTANT INFORMATION/DISCLAIMER

    This document should be read only by those persons to whom it is
    addressed. If you have received this message it was obviously addressed
    to you and therefore you can read it.

    Additionally, by sending an email to ANY of my addresses or to ANY
    mailing lists to which I am subscribed, whether intentionally or
    accidentally, you are agreeing that I am "the intended recipient," and
    that I may do whatever I wish with the contents of any message received
    from you, unless a pre-existing agreement prohibits me from so doing.

    This overrides any disclaimer or statement of confidentiality that may
    be included on your message.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Eben King@21:1/5 to David Christensen on Sun Mar 9 14:30:01 2025
    On 3/2/25 14:35, David Christensen wrote:

    At this point, I am uncertain if the /home ext4 file systems are correct
    on either the OS disc or the copied image disc (?).

    I did a "fsck -f" on each filesystem. Many had no errors, most of the
    rest were just "this inode is too wide". So they're all correct _now_,
    and I'll back up again next weekend.

    The "norecovery" option for mount(8) seems like a dangerous design
    choice.  "readonly" is supposed to mean "do not write to disk".

    Yeah, that's what I thought too.

    I must
    remember that land mine if and when I want to do forensic work.


    eben@cerberus:/$ sudo smartctl -a /dev/sda
    smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.0-31-amd64] (local
    build)
    Copyright (C) 2002-22, Bruce Allen, Christian Franke,
    www.smartmontools.org

    === START OF INFORMATION SECTION ===
    Model Family:     Seagate BarraCuda 3.5 (SMR)
    Device Model:     ST2000DM008-2UB102


    AIUI SMR does not work well for OS (e.g. /tmp, swap) and general-purpose (e.g. /home) disks that see frequent small random write workloads.  I
    prefer small high-quality 2.5" SSD's (Intel SSD 520 Series 60 GB) for my
    OS and /home disks, and put my bulk data on a file server.  I would re- purpose that HDD for images -- CMR should be okay for large sequential
    write workloads.

    ?MR=Shielded / Conventional Magnetic Recording? How do I tell a priori
    which drives are SMR and which are CMR?

    SMART Self-test log structure revision number 1
    No self-tests have been logged.  [To run self-tests, use: smartctl -t]

    Are you running tests periodically?

    I haven't been, but perhaps I should add that to my after-backup routine.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Christopher David Howie@21:1/5 to Eben King on Sun Mar 9 14:50:01 2025
    On 3/9/25 9:26 AM, Eben King wrote:
    The "norecovery" option for mount(8) seems like a dangerous design
    choice.  "readonly" is supposed to mean "do not write to disk".

    Yeah, that's what I thought too.

    "readonly" means "don't allow the contents of the filesystem to be
    changed," e.g. attempts to alter files by userspace programs are
    rejected. It doesn't mean the kernel won't write to the device.
    mount(8) even documents this explicitly:

    Note that, depending on the filesystem type, state and kernel
    behavior, the system may still write to the device. For example,
    ext3 and ext4 will replay the journal if the filesystem is dirty. To
    prevent this kind of write access, you may want to mount an ext3 or
    ext4 filesystem with the ro,noload mount options or set the block
    device itself to read-only mode, see the blockdev(8) command.
    This doesn't seem like "readonly does the wrong thing" so much as "you
    should know what things do before you use them."

    --
    Chris Howie
    http://www.chrishowie.com
    http://en.wikipedia.org/wiki/User:Crazycomputers

    If you correspond with me on a regular basis, please read this document: http://www.chrishowie.com/email-preferences/

    PGP fingerprint: 2B7A B280 8B12 21CC 260A DF65 6FCE 505A CF83 38F5

    ------------------------------------------------------------------------
    IMPORTANT INFORMATION/DISCLAIMER

    This document should be read only by those persons to whom it is
    addressed. If you have received this message it was obviously addressed
    to you and therefore you can read it.

    Additionally, by sending an email to ANY of my addresses or to ANY
    mailing lists to which I am subscribed, whether intentionally or
    accidentally, you are agreeing that I am "the intended recipient," and
    that I may do whatever I wish with the contents of any message received
    from you, unless a pre-existing agreement prohibits me from so doing.

    This overrides any disclaimer or statement of confidentiality that may
    be included on your message.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [email protected]@21:1/5 to Eben King on Sun Mar 9 15:00:01 2025
    On Sun, Mar 09, 2025 at 09:26:07AM -0400, Eben King wrote:


    On 3/2/25 14:35, David Christensen wrote:

    [...]

    AIUI SMR does not work well for OS [...]

    ?MR=Shielded / Conventional Magnetic Recording? How do I tell a priori
    which drives are SMR and which are CMR?

    Shingled magnetic recording [1]. You gain write density at the cost of randomness of writes.

    Cheers

    [1] https://en.wikipedia.org/wiki/Shingled_magnetic_recording
    --
    t

    -----BEGIN PGP SIGNATURE-----

    iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZ82dFwAKCRAFyCz1etHa Rm2iAJ9n7g7Y720G0oeeZdndJKvog9b0LwCeIsfQ+fAkco/q0tSGmaHqLVhricQ=
    =mK7S
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dan Ritter@21:1/5 to Eben King on Sun Mar 9 16:30:02 2025
    Eben King wrote:


    === START OF INFORMATION SECTION ===
    Model Family:     Seagate BarraCuda 3.5 (SMR)
    Device Model:     ST2000DM008-2UB102


    AIUI SMR does not work well for OS (e.g. /tmp, swap) and general-purpose (e.g. /home) disks that see frequent small random write workloads.  I prefer small high-quality 2.5" SSD's (Intel SSD 520 Series 60 GB) for my
    OS and /home disks, and put my bulk data on a file server.  I would re- purpose that HDD for images -- CMR should be okay for large sequential write workloads.

    ?MR=Shielded / Conventional Magnetic Recording? How do I tell a priori
    which drives are SMR and which are CMR?

    Shingled, not shielded.

    The drive manufacturer is supposed to tell you whether you are
    buying a CMR or SMR spinning disk (or other weird tech, like
    PMR or HAMR or...) and most of them do.

    But not all of them, and not always in an obvious way.

    The only such tech still on the market that people generally
    ought to avoid is SMR.

    -dsr-

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Christensen@21:1/5 to Christopher David Howie on Sun Mar 9 19:40:02 2025
    On 3/8/25 21:40, Christopher David Howie wrote:
    On 3/2/25 2:35 PM, David Christensen wrote:
    The "norecovery" option for mount(8) seems like a dangerous design
    choice.  "readonly" is supposed to mean "do not write to disk".  I
    must remember that land mine if and when I want to do forensic work.

    To be fair, the first step of forensic work is "make an image of the
    drive and save it somewhere read-only."  This way if you attempt to
    mount the image without norecovery, it barks at you because the
    underlying medium is read-only.

    You then work either with copies of the image.  (Or thin layered images using the original as a backing image, which will redirect writes to the higher layer, leaving the original image untouched.  Semantically the
    same as making a copy but without wasting a bunch of space.)


    AIUI the ideal approach for forensics is to ddrescue(1) the source disk
    to a known good, identical disk, and then work on the copy.


    David

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Christensen@21:1/5 to Eben King on Sun Mar 9 20:10:01 2025
    On 3/9/25 06:26, Eben King wrote:
    On 3/2/25 14:35, David Christensen wrote:
    AIUI SMR does not work well for OS (e.g. /tmp, swap) and general-purpose
    (e.g. /home) disks that see frequent small random write workloads.  I
    prefer small high-quality 2.5" SSD's (Intel SSD 520 Series 60 GB) for my
    OS and /home disks, and put my bulk data on a file server.  I would re-
    purpose that HDD for images -- CMR should be okay for large sequential
    write workloads.


    Oops -- that should have been "SMR should be okay for large sequential
    write workloads."


    I tried to shop carefully and believe all my HDD's are CMR. But this
    strategy only works up to certain sizes -- I believe the largest HDD's
    are SMR or something even more sophisticated.


    ?MR=Shielded / Conventional Magnetic Recording?  How do I tell a priori which drives are SMR and which are CMR?


    STFW I see:

    https://www.seagate.com/products/cmr-smr-list/

    https://blog.westerndigital.com/wd-red-nas-drives/

    https://toshiba.semicon-storage.com/ap-en/company/news/news-topics/2020/04/storage-20200428-1.html


    When making a disk drive purchase, I recommended researching the exact
    model(s) you are considering.


    SMART Self-test log structure revision number 1
    No self-tests have been logged.  [To run self-tests, use: smartctl -t] >>
    Are you running tests periodically?

    I haven't been, but perhaps I should add that to my after-backup routine.


    My SOHO file server runs 24x7, so I try to run SMART tests every month
    or two. I try to test the rest of my disks quarterly to semi-annually.


    I have glanced at smartd(8), but have yet to try it because it seems to
    prefer sending reports via e-mail (?). I have yet to figure out how
    fetch root mail messages from my daily driver mail client (Thunderbird).
    My WAG is that I need to install an IMAP server on each machine whose
    root mail I want to read (?).


    David

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Christensen@21:1/5 to Christopher David Howie on Sun Mar 9 21:40:01 2025
    On 3/9/25 06:48, Christopher David Howie wrote:
    On 3/9/25 9:26 AM, Eben King wrote:
    The "norecovery" option for mount(8) seems like a dangerous design
    choice.  "readonly" is supposed to mean "do not write to disk".

    Yeah, that's what I thought too.

    "readonly" means "don't allow the contents of the filesystem to be
    changed," e.g. attempts to alter files by userspace programs are
    rejected.  It doesn't mean the kernel won't write to the device.
    mount(8) even documents this explicitly:

    Note that, depending on the filesystem type, state and kernel
    behavior, the system may still write to the device. For example,
    ext3 and ext4 will replay the journal if the filesystem is dirty. To
    prevent this kind of write access, you may want to mount an ext3 or
    ext4 filesystem with the ro,noload mount options or set the block
    device itself to read-only mode, see the blockdev(8) command.
    This doesn't seem like "readonly does the wrong thing" so much as "you
    should know what things do before you use them."


    When the machines are to serve humans, sometimes the design must favor
    human psychology (e.g. imperfection) over technical purity (e.g.
    perfection):

    - What to name things [1].

    - "The principle of least surprise" [2].

    - "Keep it simple, stupid!" (KISS) [3].

    - "Do what I mean" (DWIM) [4].


    Now I am curious what "readonly" means to my FreeBSD systems with UFS
    and ZFS.


    David



    [1] https://martinfowler.com/bliki/TwoHardThings.html

    [2] https://en.wikipedia.org/wiki/Principle_of_least_astonishment

    [3] https://en.wikipedia.org/wiki/KISS_principle

    [4] https://en.wikipedia.org/wiki/DWIM

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael Stone@21:1/5 to David Christensen on Sun Mar 9 23:00:01 2025
    On Sun, Mar 09, 2025 at 12:04:10PM -0700, David Christensen wrote:
    I have glanced at smartd(8), but have yet to try it because it seems
    to prefer sending reports via e-mail (?).

    It's highly configurable. It also logs to syslog, and mails can be
    disabled entirely or replaced by some other scripted function.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Charles Curley@21:1/5 to David Christensen on Sun Mar 9 22:30:01 2025
    On Sun, 9 Mar 2025 12:04:10 -0700
    David Christensen <[email protected]> wrote:

    I have glanced at smartd(8), but have yet to try it because it seems
    to prefer sending reports via e-mail (?). I have yet to figure out
    how fetch root mail messages from my daily driver mail client
    (Thunderbird). My WAG is that I need to install an IMAP server on
    each machine whose root mail I want to read (?).

    What I do is use postfix to send all of my machines' emails to one user
    on one machine. I have an imap server (dovecot) for that user, and an appropriate account in clawsmail. Once you get it set up it works
    nicely.

    The only exception to that is laptops and their virtual machines; their
    mail goes to the laptop.

    --
    Does anybody read signatures any more?

    https://charlescurley.com
    https://charlescurley.com/blog/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Christensen@21:1/5 to Michael Stone on Sun Mar 9 23:50:01 2025
    On 3/9/25 14:50, Michael Stone wrote:
    On Sun, Mar 09, 2025 at 12:04:10PM -0700, David Christensen wrote:
    I have glanced at smartd(8), but have yet to try it because it seems
    to prefer sending reports via e-mail (?).

    It's highly configurable. It also logs to syslog, and mails can be
    disabled entirely or replaced by some other scripted function.


    My process is something like:

    # cd /hardware/manufacturer/model/serial

    # smartctl -t long /dev/disk/by-id/ata-model-serial

    # # wait until test is done

    # smartctl -x /dev/disk/by-id/ata-model-serial > smartctl.out

    # cvs commit


    Do you know of a "howto" URL that describes enough of the scripted functionality of smartd(8) that I could achieve the above?


    David

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Christensen@21:1/5 to Charles Curley on Sun Mar 9 23:40:01 2025
    On 3/9/25 14:28, Charles Curley wrote:
    On Sun, 9 Mar 2025 12:04:10 -0700
    David Christensen <[email protected]> wrote:

    I have glanced at smartd(8), but have yet to try it because it seems
    to prefer sending reports via e-mail (?). I have yet to figure out
    how fetch root mail messages from my daily driver mail client
    (Thunderbird). My WAG is that I need to install an IMAP server on
    each machine whose root mail I want to read (?).

    What I do is use postfix to send all of my machines' emails to one user
    on one machine. I have an imap server (dovecot) for that user, and an appropriate account in clawsmail. Once you get it set up it works
    nicely.

    The only exception to that is laptops and their virtual machines; their
    mail goes to the laptop.

    Do you know the URL of a "howto" document that describes how to set that up?


    David

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Charles Curley@21:1/5 to David Christensen on Mon Mar 10 05:20:01 2025
    On Sun, 9 Mar 2025 15:36:42 -0700
    David Christensen <[email protected]> wrote:

    Do you know the URL of a "howto" document that describes how to set
    that up?

    No, sorry. I put that together ad hoc over several years.

    --
    Does anybody read signatures any more?

    https://charlescurley.com
    https://charlescurley.com/blog/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)