Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #242773 > unrolled thread

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

Back to article view | Back to linux.debian.user

Contents

  Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD "Jorge P. de Morais Neto" <jorge+list@disroot.org> - 2021-12-08 15:30 +0100
    Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD piorunz <piorunz@gmx.com> - 2021-12-08 16:00 +0100
      Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD Jorge P. de Morais Neto <jorge+list@disroot.org> - 2021-12-08 20:40 +0100
        Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD piorunz <piorunz@gmx.com> - 2021-12-09 00:00 +0100
          Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD Jorge P. de Morais Neto <jorge+list@disroot.org> - 2022-01-02 17:40 +0100
            Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD piorunz <piorunz@gmx.com> - 2022-01-03 00:40 +0100
              Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD Jorge P. de Morais Neto <jorge+list@disroot.org> - 2022-01-03 12:50 +0100
                Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD Michael Stone <mstone@debian.org> - 2022-01-03 16:20 +0100
                  Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD Dan Ritter <dsr@randomstring.org> - 2022-01-03 17:00 +0100
                    Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD Michael Stone <mstone@debian.org> - 2022-01-03 19:30 +0100
                  Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD Jorge P. de Morais Neto <jorge+list@disroot.org> - 2022-01-04 01:00 +0100
                    Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD Michael Stone <mstone@debian.org> - 2022-01-04 19:20 +0100
        Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD piorunz <piorunz@gmx.com> - 2021-12-09 14:30 +0100
    Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD "Alexander V. Makartsev" <avbetev@gmail.com> - 2021-12-09 01:20 +0100
      Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD Andy Smith <andy@strugglers.net> - 2021-12-09 02:10 +0100
        Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD Jorge P. de Morais Neto <jorge+list@disroot.org> - 2021-12-15 15:50 +0100
          Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD Andy Smith <andy@strugglers.net> - 2021-12-16 04:30 +0100
      Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD piorunz <piorunz@gmx.com> - 2021-12-09 11:30 +0100
        Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD "Alexander V. Makartsev" <avbetev@gmail.com> - 2021-12-09 16:30 +0100
          Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD piorunz <piorunz@gmx.com> - 2021-12-09 17:20 +0100
            Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD piorunz <piorunz@gmx.com> - 2021-12-09 18:30 +0100
      Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD Jorge P. de Morais Neto <jorge+list@disroot.org> - 2021-12-15 15:40 +0100
    Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD David Christensen <dpchrist@holgerdanske.com> - 2021-12-09 07:10 +0100
      Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD Jorge P. de Morais Neto <jorge+list@disroot.org> - 2021-12-14 18:50 +0100
        Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD David Christensen <dpchrist@holgerdanske.com> - 2021-12-15 03:50 +0100
          Re: Why MBR partitioning (was: Reasonably simple setup for 1...) Felix Miata <mrmazda@earthlink.net> - 2021-12-15 04:00 +0100
            Re: Why MBR partitioning (was: Reasonably simple setup for 1...) David Christensen <dpchrist@holgerdanske.com> - 2021-12-15 05:20 +0100
            Re: Why MBR partitioning (was: Reasonably simple setup for 1...) "Thomas Schmitt" <scdbackup@gmx.net> - 2021-12-15 09:10 +0100
    Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD Anssi Saari <as@sci.fi> - 2021-12-09 10:40 +0100
      Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD Dan Ritter <dsr@randomstring.org> - 2021-12-09 13:10 +0100
      Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD Jorge P. de Morais Neto <jorge+list@disroot.org> - 2021-12-14 18:40 +0100
        Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD Andrei POPESCU <andreimpopescu@gmail.com> - 2021-12-15 21:30 +0100
    Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD "hdv@gmail" <hdv.jadev@gmail.com> - 2021-12-09 15:10 +0100
      Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD Dan Ritter <dsr@randomstring.org> - 2021-12-09 16:10 +0100
        Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD "hdv@gmail" <hdv.jadev@gmail.com> - 2021-12-09 16:50 +0100
          Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD Curt <curty@free.fr> - 2021-12-09 18:30 +0100
            Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD David Wright <deblis@lionunicorn.co.uk> - 2021-12-10 06:00 +0100
              Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD Darac Marjal <mailinglist@darac.org.uk> - 2021-12-10 10:30 +0100
        Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD Stefan Monnier <monnier@iro.umontreal.ca> - 2021-12-10 05:10 +0100
        Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD Andrei POPESCU <andreimpopescu@gmail.com> - 2021-12-10 10:40 +0100
          Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD Dan Ritter <dsr@randomstring.org> - 2021-12-10 13:40 +0100
            Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD Andrei POPESCU <andreimpopescu@gmail.com> - 2021-12-10 14:00 +0100
              Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD Dan Ritter <dsr@randomstring.org> - 2021-12-10 15:10 +0100
                Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD Charles Curley <charlescurley@charlescurley.com> - 2021-12-11 02:10 +0100
                  Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD "Andrew M.A. Cater" <amacater@einval.com> - 2021-12-11 12:30 +0100
            Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD Darac Marjal <mailinglist@darac.org.uk> - 2021-12-10 14:20 +0100
      Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD Jorge P. de Morais Neto <jorge+list@disroot.org> - 2021-12-15 16:00 +0100
        Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD "hdv@gmail" <hdv.jadev@gmail.com> - 2021-12-15 16:30 +0100

