Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[Michael Stone]

On Mon, Jan 03, 2022 at 08:51:59PM -0300, Jorge P. de Morais Neto wrote:

But doesn't Btrfs compression work with small blocks?

https://btrfs.wiki.kernel.org/index.php/Compression#Are_there_speed_penalties_when_doing_random_access_to_a_compressed_file.3F


Relatively small, which makes it fairly inefficient. But large enough 
that rewriting means writing much more than one (4k) block; what that 
means in terms of write amplification is highly workload dependent. 

There are good reasons that when file compression is expected to be 
significant, it is done at the application level. 


Fedora change proposal of Btrfs transparent compression by default
mentions increased flash-based media lifespan in the summary:

https://fedoraproject.org/wiki/Changes/BtrfsTransparentCompression#Summary


I understand that it says that, but it doesn't show its work and I'm 
skeptical that it's anything but cargo-cult repetition.

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[Jorge P . de Morais Neto]

Hi!

Em [2022-01-03 seg 10:03:08-0500], Michael Stone escreveu:

> On Mon, Jan 03, 2022 at 08:42:29AM -0300, Jorge P. de Morais Neto wrote:
>>Indeed I use such high compression to prolong SSD lifetime.
>
> This is probably misguided and useless at best, at worst you're causing 
> additional writes because compressed data is generally hard to modify in 
> place without rewriting substantial portions.

But doesn't Btrfs compression work with small blocks?

https://btrfs.wiki.kernel.org/index.php/Compression#Are_there_speed_penalties_when_doing_random_access_to_a_compressed_file.3F

Fedora change proposal of Btrfs transparent compression by default
mentions increased flash-based media lifespan in the summary:

https://fedoraproject.org/wiki/Changes/BtrfsTransparentCompression#Summary

> For reference, my main desktop which tracks debian unstable and gets
> pretty much constant updates, does package builds, etc., has after
> several years used...2% of its primary SSDs write capacity.  Most
> modern SSDs will never be used anywhere close to their limits before
> being discarded as functionally obsolete.  Just don't worry about it
> and focus on other things.

Thank you for the advice.  Indeed I should be a bit less obsessed with
certain details.  I at least dropped the idea of messing with swappiness
(as mentioned earlier in this thread) thanks to similar advice.  I have
a weakness for ricing which I must moderate.

Kind regards

-- 
- Many people hate injustice but few check the facts; this causes more
  injustice.  Ask me about 
- I am Brazilian.  I hope my English is correct and I welcome feedback.
- https://www.defectivebydesign.org
- https://www.gnu.org

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[Michael Stone]

On Mon, Jan 03, 2022 at 10:33:59AM -0500, Dan Ritter wrote:

Michael Stone wrote:

On Mon, Jan 03, 2022 at 08:42:29AM -0300, Jorge P. de Morais Neto wrote:
> Indeed I use such high compression to prolong SSD lifetime.

This is probably misguided and useless at best, at worst you're causing
additional writes because compressed data is generally hard to modify in
place without rewriting substantial portions. Concerns about SSD life are
generally overblown unless you've got really unusual usage patterns (in
which case compressing things is unlikely to make a difference).


SSDs don't modify in place. The compression is probably good for
overall bandwidth of I/O, depending on CPU utilization.


I'm aware of how SSDs work. The question is how much rewriting is 
triggered by altering a byte in a compressed file, and how that 
interacts with the SSD's erase blocks and SLC cache. In most cases the 
effects are probably negligable (at least as much as any possible 
improvement from using compression) but in pathological cases it might 
increase rather than decrease write amplification. 

Anyway, there may be reasons to want to use compression on a given 
device, but SSD longevity shouldn't be one of them.


In my experience it doesn't do much for performance because in places 
*where it matters* compression is usually being done at a higher level 
anyway, and much more efficiently. That said, it can help sometimes but 
it's going to be extremely application-dependent.



For reference, my main desktop which tracks debian unstable and gets pretty
much constant updates, does package builds, etc., has after several years
used...2% of its primary SSDs write capacity. Most modern SSDs will never be
used anywhere close to their limits before being discarded as functionally
obsolete. Just don't worry about it and focus on other things.


This is largely true on desktops and laptops, not so true on
servers.


And, of course, we're talking about a laptop.

If we were talking about servers it wouldn't generally be a runtime 
concern on a modern system if write volume is accounted for when 
provisioning--there are extremely long-lived SSDs, they just cost more. 
If you put commodity laptop HDs in a server and write literally hundreds 
of TBs per day to them they also tend to fail faster than higher grade 
HDs (just without the counter telling you when they'll stop) so that's 
not a novel concern to account for when designing a system. If you're 
running servers you should probably monitor SSD health, but that's not 
different in practical terms than monitoring SMART predictive failures 
for HDs and dealing with them as necessary. In reality, even with all 
the hand-wringing about SSD write limits, modern parts are much more 
reliable than HDs. Most of the bad experiences with SSDs that get so 
much attention (excepting bad batches, which can happen with anything) 
relate to devices many generations obsolete.

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[Dan Ritter]

Michael Stone wrote: 
> On Mon, Jan 03, 2022 at 08:42:29AM -0300, Jorge P. de Morais Neto wrote:
> > Indeed I use such high compression to prolong SSD lifetime.
> 
> This is probably misguided and useless at best, at worst you're causing
> additional writes because compressed data is generally hard to modify in
> place without rewriting substantial portions. Concerns about SSD life are
> generally overblown unless you've got really unusual usage patterns (in
> which case compressing things is unlikely to make a difference).

SSDs don't modify in place. The compression is probably good for
overall bandwidth of I/O, depending on CPU utilization.


> For reference, my main desktop which tracks debian unstable and gets pretty
> much constant updates, does package builds, etc., has after several years
> used...2% of its primary SSDs write capacity. Most modern SSDs will never be
> used anywhere close to their limits before being discarded as functionally
> obsolete. Just don't worry about it and focus on other things.

This is largely true on desktops and laptops, not so true on
servers.

-dsr-

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[Michael Stone]

On Mon, Jan 03, 2022 at 08:42:29AM -0300, Jorge P. de Morais Neto wrote:

Indeed I use such high compression to prolong SSD lifetime.


This is probably misguided and useless at best, at worst you're causing 
additional writes because compressed data is generally hard to modify in 
place without rewriting substantial portions. Concerns about SSD life 
are generally overblown unless you've got really unusual usage patterns 
(in which case compressing things is unlikely to make a difference).


For reference, my main desktop which tracks debian unstable and gets 
pretty much constant updates, does package builds, etc., has after 
several years used...2% of its primary SSDs write capacity. Most modern 
SSDs will never be used anywhere close to their limits before being 
discarded as functionally obsolete. Just don't worry about it and focus 
on other things.

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[Jorge P . de Morais Neto]

Em [2022-01-02 dom 23:38:48+], piorunz escreveu:

> On 02/01/2022 16:33, Jorge P. de Morais Neto wrote:
>> I am currently using compress-force=zstd:12 for the SSD and
>> compress=zstd:12 for both HDD (internal SATA and external USB3)¹.
>> Despite the strong compression level, performance is pretty good.  Yet,
>> when the system settles, I intend to reduce compression level to 9 or 6
>> (as you earlier recommended).  This should make performance even better,
>> while saving a lot of space because most data was compressed at
>> level 12.
>
> I run compress-force=zstd:6 on my fast PC, compress-force=zstd:3 on my
> server (to give it a bit more breathing space), and also same level 3 on
> my laptop. 12 is quite high for SSD, are you sure you not slowing down
> peak performance of your SSD by intense CPU usage? Or is it by design,
> to reduce number of writes to SSD?

Indeed I use such high compression to prolong SSD lifetime.  IIUC,
besides directly reducing the amount of data written, compression allows
extra over-provisioning which should reduce the write amplification
factor too.

Level 12 compression probably hurts performance a bit, but programs
still start very quickly---far quicker than they did over the HDD with
ext4.  This makes sense to me, because (IIUC) starting programs is
read-intensive and zstd decompression is fast even on high compression
levels.  And surprisingly, even dpkg package installation and updates,
which (IIUC) are write-intensive, are very quick too.

