Re: SDD partitioning and allocations
On 7/10/25 04:07, songbird wrote:
hello all, some questions at last... it's been a while. :)
I was able to get some SSD replacements and want to add them
to my existing setup,
Be sure to do a secure erase before you put the SSD's into service:
https://en.wikipedia.org/wiki/Secure_Erase#Secure_erase
but in previous years I recall that there
was some recommendation to leave some part of the SSD unallocated
and not formatted as part of a file system so any parts that
failed as bad blocks or wore out could be allocated from these
unused areas.
When trying to see what current recommendations are for setting
up SSDs I see no mentions of this at all? Has this changed? I've
been trying to get caught up and seeing nothing specific to EXT4
or Linux for SSDs.
AIUI SSD over-provisioning combined with setting the discard flag in
fstab(5) provides maximum performance for write intensive workloads. If
you need that, I would suggest a dedicated SSD. For a typical graphical
desktop workload, I would not worry about over-provisioning; allocate
SSD space as needed.
I don't do encryption or raid.
Pretty much my current plan for one of the SSDs would be
to put an efi small partition(as I notice the current ones I have
hardly have anything on them even if they were allocated to be 1G)
so that I can copy my current setup to that but not waste the
space). The existing ones use 5M or even much less so perhaps 50M
will be enough allowing for future expansion? The rest of the
new drive will just be one large partition. It is not a heavily
used machine or setup but I do need more space for working on
the website and picture archives.
I do have both Grub and Refind installed (for some Grub updates
it will change my initial efi boot order so I have a script setup
to change it back when needed). Refind works and does exactly
what I want.
Because I do run Debian testing most of the time I also plan
on keeping my other partition where it boots stable going. I've
only needed it a few times but I like having it there. I'll
leave this on the smaller SSD along with the swap partition
(which is not frequently or heavily used).
I agree that 1 GB for the ESP seems like overkill, but I would rather
error too large than too small.
Rather than fighting the complexities of dual-boot/ multi-boot, I prefer
to install drive racks in my computers and to put each OS instance on
its own drive. This reduces the complexity to BIOS/UEFI Setup settings.
The 2nd new SSD will be for consolidating my backups (that are on
a smaller SSD at the moment plus also on an external drive that is
not used frequently - I don't trust it as it has been knocked off
the table but until it gives up entirely it is a backup that can't
be messed with as it is not mounted or powered on often).
I would use the small SSD for Debian and the second new SSD for data.
See below for backups.
I don't use the discard options on the mounts or filesystems
and also don't run fstrim automatically, I will eventually set
this up to run monthly. I ran it recently for the first time
after several years of use of the existing SSDs. I've not noticed
any decline in the existing SSD speeds, etc. at all but I'm also
not running too much that is demanding for performance.
I run fstrim(8) monthly on my Debian SSD's before taking an image.
Zeroes compress nicely and the drive will have plenty of erased blocks
for the next month.
I do like having multiple backups on the different SSDs just
in case one of them decides to fail on me. No signs of any
troubles so far.
songbird
For a single desktop, I would connect the external drive when making
backups, disconnect it when not, and store it near-site. It would be
best to buy another external drive and implement near-site/ off-site
rotation.
A related subject to consider is archiving -- burning backups to
write-once discs periodically -- CD-R, DVD-R, BD-R, DL, XL, etc..
David
Reply to: