this post was submitted on 19 Apr 2024
889 points (98.8% liked)

linuxmemes

21263 readers
528 users here now

Hint: :q!


Sister communities:


Community rules (click to expand)

1. Follow the site-wide rules

2. Be civil
  • Understand the difference between a joke and an insult.
  • Do not harrass or attack members of the community for any reason.
  • Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
  • Bigotry will not be tolerated.
  • These rules are somewhat loosened when the subject is a public figure. Still, do not attack their person or incite harrassment.
  • 3. Post Linux-related content
  • Including Unix and BSD.
  • Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of sudo in Windows.
  • No porn. Even if you watch it on a Linux machine.
  • 4. No recent reposts
  • Everybody uses Arch btw, can't quit Vim, and wants to interject for a moment. You can stop now.

  • Please report posts and comments that break these rules!

    founded 1 year ago
    MODERATORS
     
    you are viewing a single comment's thread
    view the rest of the comments
    [–] [email protected] -1 points 6 months ago* (last edited 6 months ago) (1 children)

    If an app didn't manage to shut down in 90seconds, it is probably hanging and there will be "DaTa LoSs" no matter if you kill it after 2 seconds or after 90.


    Been running arch for over 5 years now.

    I track all my hours and for arch maintenance I've spent a grand total of ~41 hours (desktop + laptop and including sitting there and staring at the screen while an update is running). The top three longest sessions were:

    1. btrfs data rescue after I deleted a parent snapshot of my rollback (~20h)
    2. grub update (~2h)
    3. jdk update which was fucky (~30min)

    |

    It's about 8.2 hours per year (or ~10minutes per week) which is less than I had to spend on windows maintenance (~22h/y afair, about half of that time was manually updating apps by going to their website and downloading a newer version).

    Ubuntu also faired worse for me with two weekends of maintenance in a year (~32h), because I need the bleeding edge and some weird ass packages for work and it resulted in a frankenstein of PPAs and self built shit, which completely broke on every release upgrade.

    [–] [email protected] 3 points 6 months ago (1 children)

    btrfs data rescue after I deleted a parent snapshot of my rollback

    Can you expand a bit on that? I thought it didn't matter if you deleted parent snapshots because the extents required by the child would still be there.

    [–] [email protected] 1 points 6 months ago* (last edited 6 months ago) (1 children)

    Honestly, I have no idea why it went wrong or why it let me do that. Also my memory is a bit fuzzy since it's been a while, but as best I can remember what I did step by step:

    1. fuck around with power management configs
    2. using btrfs-assistant gui app, rolled back to before that
    3. btrfs-assistant created an additional snapshot, called backup something, I didn't really pay attention
    4. reboot, all seemed good
    5. used btrfs-list to take a look, the subvolume that was the current root / was a child of the aformentioned backup subvolume
    6. started btrfs-assistant and deleted the backup subvolume
    7. system suddenly read only
    8. reboot, still read only
    9. btrfs check said broken refs and some other errors,
    10. i tried to let btrfs check fix the errors, which made it worse, now I couldn't even mount the drive anymore because btrfs was completely borked
    11. used btrfs rescue, which got all files out onto an external drive successfully
    12. installed arch again and rsync the rescued files over the new install, everything works as before, all files are there
    [–] [email protected] 2 points 6 months ago

    btrfs check said broken refs and some other errors,

    Gotcha. That must have been a kernel bug (or hardware error), none of the userspace utilities could cause it unless they were trying to manipulate the block device directly, which would be really dumb. It's possible it wasn't even related to the subvolume manipulation.