Besides, I think I rarely need top CPU power and disk throughput at the
same time.  I max out the quad-core processor when compiling Guix
packages but that happens on /tmp (tmpfs), so high Btrfs zstd
compression does no harm.  I also stress the CPU (and the integrated
GPU) on the rare occasions I play Xonotic or SuperTuxKart, and Btrfs
compression probably does no harm during 3D game rendering either.

In conclusion, my SSD is plenty quick for my needs even with very high
Btrfs zstd compression.  I care more about maximizing its lifetime than
having programs start a fraction of a second quicker when they already
start very quickly.

And when the system settles I intend to reduce Btrfs zstd compression
level to 9 or 6 in an attempt to save electricity---although I am nearly
always on AC power.

> No, I am not on this list, where is it?  Please send a link!

http://vger.kernel.org/vger-lists.html#linux-btrfs

Kind regards,
  Jorge

-- 
- Many people hate injustice but few check the facts; this causes more
  injustice.  Ask me about 
- Please adopt free/libre formats like PDF, Org, LaTeX, ODF, Opus, WebM and 7z.
- Libre apps for AOSP (Replicant, LineageOS, etc.) and Android: F-Droid
- https://www.gnu.org/philosophy/free-sw.html "What is free software?"

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[piorunz]

On 02/01/2022 16:33, Jorge P. de Morais Neto wrote:

Hi Piotr!  Happy 2022!


Hi Jorge!

Likewise!


Have you revised after kernel Linux 4.15?  The btrfs(5) manpage says:

Since kernel 4.15, a set of heuristic algorithms have been
improved by using frequency sampling, repeated pattern
detection and Shannon entropy calculation to avoid that.

Therefore, it looks like after kernel Linux 4.15 the compress option (or
compress=ALG:LEVEL), instead of compress-force, became more interesting.


Full paragraph says:
"Otherwise some simple heuristics are applied to detect an
incompressible file. If the first blocks written to a file are not
compressible, the whole file is permanently marked to skip compression.
As this is too simple, the compress-force is a workaround that will
compress most of the files at the cost of some wasted CPU cycles on
failed attempts. Since kernel 4.15, a set of heuristic algorithms have
been improved by using frequency sampling, repeated pattern detection
and Shannon entropy calculation to avoid that."

Meaning, compress has been improved to detect first block-uncompressible
rest-compressible files, and so on. But only improved.
Compress-force still remains 100% efficient in compressing everything,
for example 40GB VM disk file, where first 20GB is well used, but
remaining 20GB are empty with zeros, or zero-like patterns, which are
highly compressible. However "improved" compress is, I doubt it will
catch all these edge cases. I entrust compress-force to compress
everything for me without misses, at the cost of some CPU usage, most
likely much smaller CPU footprint than chosen compression level itself.



I am currently using compress-force=zstd:12 for the SSD and
compress=zstd:12 for both HDD (internal SATA and external USB3)¹.
Despite the strong compression level, performance is pretty good.  Yet,
when the system settles, I intend to reduce compression level to 9 or 6
(as you earlier recommended).  This should make performance even better,
while saving a lot of space because most data was compressed at
level 12.


I run compress-force=zstd:6 on my fast PC, compress-force=zstd:3 on my
server (to give it a bit more breathing space), and also same level 3 on
my laptop. 12 is quite high for SSD, are you sure you not slowing down
peak performance of your SSD by intense CPU usage? Or is it by design,
to reduce number of writes to SSD?


And I may also change compress-force to compress, even for the SSD,
because I run kernel 5.10 which is later than 4.15.  I may ask the
linux-btrfs mailing list first.  I have subscribed to it.  Are you there
too?


No, I am not on this list, where is it? Please send a link!


Regards

* Footnotes

¹ Both HDD have compress (rather than compress-force) because most of
their files are already compressed---pictures, videos, music, compressed
archives etc.


Makes sense!

--
With kindest regards, Piotr.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[Jorge P . de Morais Neto]

Hi Piotr!  Happy 2022!

Em [2021-12-08 qua 22:54:29+], piorunz escreveu:

> On 08/12/2021 19:35, Jorge P. de Morais Neto wrote:

>> - Why `compress-force' instead of simply `compress'?
>
> I've read very extensive discussion about that and came to conclusion
> that compress-force is better.  It's checking every chunk of file for
> compressibility.  "compress", on the other hand, checks only first
> sectors, then drops compression if no compressible data is detected.
> Imagine your qcow file, first 1 GB is not compressible, so "compress"
> option will drop compression of that file right away.  But remaining 20GB
> are zeros because you haven't filled that yet.  With compress-force, you
> compress these zeros to nothing.  File takes 1GB of space.  You don't have
> that on ext4, or btrfs "compress" only option.

Have you revised after kernel Linux 4.15?  The btrfs(5) manpage says:

   Since kernel 4.15, a set of heuristic algorithms have been
   improved by using frequency sampling, repeated pattern
   detection and Shannon entropy calculation to avoid that.

Therefore, it looks like after kernel Linux 4.15 the compress option (or
compress=ALG:LEVEL), instead of compress-force, became more interesting.

I am currently using compress-force=zstd:12 for the SSD and
compress=zstd:12 for both HDD (internal SATA and external USB3)¹.
Despite the strong compression level, performance is pretty good.  Yet,
when the system settles, I intend to reduce compression level to 9 or 6
(as you earlier recommended).  This should make performance even better,
while saving a lot of space because most data was compressed at
level 12.

And I may also change compress-force to compress, even for the SSD,
because I run kernel 5.10 which is later than 4.15.  I may ask the
linux-btrfs mailing list first.  I have subscribed to it.  Are you there
too?

Regards

* Footnotes

¹ Both HDD have compress (rather than compress-force) because most of
their files are already compressed---pictures, videos, music, compressed
archives etc.

-- 
- Many people hate injustice but few check the facts; this causes more
  injustice.  Ask me about 
- I am Brazilian.  I hope my English is correct and I welcome feedback.
- https://www.defectivebydesign.org
- https://www.gnu.org

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[Andy Smith]

Hi Jorge,

On Wed, Dec 15, 2021 at 11:39:59AM -0300, Jorge P. de Morais Neto wrote:
> I intend to use Btrfs.  This means if I later decide to use some of the
> unpartitioned space, I can easily and efficiently add it to the main
> Btrfs file system without directly using LVM (since Btrfs actually
> includes logical volume management), right?

Sure. You can make a smaller partition as your btrfs, make
sub-volumes out of that and when it comes time to expand you can
simply extend the end of the partition and tell btrfs to grow into
it.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[Andrei POPESCU]

On Ma, 14 dec 21, 14:30:10, Jorge P. de Morais Neto wrote:
> Hello!  I apologize for the delay and reply below:
> 
> Em [2021-12-09 qui 11:36:17+0200], Anssi Saari escreveu:
> 
> >> I would have tmpfs on /tmp---I have read that long thread where
> >> someone alleged that moving /tmp to tmpfs makes it useless but I
> >> disagree.
> >
> > Any link to this discussion?  I really like tmpfs for /tmp but for
> > everything there's resistance to change first and foremost.
> 
> LWN.net summary: https://lwn.net/Articles/499410/ "Temporary files: RAM
> or disk?"
> 
> Summary by the thread initiator:
> https://lists.debian.org/debian-devel/2012/06/msg00311.html "Summary:
> Moving /tmp to tmpfs makes it useless"

That discussion is from 2012 (which in computing is ancient history), I 
wonder how much of it is still valid (either way).

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[hdv@gmail]

On 2021-12-15 15:51, Jorge P. de Morais Neto wrote:

Hello,

Em [2021-12-09 qui 15:00:43+0100], hdv@gmail escreveu:


