Wow, that was very harsh AND very wrong. All storage devices die eventually, that's why we have backups (and RAID, off-site replication, etc). HDDs and SSDs are the same in this respect.
SSDs do NOT die just from repeated writes to the same sector: this can happen with raw flash cells, but SSDs are NOT that, they all include complex logic for wear leveling, and it works very well in practice. As SSDs grow larger, they can withstand more writes, as wear leveling spreads the wear over more flash cells. For datacenter use, SSDs are gaining more and more use cases as primary storage, and their reliability is getting ahead of HDDs: https://www.backblaze.com/blog/ssd-drive-stats-mid-2022-review/ Home users need not worry at all about SSD longevity. They just need to be ready for they drives to die, just like any storage device, and use backups. JM On Wed, Sep 27, 2023 at 3:26 PM Roberto Fastec <roberto.fas...@gmail.com> wrote: > > What an awful idea to encrypt data on an hardware accelerator > > SSD is everything but an affordable storage for keeping safely your data > > and as soon some cells will fail , and with LVM , the first ones will be > where LVM tables are sitting (and being heavily modified) .. you'll loose ALL > the data, because of the extents mechanism > > Nevertheless, if you got damaged just the cells where encryption keys are > written, again you loose everything > > Remember that the data must seat on the affordable hard disk drive. > > SSD is just an hardware accelerator, if of high quality (enterprise class) it > can be good as cache for RAID systems > > Man that has been advised, is half saved > > Kind regards > > R. > > Ottieni BlueMail per Android > Il giorno 27 set 2023, alle ore 11:58, Zdenek Kabelac > <zdenek.kabe...@gmail.com> ha scritto: >> >> Dne 27. 09. 23 v 1:10 Jean-Marc Saffroy napsal(a): >>> >>> Hi, >>> >>> On Tue, Sep 26, 2023 at 10:00 PM Zdenek Kabelac >>> <zdenek.kabe...@gmail.com> wrote: >>>> >>>> Yep typical usage is to encrypt underlying PV - and then create LVs and >>>> its >>>> snapshots on encrypted device. >>> >>> >>> Sure, I'd do that in other circumstances. >>> >>> But in my case it would just be a waste: I am replacing several disks >>> on a desktop computer with a single 2TB NVME SSD for everything. Only >>> /home needs to be encrypted, and it's tiny, like 100-200GB. Going >>> through encryption for most application I/Os would use CPU time and >>> increase latency with no benefit. >>> >>> So I prefer to manage available raw (un-encrypted) space with LVM. >>> >>> Now, I also need to do backups of /home, and that's why I want >>> snapshots. But that first layer of LVM would only show a snapshot of >>> an encrypted volume, and the backup job shouldn't have the passphrase >>> to decrypt the volume. >>> >>> Which is why I'm trying to find a way of doing snaphots of an "opened" >>> LUKS volume: this way, the backup job can do its job without requiring >>> a passphrase. >> >> >> well that's where you will considerably 'complicate' your life :) >> As you would need to 'orchestrace' this yourself with 'dmsetup' usage. >> >> running 'dmsetup suspend' on your home device, >> that taking a snapshot of your underlying LV. >> >> Here the usage of 'thin-pool' would possibly help a little bit - as you get a >> control over when a snapshot LV appears in your system. >> >> Once you have the snapshot created you 'resume' the top-level >> decrypted volume. >> >> Then if you want to access your snapshot - you create another 'crypto' device >> - unlock it again with your key - and it should work. >> >> But the level of complexity here is rather high - this it might be actually >> way easier to just 'partition' your device for 'encrypted' and unecrypted' >> parts and use 2 PVs for 2 VGs.... >> >>> But my tests don't tell me if there are other people doing similar >>> things on production systems, or if they are happy with the results. >>> Unusual setups tend to exhibit unusual bugs, and I am not super fond >>> of bugs in my storage systems. :-) >> >> >> Yep - people prefer simple rock solid solutions.... >> That's why the above describe scenarios is not really used.... >> As solving then all individual errors that may appear is far from being >> simple. >> >> >>> Just the one /home in my case, so no worse than prompting for the >>> passphrase for an entire disk. >> >> >> Every access to a snapshot needs then a new separate 'unlock'.. >> >>>> Speaking about snapshots - you should consider switching to 'thin-pools' >>>> for >>>> far better performance... >>> >>> >>> I only need snapshots for backups: once a day, create a snapshot, >>> mount it, do a file-level incremental backup, unmount it, delete it. >>> >>> Would the thin-pools make a difference in this case? >> >> >> Well there are many ways how to skin a cat... >> I.e. check blk-archive https://github.com/jthornber/blk-archive >> >> Regards >> >> Zdenek >> >> ________________________________ >> >> linux-lvm mailing list >> linux-lvm@redhat.com >> https://listman.redhat.com/mailman/listinfo/linux-lvm >> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/ _______________________________________________ linux-lvm mailing list linux-lvm@redhat.com https://listman.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
