• 0 Posts
  • 23 Comments
Joined 2 年前
cake
Cake day: 2023年7月2日

help-circle

  • If you’re worried enough to encrypt the drive, you shouldn’t be auto mounting it.

    This really depends on your threat model. If you are only concerned about the drive getting stolen, or wanting to keep the data on it private if you need to RMA the drive, mounting it automatically on boot with a key stored on the rootfs can be perfectly fine. If you are a journalist in a hostile country and protecting your sources from state level actors is a matter of life and death, then yeah, this would be woefully insufficient.











  • Micay stepped down as lead developer and foundation director. I’m not sure what role he has with the project currently, but it seems like he plans on leaving the project entirely, long term. I haven’t heard of any controversy since then. They’ve been hard at work and actually added support for Android Auto last month.


    • SLC -> Single-Level Cell, i.e. 1 bit per cell
    • MLC -> Multi-Level Cell, i.e. 2 bits per cell
    • TLC -> Triple-Level Cell, i.e. 3 bits per cell
    • QLC -> Quad-Level Cell, i.e. 4 bits per cell

    The more bits per cell you store, the more dense and therefore cheaper your flash chips can be for a give capacity. The downside is that it is slower and less reliable since you have to be able to write and read exponentially more voltage states per cell, e.g. 2 states for SLC, 4 states for MLC, 8 states for TLC, etc.



  • Scholars_Mate@lemmy.worldtoLinux@lemmy.mlSystemd timer unit
    link
    fedilink
    English
    arrow-up
    15
    ·
    edit-2
    2 年前

    the timer has no idea if it was triggered during last boot. It only has the context of “this” boot, so it will do it right after a reboot and set a timer to start the service again after a week of uptime.

    This is not correct. Persistent=true saves the last time the timer was run on disk. From the systemd.timer man page:

    Takes a boolean argument. If true, the time when the service unit was last triggered is stored on disk. When the timer is activated, the service unit is triggered immediately if it would have been triggered at least once during the time when the timer was inactive.

    OP needs to remove Requires=backup.service from the [Unit] section so it stops running it when it start the timer on boot.



  • Well, for one, it’s network attached storage. If it’s not present in the network for one reason or another, guess what, your OS doesn’t boot… or it errors during boot, depending on how the kernel was compiled and what switches your bootloader sends to the kernel during boot.

    Just use nofail in the fstab.

    Second, this is an easy way for malware to spread, especially if it’s set to run after user logon.

    If your fileshare is accessible to you, it is also accessible to malware running as your user. Mounting the share via a filemanager doesn’t change this.


  • USB 2 is 480 Mb/s, not 480 MB/s. 480 Mb/s is 60 MB/s, so the 500 MB/s from PCIe 2.0 x1 is quite a bit faster and is about the limit of what a SATA 3 interface could do. Also, sequential throughput isn’t nearly as important as most people think. Random IO, which NVMe drives excel at, will make a far more noticeable impact on real world performance.


  • I’ve been using PhotoPrism for the past couple of days and have really liked it.

    I was considering Immich, but the rapid development cycle turned me off of it for now. I don’t want to have to deal with keeping up with patch notes and potential breaking changes. Immich also seems more focused on photo backups from your phone, which isn’t quite what I wanted. PhotoPrism just let me upload all my existing photos on the web ui.

    I’d say give both a try. Both provide a docker-compose file, so you should be able to bring them up fairly quick.


  • I think the snapshot exists but is not mounted as a btrfs subvolume.

    Is it not listed when you try running btrfs subvolume list .? You might need to change the . to a path that is on the array.

    from the research I did, the @docker folder at the volume root holds all the volumes, images, subvolumes, etc. and I did copy that over.

    Copying over the files wouldn’t be enough. You would actually need to create the subvolumes, e.g. btrfs subvolume create subvolume_name.

    Do you happen to know if I find the snapshot folder and download it, will there be anything recoverable? Or would it just be like, hashes and unintelligble stuff?

    Unfortunately, I am not familiar enough with how Synology does things, but a btrfs snapshot will just appear as normal directory with the files/directories in it. If Synology isn’t using btrfs for the snapshoting, I’m not sure what you’ll find.