Regarding the swap space: I wouldn't make it so big.  That really isn't
necessary.  I have a 64GB RAM system here, on which I have 2GB of swap.  I
doubt I have ever seen conky show me more than 35% use.  And I am quite a
heavy user of system resources (much 3D CAD editing, photo editing,
video editing and rendering, and often multiple VM's in use).

My laptop has 32GB of RAM and 2 GB of swap and on that system I haven't
seen much swapping either.


I wanted to play safe in case I later upgrade the RAM to 32 GiB and,
additionally, I later enable the hibernate functionality.  Since I have
a 1 TB HDD, I can spare a 32 GiB (approximately 34 GB) for swapping.


If you can spare the space, then I don't see why not. If you plan to go 
to ACPI state S4 (suspend to disk, hibernate) this certainly is useful. 
In my experience only a handful of people actually use S4 though.


> For increased swapping performance, the swapping space on a rotational

drive should be contiguous and located at the start of the drive, right?


I used to think so myself. And out of habit I still choose to do it like 
that myself. But I haven't noticed any significant performance gains 
during some extensive testing in practice (>100 disks over a period of 3 
years in a server room of a university).


Apart from performance, it is said that it would mean less movement of 
the heads and thus less wear [1], but again, in practice I haven't ever 
seen a case where this would have made a significant difference in a 
normal user setting. It would be different in a large-scale commercial 
setting though.


There is something else to consider: why not create a swap file, instead 
of a swap partition? That way you are free to play around and test what 
fits your needs best, without having to chance the partitions.


[1] This will depend on many, many parameters. You would expect a 
location somewhere in the middle of the disk to be the sweet spot when 
it comes to minimising movement in a fairly filled up disk. But then 
again, if you have lots of static files you do not regularly access in a 
large partition at the end of the disk, then you will have an uneven 
geometry which will make the optimum shift.


Grx HdV

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[Jorge P . de Morais Neto]

Hello,

Em [2021-12-09 qui 15:00:43+0100], hdv@gmail escreveu:

> Regarding the swap space: I wouldn't make it so big.  That really isn't 
> necessary.  I have a 64GB RAM system here, on which I have 2GB of swap.  I 
> doubt I have ever seen conky show me more than 35% use.  And I am quite a 
> heavy user of system resources (much 3D CAD editing, photo editing, 
> video editing and rendering, and often multiple VM's in use).
>
> My laptop has 32GB of RAM and 2 GB of swap and on that system I haven't 
> seen much swapping either.

I wanted to play safe in case I later upgrade the RAM to 32 GiB and,
additionally, I later enable the hibernate functionality.  Since I have
a 1 TB HDD, I can spare a 32 GiB (approximately 34 GB) for swapping.
For increased swapping performance, the swapping space on a rotational
drive should be contiguous and located at the start of the drive, right?

Kindest regards,
Jorge

-- 
- Many people hate injustice but few check the facts; this causes more
  injustice.  Ask me about 
- I am Brazilian.  I hope my English is correct and I welcome feedback.
- https://www.defectivebydesign.org
- https://www.gnu.org

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[Jorge P . de Morais Neto]

Hello,

Em [2021-12-09 qui 01:02:17+], Andy Smith escreveu:

> If you are still worried you could partition just half of it and use
> it as a physical volume for LVM, which you might want to do anyway to
> encrypt it (LUKS), Then over time you can see how much you have
> written, how much life is left etc. and decide then whether to leave
> it over-provisioned or extend the LVM further.  It leaves your options
> open.

I intend to use Btrfs.  This means if I later decide to use some of the
unpartitioned space, I can easily and efficiently add it to the main
Btrfs file system without directly using LVM (since Btrfs actually
includes logical volume management), right?

Kindest regards,

-- 
- Many people hate injustice but few check the facts; this causes more
  injustice.  Ask me about 
- Please adopt free/libre formats like PDF, Org, LaTeX, ODF, Opus, WebM and 7z.
- Libre apps for AOSP (Replicant, LineageOS, etc.) and Android: F-Droid
- https://www.gnu.org/philosophy/free-sw.html "What is free software?"

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[Jorge P . de Morais Neto]

Hi.

Em [2021-12-09 qui 05:14:09+0500], Alexander V. Makartsev escreveu:

> So, if you plan to use NVMe SSD as a system drive, I suggest you also 
> keep /swap partition

I am considering swapping to the SSD, yes.

> Also, I suggest you to make backups of /home on daily schedule to HDD,
> because data recovery from a failed SSD is not only very expensive,
> but often also next to impossible.

Thank you for this tip, I was not fully aware of this issue.

Kindest regards

-- 
- Many people hate injustice but few check the facts; this causes more
  injustice.  Ask me about 
- I am Brazilian.  I hope my English is correct and I welcome feedback.
- Free Software Supporter: https://www.fsf.org/free-software-supporter
- If an email of mine arrives at your spam box, please notify me.

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[David Christensen]

On 12/14/21 9:39 AM, Jorge P. de Morais Neto wrote:

Hello!

Em [2021-12-08 qua 22:05:50-0800], David Christensen escreveu:


I would remove the 1 TB HDD, install the 250 GB NVMe SSD, and do a fresh
install of Debian 11 with MBR partitioning, 1E+9 byte boot partition
(ext4)


Why MBR partitioning 



So that you can boot the system drive in old and new computers -- e.g. 
MBR is "lowest common denominator".




and why a separate boot partition?



To boot the system when root is encrypted.



I would put the 1 TB HDD into an external HDD enclosure and use it to
store system images (e.g. partition table, boot, swap, and root).


I already have a 1.5 TB external HDD.  And I intend to use GPT
partitioning, which (I've read) stores checksummed copies of the
partition table. 



https://en.wikipedia.org/wiki/Data_integrity


I keep records of how I partition each disk, so I can easily recreate a 
damaged partition table.  Alternatively, or in addition, there are tools 
for backing up and restoring partition tables.  The monthly images that 
I take include the partition table, boot partition, swap partition, and 
root partition.



I suggest that you look at Btrfs and/or ZFS for filesystem, metadata, 
and data integrity.  Btrfs is available in the Debian installer and can 
be used for boot, root, and data; but may require manual maintenance. 
ZFS is a package, and readily used for data; but boot and root are 
advanced use-cases.




For the actual data, I have weekly backups to the
external HDD, and I intend to have daily rsync of some of the SSD data
to the internal HDD.  Would not that be safe enough?



Only you can decide what is "safe enough".



I recommend a file server or NAS for bulk data -- downloads, music,
photographs, videos, etc..


I would like to setup a home server, but probably not very soon.



Setting up a Samba server is an ideal use-case for Debian.  So is 
setting up a Git repository.  Save up for a real server with Xeon CPU(s) 
and ECC memory (used hardware shipped to Brasil starts around US$250 on 
eBay).




I recommend a version control server for user project files and system
configuration files.


I store my dotfiles (and some other data) in a git repository in my
notebook.  



Good.



I hope that duplicity is correctly backing up that git
repository, 



Do not hope; validate.



but I admit I have not tested it.



Install Debian onto a good USB 3.0 flash drive.  Install your favorite 
troubleshooting and backup tools.  Backup your laptop as usual.  Use the 
USB Debian drive to do a restore onto alternate media.  Use the USB 
Debian drive to verify that the restore matches the original.



David

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[Jorge P . de Morais Neto]

Hello!

Em [2021-12-08 qua 22:05:50-0800], David Christensen escreveu:

> I would remove the 1 TB HDD, install the 250 GB NVMe SSD, and do a fresh 
> install of Debian 11 with MBR partitioning, 1E+9 byte boot partition 
> (ext4)

Why MBR partitioning and why a separate boot partition?

> I would put the 1 TB HDD into an external HDD enclosure and use it to
> store system images (e.g. partition table, boot, swap, and root).

I already have a 1.5 TB external HDD.  And I intend to use GPT
partitioning, which (I've read) stores checksummed copies of the
partition table.  For the actual data, I have weekly backups to the
external HDD, and I intend to have daily rsync of some of the SSD data
to the internal HDD.  Would not that be safe enough?

> I recommend a file server or NAS for bulk data -- downloads, music,
> photographs, videos, etc..

I would like to setup a home server, but probably not very soon.

> I recommend a version control server for user project files and system 
> configuration files.

I store my dotfiles (and some other data) in a git repository in my
notebook.  I hope that duplicity is correctly backing up that git
repository, but I admit I have not tested it.

Regards!

-- 
- Many people hate injustice but few check the facts; this causes more
  injustice.  Ask me about 
- I am Brazilian.  I hope my English is correct and I welcome feedback.
- https://www.defectivebydesign.org
- https://www.gnu.org

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[Andrew M.A. Cater]

On Fri, Dec 10, 2021 at 08:08:22AM -0700, Charles Curley wrote:
> On Fri, 10 Dec 2021 08:26:24 -0500
> Dan Ritter  wrote:
> 
> > Many laptops never need to go to disk-stored suspension; a low-power
> > sleep mode is all they need to get through to the next power point.
> > For the cases where it is necessary, it should be as reliable as
> > possible.
> 
> Perhaps. But one reason to use hibernation (disk-stored suspension) is
> security. If your hard drive, including swap area, is encrypted,
> hibernation encrypts everything, and one would need the passphrase to
> get in to the system. Thus your data is more secure from governments
> and other thieves.
> 

One thing that may be worth thinking about: if you take "guided partitioning"
then for Bullseye, the default size of swap is 1GB - since very few
programs should be hitting swap. If you have a laptop with 8G of memory,
then you may well need at least 8G to hibernate - so it is worth checking
siazes and requirements as you install.

On the laptop next door with 4G of memory but only 32G of flash disk - 
saving for hibernation would be difficult.

All the very best, as ever,

Andy Cater


> -- 
> Does anybody read signatures any more?
> 
> https://charlescurley.com
> https://charlescurley.com/blog/
> 

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[Charles Curley]

On Fri, 10 Dec 2021 08:26:24 -0500
Dan Ritter  wrote:

> Many laptops never need to go to disk-stored suspension; a low-power
> sleep mode is all they need to get through to the next power point.
> For the cases where it is necessary, it should be as reliable as
> possible.

Perhaps. But one reason to use hibernation (disk-stored suspension) is
security. If your hard drive, including swap area, is encrypted,
hibernation encrypts everything, and one would need the passphrase to
get in to the system. Thus your data is more secure from governments
and other thieves.

-- 
Does anybody read signatures any more?

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

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[Dan Ritter]

Andrei POPESCU wrote: 
> On Vi, 10 dec 21, 07:21:37, Dan Ritter wrote:
> > Andrei POPESCU wrote: 
> > > On Jo, 09 dec 21, 09:46:26, Dan Ritter wrote:
> > > > 
> > > > In a more perfect world, the space for suspension would not
> > > > otherwise be treated as swap space.
> > > 
> > > It still has to be reserved from somewhere, and swap appears to be the 
> > > logical choice for that.
> > 
> > No, it was a convenient choice. A better choice would have been
> > a way to mark a swap partition or file as for use only by the
> > hibernation system, or, as actually once existed, a system that
> > would mount a specific swap partition during the hibernation
> > shutdown procedure, and unmount it after recovery.
> 
> In my opinion that would be a waste of space.

It is a reasonable opinion, but I disagree.

On modern laptops, there is usually a lot of disk space (500GB - 1TB),
so 8-64GB reserved for a special use is not a terrible price compared
to other things we do. I wouldn't make it mandatory, just easy.

Many laptops never need to go to disk-stored suspension; a low-power
sleep mode is all they need to get through to the next power point. For
the cases where it is necessary, it should be as reliable as possible.

-dsr-

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[Darac Marjal]

On 10/12/2021 12:21, Dan Ritter wrote:

Andrei POPESCU wrote:

On Jo, 09 dec 21, 09:46:26, Dan Ritter wrote:

In a more perfect world, the space for suspension would not
otherwise be treated as swap space.

It still has to be reserved from somewhere, and swap appears to be the
logical choice for that.

No, it was a convenient choice. A better choice would have been
a way to mark a swap partition or file as for use only by the
hibernation system, or, as actually once existed, a system that
would mount a specific swap partition during the hibernation
shutdown procedure, and unmount it after recovery.


According to systemd-suspend.service(8):

"Immediately before entering system suspend and/or hibernation 
systemd-suspend.service (and the other mentioned units, respectively) 
will run all executables in /lib/systemd/system-sleep/"


There is also /etc/pm/sleep.d, which is a more system-specific location 
(i.e. /etc rather than /lib)


Therefore, it *should* be theoretically possible to reserve a partition 
explicitly for the purpose of hibernation. The script can bring the 
device online (with swapon) and then tell the kernel to hibernate to 
that device (echo $MAJOR:$MINOR > /sys/power/resume). Upon resume, the 
device can be taken offline (with swapoff) so that it isn't used for 
regular swap.


For extra credit, devise a standard marking for this partition (e.g. a 
label or a GPT UUID) so that this system can be made universal :)





-dsr-



OpenPGP_signature
Description: OpenPGP digital signature

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[Andrei POPESCU]

On Vi, 10 dec 21, 07:21:37, Dan Ritter wrote:
> Andrei POPESCU wrote: 
> > On Jo, 09 dec 21, 09:46:26, Dan Ritter wrote:
> > > 
> > > In a more perfect world, the space for suspension would not
> > > otherwise be treated as swap space.
> > 
> > It still has to be reserved from somewhere, and swap appears to be the 
> > logical choice for that.
> 
> No, it was a convenient choice. A better choice would have been
> a way to mark a swap partition or file as for use only by the
> hibernation system, or, as actually once existed, a system that
> would mount a specific swap partition during the hibernation
> shutdown procedure, and unmount it after recovery.

In my opinion that would be a waste of space.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[Dan Ritter]

Andrei POPESCU wrote: 
> On Jo, 09 dec 21, 09:46:26, Dan Ritter wrote:
> > 
> > In a more perfect world, the space for suspension would not
> > otherwise be treated as swap space.
> 
> It still has to be reserved from somewhere, and swap appears to be the 
> logical choice for that.

No, it was a convenient choice. A better choice would have been
a way to mark a swap partition or file as for use only by the
hibernation system, or, as actually once existed, a system that
would mount a specific swap partition during the hibernation
shutdown procedure, and unmount it after recovery.

-dsr-

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[Andrei POPESCU]

On Jo, 09 dec 21, 09:46:26, Dan Ritter wrote:
> 
> In a more perfect world, the space for suspension would not
> otherwise be treated as swap space.

It still has to be reserved from somewhere, and swap appears to be the 
logical choice for that.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[Darac Marjal]

On 10/12/2021 04:53, David Wright wrote:

On Thu 09 Dec 2021 at 17:12:01 (-), Curt wrote:

On 2021-12-09, hdv@gmail  wrote:

Swap is where a laptop stores RAM during suspend-to-disk, the long
term hibernation suspension. Without at least as much swap as
RAM, you are limited to suspend-to-RAM.

In a more perfect world, the space for suspension would not
otherwise be treated as swap space.

It certainly was the reason why I always had swap at least as big as RAM
in the past on my laptops. However, I have not had any trouble
suspending or hibernating my laptops in the years since I reduced swap
to 2GB. That is just my experience, and it may not be the same for
others. But it might help the thread starter to know this is a feasible
option (depending on their use case).

It's only that there is a distinction between suspend-to-RAM and
suspend-to-disk, the latter using zero power consumption until the
machine is powered on.

Anyway, you probably already knew that (I didn't).

Aka hibernation, it's also incompatible with random-encrypted swap
(recommended in https://lists.debian.org/debian-user/2021/12/msg00239.html,
and by me, if you have sensitive information on your laptop).


It's a shame that TuxOnIce (aka Software Suspend 2) seems to have 
disappeared. That was a mostly-userspace hibernation solution that 
developed some quite neat tricks such as:


 * Mounting a swap device prior to hibernation

 * Graphical progress of hibernation

I seem to recall that, because it *was* a userspace solution, you needed 
to boot a certain amount of kernel and userspace before you could start 
resuming from hibernation, so there should have been a point where you 
could handle decryption (although, you would need a known key to decrypt 
the swap device, I suppose).





Cheers,
David.



OpenPGP_signature
Description: OpenPGP digital signature

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[David Wright]

On Thu 09 Dec 2021 at 17:12:01 (-), Curt wrote:
> On 2021-12-09, hdv@gmail  wrote:
> >> 
> >> Swap is where a laptop stores RAM during suspend-to-disk, the long
> >> term hibernation suspension. Without at least as much swap as
> >> RAM, you are limited to suspend-to-RAM.
> >> 
> >> In a more perfect world, the space for suspension would not
> >> otherwise be treated as swap space.
> >
> > It certainly was the reason why I always had swap at least as big as RAM 
> > in the past on my laptops. However, I have not had any trouble 
> > suspending or hibernating my laptops in the years since I reduced swap 
> > to 2GB. That is just my experience, and it may not be the same for 
> > others. But it might help the thread starter to know this is a feasible 
> > option (depending on their use case).
> 
> It's only that there is a distinction between suspend-to-RAM and
> suspend-to-disk, the latter using zero power consumption until the
> machine is powered on. 
> 
> Anyway, you probably already knew that (I didn't).

Aka hibernation, it's also incompatible with random-encrypted swap
(recommended in https://lists.debian.org/debian-user/2021/12/msg00239.html,
and by me, if you have sensitive information on your laptop).

Cheers,
David.

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[piorunz]

On 09/12/2021 16:16, piorunz wrote:

I monitor SMART very closely.


Just spend last hour adding things to my Telegram bot which monitors my
server passively:

https://i.imgur.com/TnI0kex.png
https://i.imgur.com/3RQQWT1.png

All important SMART fields which are 0, are now hidden, I only see
non-zero values.



--
With kindest regards, Piotr.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[Curt]

On 2021-12-09, hdv@gmail  wrote:
>> 
>> Swap is where a laptop stores RAM during suspend-to-disk, the long
>> term hibernation suspension. Without at least as much swap as
>> RAM, you are limited to suspend-to-RAM.
>> 
>> In a more perfect world, the space for suspension would not
>> otherwise be treated as swap space.
>> 
>> -dsr-
>> 
>
> It certainly was the reason why I always had swap at least as big as RAM 
> in the past on my laptops. However, I have not had any trouble 
> suspending or hibernating my laptops in the years since I reduced swap 
> to 2GB. That is just my experience, and it may not be the same for 
> others. But it might help the thread starter to know this is a feasible 
> option (depending on their use case).

It's only that there is a distinction between suspend-to-RAM and
suspend-to-disk, the latter using zero power consumption until the
machine is powered on. 

Anyway, you probably already knew that (I didn't).

> P.S. I am on the list. It is sufficient to just reply to the list for me 
> to receive your message.
>
> Grx HdV
>
>


-- 

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[piorunz]

On 09/12/2021 15:22, Alexander V. Makartsev wrote:


"Crucial MX500 250GB" is based on a NAND 3D TLC-3bit¹ ICs and rated only
100TBW.
That is a relatively small amount, if you compare it to the devices I
was talking about.
Now if you take 12% for 2 years of 100TBW drive, which may look like a
lot at a first glance and calculate the difference (300TBW / 100TBW = 3;
12 / 3 = 4), it won't look too off from what I've got in the SMART readings.
So now let's assume you will continue to use your SSDs like before, it
would take roughly 14 years more (12% / 2 years = 6% per year; 100 / 6 =
16) of continuous use to wear out.
That's way past their warranty period and by reaching that time they
already paid for themselves.


I monitor SMART very closely.

*SMART data:*
Device Model: CT250MX500SSD1
Power On: 18188 hours
Temperature: 38 °C
Reported Uncorrectable: 0
Offline Uncorrectable: 0
Reallocated NAND Blocks: 0
Unused Reserve NAND Blocks: 31
Life Used: 12%
Total Written: 12 TiB

Device Model: CT250MX500SSD1
Power On: 15601 hours
Temperature: 35 °C
Reported Uncorrectable: 0
Offline Uncorrectable: 0
Reallocated NAND Blocks: 0
Unused Reserve NAND Blocks: 28
Life Used: 12%
Total Written: 13 TiB

Since I use only part of the drive now, and rest is not partitioned,
drive sees this and recognizes as overprovisioning. Wear levelling
mechanisms can use this surface, drive doesn't need to remember states
of cells in this region. I might be wrong, but that's what happening I
think.
Since I did that, writes have stopped. Debian is running on these
drives, / partition, /home and /var are elsewhere. Nothing is happening
on these drives apart from apt updates sometimes. Usage didn't changed
With overprovisioning enabled now, I can easily run with drives in mint
condition for many years without worry.

--
With kindest regards, Piotr.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[hdv@gmail]

On 2021-12-09 15:46, Dan Ritter wrote:

hdv@gmail wrote:

On 2021-12-08 15:27, Jorge P. de Morais Neto wrote:

Hi everyone!  I have a Dell Inspiron 5570 laptop with 1TB HDD and 16 GiB
RAM (it supports 32 GiB).  I am about to buy an M.2 NVMe 250GB SSD---a
  

Regarding the swap space: I wouldn't make it so big. That really isn't
necessary. I have a 64GB RAM system here, on which I have 2GB of swap. I
doubt I have ever seen conky show me more than 35% use. And I am quite a
heavy user of system resources (much 3D CAD editing, photo editing, video
editing and rendering, and often multiple VM's in use).

My laptop has 32GB of RAM and 2 GB of swap and on that system I haven't seen
much swapping either.


Swap is where a laptop stores RAM during suspend-to-disk, the long
term hibernation suspension. Without at least as much swap as
RAM, you are limited to suspend-to-RAM.

In a more perfect world, the space for suspension would not
otherwise be treated as swap space.

-dsr-



It certainly was the reason why I always had swap at least as big as RAM 
in the past on my laptops. However, I have not had any trouble 
suspending or hibernating my laptops in the years since I reduced swap 
to 2GB. That is just my experience, and it may not be the same for 
others. But it might help the thread starter to know this is a feasible 
option (depending on their use case).


P.S. I am on the list. It is sufficient to just reply to the list for me 
to receive your message.


Grx HdV

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[Alexander V. Makartsev]

On 09.12.2021 15:22, piorunz wrote:

On 09/12/2021 00:14, Alexander V. Makartsev wrote:

I'd advise against doing extra over-provisioning and making /swap on
slow HDD.
IMO it is a thing of the past, especially on a home\personal computer.
Modern NAND technology and provisioning algorithms made SSDs quite
resilient.
It is more likely that a controller IC will fail than a NAND ICs will
wear off themselves during mild daily usage.


I disagree. I was quite surprised that my 2x Crucial MX500 250GB 3D
drives which I use in mdadm RAID1, saying that they are 12% used in 2
years of use. That's because I created one big partition for entire
drive and used it that way. Most of it was free anyway. They are used as
/ in my server, mostly just idling, as all work is being done on HDD
RAID (/home and /var is on HDDs too). Now, I trimmed down Ext4 partition
and mdadm RAID surface underneath it, and left free space at the end of
the drive. Slow creep of life used has stopped and I am on 12% on both
drives for few months now. Nothing else has changed, and life use 
stopped.

Maybe Crucial drives are just more honest than other drives who say 2%
use after 5 years of operation?
Usage will be different for everyone and in perfect scenario you have to 
estimate how much data you would write to SSD daily, before you purchase 
them.
Also, you have to keep in mind TBW ratings of devices you have and NAND 
type they based on.
Published ratings should be a result of standardized testing procedures 
which were developed by JEDEC.
This costs money and its the reason why some SSD manufacturers hide 
ratings and/or NAND types of their products from specifications.


"Crucial MX500 250GB" is based on a NAND 3D TLC-3bit¹ ICs and rated only 
100TBW.
That is a relatively small amount, if you compare it to the devices I 
was talking about.
Now if you take 12% for 2 years of 100TBW drive, which may look like a 
lot at a first glance and calculate the difference (300TBW / 100TBW = 3; 
12 / 3 = 4), it won't look too off from what I've got in the SMART readings.
So now let's assume you will continue to use your SSDs like before, it 
would take roughly 14 years more (12% / 2 years = 6% per year; 100 / 6 = 
16) of continuous use to wear out.
That's way past their warranty period and by reaching that time they 
already paid for themselves.
As you can see, as long as you buy drives with your workload in mind, 
make backups (which you should do anyway) and monitor the SMART, there 
is almost zero reasons to buy a SSD and not use it to it's full potential.


The data will be spread out among NAND ICs² evenly by provisioning 
algorithms anyway and IMO leaving extra unpartitioned space won't do 
anything useful.
If I remember correctly, there was a time in early SSD days when doing 
that was recommended, but I don't think this is still needed, because 
modern SSDs became quite spacious and their controllers and firmware 
evolved.



¹ Crucial\Micron is hiding the actual NAND type, like many others, 
presenting marketing fluff instead, and I assume it is an older 3D TLC 
3-bit with low layer count and hopefully not QLC.
² Usually inside a cheap consumer-grade devices only two NAND ICs, often 
even without DRAM buffer.


--
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[Dan Ritter]

hdv@gmail wrote: 
> On 2021-12-08 15:27, Jorge P. de Morais Neto wrote:
> > Hi everyone!  I have a Dell Inspiron 5570 laptop with 1TB HDD and 16 GiB
> > RAM (it supports 32 GiB).  I am about to buy an M.2 NVMe 250GB SSD---a
 
> Regarding the swap space: I wouldn't make it so big. That really isn't
> necessary. I have a 64GB RAM system here, on which I have 2GB of swap. I
> doubt I have ever seen conky show me more than 35% use. And I am quite a
> heavy user of system resources (much 3D CAD editing, photo editing, video
> editing and rendering, and often multiple VM's in use).
> 
> My laptop has 32GB of RAM and 2 GB of swap and on that system I haven't seen
> much swapping either.

Swap is where a laptop stores RAM during suspend-to-disk, the long
term hibernation suspension. Without at least as much swap as
RAM, you are limited to suspend-to-RAM.

In a more perfect world, the space for suspension would not
otherwise be treated as swap space.

-dsr-

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[hdv@gmail]

On 2021-12-08 15:27, Jorge P. de Morais Neto wrote:

Hi everyone!  I have a Dell Inspiron 5570 laptop with 1TB HDD and 16 GiB
RAM (it supports 32 GiB).  I am about to buy an M.2 NVMe 250GB SSD---a
Western Digital WD Blue SN550.  I would like to set the system for
reliability, SSD durability¹ and performance.

I have looked at [Multi HDD/SSD Partitioning Scheme][] but it is too
complex and probably outdated (last modified 2013-10-17).  I would like
something simpler.  For backups, I would continue my weekly manual
backups to my 1.5 TB external HDD with duplicity.

On the SSD I intend to leave 35 GB unpartitioned for extra over
provisioning.  It would have just one 215 GB partition.

On the HDD I would put a 34 GB swap partition at the beginning, then a
215 GB partition for RAID1 with the SSD, then a 751 GB partition.  I
intend to put Debian system *and* /home on the 215 GB RAID1, but I would
set all the XDG user dirs² on the 751 GB HDD partition.  I would have
tmpfs on /tmp---I have read that long thread where someone alleged that
moving /tmp to tmpfs makes it useless but I disagree.

Would all this be reasonable?  Do you recommend any change?  Any tip?  I
run Debian stable with only official repositories, including
bullseye-backports.  I also manually installed GNU Guix package manager
and my main Guix profile has 163 packages.

Regards!

[Multi HDD/SSD Partitioning Scheme] 
https://wiki.debian.org/Multi%20HDD/SSD%20Partition%20Scheme

¹ According to its data sheet, the 250GB WD Blue SN550 endures 150TBW.
² See the xdg-user-dir manpage.



Regarding the swap space: I wouldn't make it so big. That really isn't 
necessary. I have a 64GB RAM system here, on which I have 2GB of swap. I 
doubt I have ever seen conky show me more than 35% use. And I am quite a 
heavy user of system resources (much 3D CAD editing, photo editing, 
video editing and rendering, and often multiple VM's in use).


My laptop has 32GB of RAM and 2 GB of swap and on that system I haven't 
seen much swapping either.


Grx HdV

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[piorunz]

On 08/12/2021 19:35, Jorge P. de Morais Neto wrote:

- noatime: I didn't know about this issue, I thought relatime was
   efficient enough.  Thank you for the tip!



- nodiratime: According to the mount manpage, noatime implies
   nodiratime.


That's correct, I removed nodiratime.


- ssd: Does btrfs not autodetect SSD?  Why provide ssd option?


You are correct. Couldn't find it in btrfs man pages... but several
online sources said this:
https://docs.oracle.com/cd/E37670_01/E41138/html/section_ek5_kn5_tr.html

Just removed SSD option. I'm gonna trust Btrfs to detect my drives
correctly.

Thanks! :)

--
With kindest regards, Piotr.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[Dan Ritter]

Anssi Saari wrote: 
> 
> In general, I wonder what Debian's policy is on Guix? Does it create a
> FrankenDebian? I wonder the same about Debian-Multimedia too. Some
> poeple seem to hate that, I use it for GPU accelerated ffmpeg for the
> rare occasions when I need to encode video. And they package mplayer
> too.

A FrankenDebian is a system where the repositories that .deb
packages come from have different owners and have the
possibility of conflicting with each other in ways that the
packaging system can't resolve by itself.

If you have a control system that uses apt to install packages,
that doesn't create a conflict at all.

If you have a control system that installs its own non .deb
packages in a way that doesn't break anything else -- say, using
/opt, /usr/local, /home/USER/something -- that doesn't create a
conflict. 

If you have a control system which installs things over the
standard directories, possibly with the same names, it's not a
FrankenDebian but it is very likely to be a borken system very
quickly.

Deb-Multimedia (note, changed its name to reduce the likelihood
of being confused with an official Debian project) provides a
repo of packages that can conflict and create a FrankenDebian.
That said, it is very useful in certain cases. Nobody wants to
help pick up the pieces, though.

-dsr-

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[piorunz]

On 09/12/2021 00:14, Alexander V. Makartsev wrote:

I'd advise against doing extra over-provisioning and making /swap on
slow HDD.
IMO it is a thing of the past, especially on a home\personal computer.
Modern NAND technology and provisioning algorithms made SSDs quite
resilient.
It is more likely that a controller IC will fail than a NAND ICs will
wear off themselves during mild daily usage.


I disagree. I was quite surprised that my 2x Crucial MX500 250GB 3D
drives which I use in mdadm RAID1, saying that they are 12% used in 2
years of use. That's because I created one big partition for entire
drive and used it that way. Most of it was free anyway. They are used as
/ in my server, mostly just idling, as all work is being done on HDD
RAID (/home and /var is on HDDs too). Now, I trimmed down Ext4 partition
and mdadm RAID surface underneath it, and left free space at the end of
the drive. Slow creep of life used has stopped and I am on 12% on both
drives for few months now. Nothing else has changed, and life use stopped.
Maybe Crucial drives are just more honest than other drives who say 2%
use after 5 years of operation?

--
With kindest regards, Piotr.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[Anssi Saari]

"Jorge P. de Morais Neto"  writes:

> Hi everyone!  I have a Dell Inspiron 5570 laptop with 1TB HDD and 16 GiB
> RAM (it supports 32 GiB).  I am about to buy an M.2 NVMe 250GB SSD---a
> Western Digital WD Blue SN550.  I would like to set the system for
> reliability, SSD durability¹ and performance.

Are you really on a shoestring budget? The SN550 comes in 1 TB size
too. You could put two SSDs on the system easily.

> On the SSD I intend to leave 35 GB unpartitioned for extra over
> provisioning.  It would have just one 215 GB partition.

Does that actually help anything? I see it more as a case of "SSDs are
ice cream" fallacy from the decade before last.

> On the HDD I would put a 34 GB swap partition at the beginning

If you're going to page, why page to the slow media? Because the SSD
is ice cream again and will melt away if used?

> ...then a 215 GB partition for RAID1 with the SSD...

I love the idea of using the slow mirror capability of mdraid although I
don't know if it's still there. Also I see from your responses you had
no idea that even exists and assumed mirroring takes care of this
automagically. There's also the thing about 2.5" drives that they're
almost exclusively SMR now which means super slow writes, really bad for
mirroring.

I don't know what you expect to gain though? Up to date backup in case
of a specific kind of drive failure I guess? But what if you get the
kind of failure where both or your mirrors are crap? I actually had that
sort of thing happen on a RAID-6 array. Redundancy or mirroring not much
good if your data is crap. That's when backups are important.

> then a 751 GB partition.  I intend to put Debian system *and* /home on
> the 215 GB RAID1, but I would set all the XDG user dirs² on the 751 GB
> HDD partition.  I would have tmpfs on /tmp---I have read that long
> thread where someone alleged that moving /tmp to tmpfs makes it
> useless but I disagree.

Any link to this discussion? I really like tmpfs for /tmp but for
everything there's resistance to change first and foremost.

> Would all this be reasonable?

I suppose that's in the eye of the beholder. To me, simple would be
mounting the SSD on / and the HD on /stuff. Or just go with one large
SSD on / and do backups to external drive as you've done before.

In general, I wonder what Debian's policy is on Guix? Does it create a
FrankenDebian? I wonder the same about Debian-Multimedia too. Some
poeple seem to hate that, I use it for GPU accelerated ffmpeg for the
rare occasions when I need to encode video. And they package mplayer
too.

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[David Christensen]

On 12/8/21 6:27 AM, Jorge P. de Morais Neto wrote:

Hi everyone!  I have a Dell Inspiron 5570 laptop with 1TB HDD and 16 GiB
RAM (it supports 32 GiB).  I am about to buy an M.2 NVMe 250GB SSD---a
Western Digital WD Blue SN550.  I would like to set the system for
reliability, SSD durability¹ and performance.

I have looked at [Multi HDD/SSD Partitioning Scheme][] but it is too
complex and probably outdated (last modified 2013-10-17).  I would like
something simpler.  For backups, I would continue my weekly manual
backups to my 1.5 TB external HDD with duplicity.

On the SSD I intend to leave 35 GB unpartitioned for extra over
provisioning.  It would have just one 215 GB partition.

On the HDD I would put a 34 GB swap partition at the beginning, then a
215 GB partition for RAID1 with the SSD, then a 751 GB partition.  I
intend to put Debian system *and* /home on the 215 GB RAID1, but I would
set all the XDG user dirs² on the 751 GB HDD partition.  I would have
tmpfs on /tmp---I have read that long thread where someone alleged that
moving /tmp to tmpfs makes it useless but I disagree.

Would all this be reasonable?  Do you recommend any change?  Any tip?  I
run Debian stable with only official repositories, including
bullseye-backports.  I also manually installed GNU Guix package manager
and my main Guix profile has 163 packages.

Regards!

[Multi HDD/SSD Partitioning Scheme] 
https://wiki.debian.org/Multi%20HDD/SSD%20Partition%20Scheme

¹ According to its data sheet, the 250GB WD Blue SN550 endures 150TBW.
² See the xdg-user-dir manpage.



I would remove the 1 TB HDD, install the 250 GB NVMe SSD, and do a fresh 
install of Debian 11 with MBR partitioning, 1E+9 byte boot partition 
(ext4), 1E+9 byte swap partition (random key encrypted), and 13E+9 to 
27E+9 byte root partition (passphrase encrypted ext4).  (E.g. partition 
table and first three partitions fit onto a "16 GB" to "30 GB" device.) 
 Once the system is built, I would add a fourth partition (key file 
encrypted ext4) using all remaining space for development, audio/ video 
working and "scratch" files, VM's, etc..



Over-provisioning was a big deal when SSD's first came out.  I would not 
worry about it on that laptop with that SSD.  If you do have an app with 
an intensive and sustained write workload, build a specific computer.



I would put the 1 TB HDD into an external HDD enclosure and use it to 
store system images (e.g. partition table, boot, swap, and root).  I 
take images of all of my system drives every month, and retain images 
for a few months.  You will need a USB flash drive with a Debian 
installation, or some live distribution (e.g. Debian Live, Clonezilla, 
etc.), to take and restore images.



I backup daily.


I recommend a file server or NAS for bulk data -- downloads, music, 
photographs, videos, etc..  Set up a VPN for remote access.



(Windows has Offline Files.  Does Debian GNU/Linux?)


I recommend a version control server for user project files and system 
configuration files.



(My SOHO server runs both of the above services in VM's.  Storage is RAID.)


David

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[Andy Smith]

Hello,

On Thu, Dec 09, 2021 at 05:14:09AM +0500, Alexander V. Makartsev wrote:
> Bottom line, there is a high probability that your SSD will work fine for
> many years and if/when it will die for whatever reason, just replace it and
> recover data (or a whole system) from backups.

OP: I agree with this, For typical desktop home use it is not worth
worrying about write endurance these days. Not unless your workload
is unusual or you went out of your way to pick an NVMe device with
very low write endurance, which you have not: 250GB WD Blue SN550 rated
for 150TBW.

If you are still worried you could partition just half of it and use
it as a physical volume for LVM, which you might want to do anyway
to encrypt it (LUKS), Then over time you can see how much you have
written, how much life is left etc. and decide then whether to leave
it over-provisioned or extend the LVM further. It leaves your
options open.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[Alexander V. Makartsev]

On 08.12.2021 19:27, Jorge P. de Morais Neto wrote:

Hi everyone!  I have a Dell Inspiron 5570 laptop with 1TB HDD and 16 GiB
RAM (it supports 32 GiB).  I am about to buy an M.2 NVMe 250GB SSD---a
Western Digital WD Blue SN550.  I would like to set the system for
reliability, SSD durability¹ and performance.

I have looked at [Multi HDD/SSD Partitioning Scheme][] but it is too
complex and probably outdated (last modified 2013-10-17).  I would like
something simpler.  For backups, I would continue my weekly manual
backups to my 1.5 TB external HDD with duplicity.

On the SSD I intend to leave 35 GB unpartitioned for extra over
provisioning.  It would have just one 215 GB partition.

On the HDD I would put a 34 GB swap partition at the beginning, then a
215 GB partition for RAID1 with the SSD, then a 751 GB partition.  I
intend to put Debian system *and* /home on the 215 GB RAID1, but I would
set all the XDG user dirs² on the 751 GB HDD partition.  I would have
tmpfs on /tmp---I have read that long thread where someone alleged that
moving /tmp to tmpfs makes it useless but I disagree.

Would all this be reasonable?  Do you recommend any change?  Any tip?  I
run Debian stable with only official repositories, including
bullseye-backports.  I also manually installed GNU Guix package manager
and my main Guix profile has 163 packages.
I'd advise against doing extra over-provisioning and making /swap on 
slow HDD.

IMO it is a thing of the past, especially on a home\personal computer.
Modern NAND technology and provisioning algorithms made SSDs quite 
resilient.
It is more likely that a controller IC will fail than a NAND ICs will 
wear off themselves during mild daily usage.


I have a few dozen of SSD devices to back up my personal experience and 
have access to information about two of them right now:
First model is "SKC400S37256G" made by Kingston. It is a 256GB SSD based 
on 2D MLC-2bit NAND and rated 300TBW.
It is working inside a home PC as a system drive with swap and /home on 
it. Manual TRIM once in 1-3 months. PC always shuts down (no hibernation).
According to SMART, it is working for 28132 hours¹ (3,2y) and has 98% 
life left².
Second model is "SHFS37A120G" made by Kingston. It is a 120GB SSD based 
on 2D MLC-2bit NAND and rated 354TBW.
It is working 24/7 inside a SOHO server as a system drive with swap on 
it. /home is on another disk.
According to SMART, it is working for 48810 hours (5,5y) and has 94% 
life left.


So, if you plan to use NVMe SSD as a system drive, I suggest you also 
keep /swap partition and /home on it for a maximum system and apps 
performance, and monitor it with smartmontools.
If you still want to save on its life you can always make symlinks for 
write-intensive, but not important, directories, like Downloads, to the HDD.
Also, I suggest you to make backups of /home on daily schedule to HDD, 
because data recovery from a failed SSD is not only very expensive, but 
often also next to impossible.
Bottom line, there is a high probability that your SSD will work fine 
for many years and if/when it will die for whatever reason, just replace 
it and recover data (or a whole system) from backups.



¹ Attribute #9 - Power_ On_Hours.
² Attribute #231 - SSD_Life_Left.

--
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[piorunz]

On 08/12/2021 19:35, Jorge P. de Morais Neto wrote:

Hi.  Thank you for your response.

Em [2021-12-08 qua 14:49:50+], piorunz escreveu:


I understand you have one SATA 2.5" slot in your laptop and one NVMe
slot, and you want to utilize them both.


That is correct.


On the SSD I intend to leave 35 GB unpartitioned for extra over
provisioning.  It would have just one 215 GB partition.


Leave more overprovisioning if you can. Use Btrfs with zstd compression
for your / and /home, you will gain many gigabytes.


How much overprovisioning would you recommend?  I can probably afford
more indeed (because of the 1 TB HDD), but excessive overprovisioning
could increase the risk of the system failing due to lack of disk space
during some important task.  Also, I heard that Linux filesystems like
having some reasonable (some say 10%) internal (within the filesystem)
free space.


As much as you can spare. Of course give any filesystem on NVMe a space
to breathe. It's up to you.




This doesn't make any sense.  Don't run RAID1 SSD+HDD.  You will kill
all gains SSD NVMe provides.


I lack RAID experience, but I assumed the kernel would easily be smart
enough to read from the fastest RAID member (SSD), so read performance
would be great.  And I hoped the kernel would also be smart enough to,
on writes, write to the SSD first and later (asynchronously) replicate
to the HDD.  But now a quick web search indeed suggests that those
optimizations are not default or common, so we can drop the RAID idea.


This is due to mdadm, not Linux kernel. You were going to use mdadm,
correct?
async writes may be possible in a way you described, but don't bet it
will be working like that out of the box. Out of the box, with mdadm,
you will have performance of HDD, no gains whatsoever.


- noatime: I didn't know about this issue, I thought relatime was
   efficient enough.  Thank you for the tip!


You are welcome!


- nodiratime: According to the mount manpage, noatime implies
   nodiratime.


It' been long time since I review this. I will check again and fix my
own mount options if this is not necessary :) Thanks.


- ssd: Does btrfs not autodetect SSD?  Why provide ssd option?


I am not sure if Btrfs autodetects SSD. SSD mode is enabling some
optimizations. If you decide to read on it, please share if you find
anything.


- Why `compress-force' instead of simply `compress'?


I've read very extensive discussion about that and came to conclusion
that compress-force is better. It's checking every chunk of file for
compressibility. "compress", on the other hand, checks only first
sectors, then drops compression if no compressible data is detected.
Imagine your qcow file, first 1 GB is not compressible, so "compress"
option will drop compression of that file right away. But remaining 20GB
are zeros because you haven't filled that yet. With compress-force, you
compress these zeros to nothing. File takes 1GB of space. You don't have
that on ext4, or btrfs "compress" only option.


For more context, my DE is Gnome and some of my most often used
applications are:

- GNU Emacs
- notmuch and offlineimap (I am considering switching to mbsync)
- GNU IceCat and Mozilla Firefox
- Gajim and GNU Jami
- Nextcloud (it is always running but rarely syncing changes)
- Gnome Boxes or Virtual Machine Manager running a VM with 2 GiB RAM and
   one .qcow2 disk image currently weighting 24 GB.

Kind regards!


In your use case, I would use partitioning suggested earlier. Place
Virtual Machine Manager images folder on HDD. Your / and /home will be
very small and totally manageable, while select folders like VMM images,
will live on HDD. Then all backups are up to you, but you not losing any
speed of your brand new NVMe.

--
With kindest regards, Piotr.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[Jorge P . de Morais Neto]

Hi.  Thank you for your response.

Em [2021-12-08 qua 14:49:50+], piorunz escreveu:

> I understand you have one SATA 2.5" slot in your laptop and one NVMe
> slot, and you want to utilize them both.

That is correct.

>> On the SSD I intend to leave 35 GB unpartitioned for extra over
>> provisioning.  It would have just one 215 GB partition.
>
> Leave more overprovisioning if you can. Use Btrfs with zstd compression
> for your / and /home, you will gain many gigabytes.

How much overprovisioning would you recommend?  I can probably afford
more indeed (because of the 1 TB HDD), but excessive overprovisioning
could increase the risk of the system failing due to lack of disk space
during some important task.  Also, I heard that Linux filesystems like
having some reasonable (some say 10%) internal (within the filesystem)
free space.

> This doesn't make any sense.  Don't run RAID1 SSD+HDD.  You will kill
> all gains SSD NVMe provides.

I lack RAID experience, but I assumed the kernel would easily be smart
enough to read from the fastest RAID member (SSD), so read performance
would be great.  And I hoped the kernel would also be smart enough to,
on writes, write to the SSD first and later (asynchronously) replicate
to the HDD.  But now a quick web search indeed suggests that those
optimizations are not default or common, so we can drop the RAID idea.

> / on NVMe Btrfs
> noatime,nodiratime,space_cache=v2,ssd,compress-force=zstd:6,subvol=@
>
> /home on NVMe Btrfs
> noatime,nodiratime,space_cache=v2,ssd,compress-force=zstd:6,subvol=@home

About those options:

- noatime: I didn't know about this issue, I thought relatime was
  efficient enough.  Thank you for the tip!
- nodiratime: According to the mount manpage, noatime implies
  nodiratime.
- ssd: Does btrfs not autodetect SSD?  Why provide ssd option?
- Why `compress-force' instead of simply `compress'?


For more context, my DE is Gnome and some of my most often used
applications are:

- GNU Emacs
- notmuch and offlineimap (I am considering switching to mbsync)
- GNU IceCat and Mozilla Firefox
- Gajim and GNU Jami
- Nextcloud (it is always running but rarely syncing changes)
- Gnome Boxes or Virtual Machine Manager running a VM with 2 GiB RAM and
  one .qcow2 disk image currently weighting 24 GB.

Kind regards!

-- 
- Many people hate injustice but few check the facts; this causes more
  injustice.  Ask me about 
- I am Brazilian.  I hope my English is correct and I welcome feedback.
- Free Software Supporter: https://www.fsf.org/free-software-supporter
- If an email of mine arrives at your spam box, please notify me.

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[piorunz]

On 08/12/2021 14:27, Jorge P. de Morais Neto wrote:

I understand you have one SATA 2.5" slot in your laptop and one NVMe
slot, and you want to utilize them both. My post below work on this
assumption.


For backups, I would continue my weekly manual
backups to my 1.5 TB external HDD with duplicity.



On the SSD I intend to leave 35 GB unpartitioned for extra over
provisioning.  It would have just one 215 GB partition.


Leave more overprovisioning if you can. Use Btrfs with zstd compression
for your / and /home, you will gain many gigabytes.


On the HDD I would put a 34 GB swap partition at the beginning, then a
215 GB partition for RAID1 with the SSD, then a 751 GB partition.


This doesn't make any sense. Don't run RAID1 SSD+HDD. You will kill all
gains SSD NVMe provides. 1TB 2.5" are totally slow and it will kill your
productivity. You may as well not be buying any NVMe if you are to use
it with RAID1 with spinning rust. Just run even hourly, or daily,
backups, rsyncs, or whatever tool you want to use, but don't run them
online as RAID1 together.


intend to put Debian system*and*  /home on the 215 GB RAID1, but I would
set all the XDG user dirs² on the 751 GB HDD partition


If I were you, I'd do as follows:

/ on NVMe Btrfs
noatime,nodiratime,space_cache=v2,ssd,compress-force=zstd:6,subvol=@

/home on NVMe Btrfs
noatime,nodiratime,space_cache=v2,ssd,compress-force=zstd:6,subvol=@home

/home/user/folder - that would be whatever is really big and you can't
fit it in SSD /home - make it your Videos, Steam games, your
storage-hungry app - put that as: HDD
noatime,nodiratime,space_cache=v2,compress-force=zstd:6,subvol=@hddfolder1
and mount that in fstab as your /home/user/folder

That way you have small /, bigger /home, both on SSD, and massive,
specific folders on HDD. Everything with compression on the fly. If you
have very slow CPU, decrease zstd compression to 3. If you really need
battery life, and don't want any extra CPU cycles, disable it.

Do the rest as you please, swap, tmp etc. Configure daily, weekly,
hourly rsync to copy everything on / and /home to HDD separate
partitions. That way if you NVMe dies you can plug new one, copy
everything back to it and start again.

Another option (I wouldn't do it, but here you go) is to replace 1TB HDD
for 1TB SSD. You can pair it with NVMe, it will be slower a bit, but not
that slow like RAID1 NVMe+HDD setup would be.

--
With kindest regards, Piotr.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