Page 1 of 3  [1] 2 3  Next page →

#242773 — Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

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.

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

[toc] | [next] | [standalone]

#242776

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/
⠈⠳⣄⠀⠀⠀⠀

[toc] | [prev] | [next] | [standalone]

#242783

Hi.  Thank you for your response.

Em [2021-12-08 qua 14:49:50+0000], 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 <https://stallmansupport.org>
- 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.

[toc] | [prev] | [next] | [standalone]

#242786

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+0000], 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/
⠈⠳⣄⠀⠀⠀⠀

[toc] | [prev] | [next] | [standalone]

#243584

Hi Piotr!  Happy 2022!

Em [2021-12-08 qua 22:54:29+0000], 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 <https://stallmansupport.org>
- I am Brazilian.  I hope my English is correct and I welcome feedback.
- https://www.defectivebydesign.org
- https://www.gnu.org

[toc] | [prev] | [next] | [standalone]

#243592

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/
⠈⠳⣄⠀⠀⠀⠀

[toc] | [prev] | [next] | [standalone]

#243627

Em [2022-01-02 dom 23:38:48+0000], 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 <https://stallmansupport.org>
- 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?"

[toc] | [prev] | [next] | [standalone]

#243631

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.

[toc] | [prev] | [next] | [standalone]

#243632

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-

[toc] | [prev] | [next] | [standalone]

#243634

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.

[toc] | [prev] | [next] | [standalone]

#243661

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 <https://stallmansupport.org>
- I am Brazilian.  I hope my English is correct and I welcome feedback.
- https://www.defectivebydesign.org
- https://www.gnu.org

[toc] | [prev] | [next] | [standalone]

#243688

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.

[toc] | [prev] | [next] | [standalone]

#242801

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/
⠈⠳⣄⠀⠀⠀⠀

[toc] | [prev] | [next] | [standalone]

#242787

[Multipart message — attachments visible in raw view] — view raw

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
⠈⠳⣄⠀⠀⠀⠀

[toc] | [prev] | [next] | [standalone]

#242791

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

[toc] | [prev] | [next] | [standalone]

#243140

Hello,

Em [2021-12-09 qui 01:02:17+0000], 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 <https://stallmansupport.org>
- 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?"

[toc] | [prev] | [next] | [standalone]

#243159

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

[toc] | [prev] | [next] | [standalone]

#242797

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/
⠈⠳⣄⠀⠀⠀⠀

[toc] | [prev] | [next] | [standalone]

#242807

[Multipart message — attachments visible in raw view] — view raw

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
⠈⠳⣄⠀⠀⠀⠀

[toc] | [prev] | [next] | [standalone]

#242811

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/
⠈⠳⣄⠀⠀⠀⠀

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | linux.debian.user

csiph-web