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

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

mdadm usage

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

Contents

  mdadm usage "Thomas A. Anderson" <thomas.anderson@little-beak.com> - 2020-12-29 08:10 +0100
    Re: mdadm usage Reco <recoverym4n@enotuniq.net> - 2020-12-29 08:30 +0100
      Re: mdadm usage deloptes <deloptes@gmail.com> - 2020-12-29 09:40 +0100
    Re: mdadm usage Felix Miata <mrmazda@earthlink.net> - 2020-12-29 08:50 +0100
      Re: mdadm usage basti <mailinglist@unix-solution.de> - 2020-12-29 09:40 +0100
        Re: mdadm usage "Thomas A. Anderson" <thomas.anderson@little-beak.com> - 2020-12-29 21:40 +0100
          Re: mdadm usage Linux-Fan <Ma_Sys.ma@web.de> - 2020-12-30 00:00 +0100
          Re: mdadm usage deloptes <deloptes@gmail.com> - 2020-12-30 02:00 +0100
            Re: mdadm usage Michael Stone <mstone@debian.org> - 2020-12-30 02:30 +0100
              Re: mdadm usage deloptes <deloptes@gmail.com> - 2020-12-30 09:20 +0100
              Re: mdadm usage Jesper Dybdal <jd-debian-user@dybdal.dk> - 2020-12-30 14:40 +0100
                Re: mdadm usage Andy Smith <andy@strugglers.net> - 2020-12-30 15:00 +0100
                  Re: mdadm usage Jesper Dybdal <jd-debian-user@dybdal.dk> - 2021-01-02 14:40 +0100
                mdadm usage Nicholas Geovanis <nickgeovanis@gmail.com> - 2020-12-30 15:10 +0100
                  Re: mdadm usage Nicholas Geovanis <nickgeovanis@gmail.com> - 2020-12-30 15:10 +0100
                    Re: mdadm usage deloptes <deloptes@gmail.com> - 2020-12-30 21:50 +0100
                      Re: mdadm usage Michael Stone <mstone@debian.org> - 2020-12-30 22:40 +0100
                        Re: mdadm usage deloptes <deloptes@gmail.com> - 2020-12-30 23:20 +0100
                          Re: mdadm usage Andy Smith <andy@strugglers.net> - 2020-12-31 00:30 +0100
                            Re: mdadm usage rhkramer@gmail.com - 2020-12-31 13:30 +0100
                              Re: mdadm usage Michael Stone <mstone@debian.org> - 2020-12-31 15:20 +0100
                                Re: mdadm usage Andy Smith <andy@strugglers.net> - 2020-12-31 15:30 +0100
                          Re: mdadm usage Reco <recoverym4n@enotuniq.net> - 2020-12-31 15:50 +0100
                            Re: mdadm usage Andy Smith <andy@strugglers.net> - 2020-12-31 16:10 +0100
                              Re: mdadm usage Reco <recoverym4n@enotuniq.net> - 2020-12-31 16:20 +0100
                                Re: mdadm usage Andy Smith <andy@strugglers.net> - 2020-12-31 16:40 +0100
                                  Re: mdadm usage deloptes <deloptes@gmail.com> - 2021-01-01 23:10 +0100
                                    Re: mdadm usage Andrei POPESCU <andreimpopescu@gmail.com> - 2021-01-02 09:40 +0100
                                      Re: mdadm usage deloptes <deloptes@gmail.com> - 2021-01-02 10:10 +0100
                                        Re: mdadm usage Andrei POPESCU <andreimpopescu@gmail.com> - 2021-01-02 11:30 +0100
                                        Re: mdadm usage Linux-Fan <Ma_Sys.ma@web.de> - 2021-01-02 14:50 +0100
                                          Re: mdadm usage deloptes <deloptes@gmail.com> - 2021-01-02 16:40 +0100
                                            Re: mdadm usage Linux-Fan <Ma_Sys.ma@web.de> - 2021-01-02 18:10 +0100
                                      Re: mdadm usage The Wanderer <wanderer@fastmail.fm> - 2021-01-02 10:40 +0100
                                        Re: mdadm usage Andrei POPESCU <andreimpopescu@gmail.com> - 2021-01-02 12:00 +0100
                                          Re: mdadm usage The Wanderer <wanderer@fastmail.fm> - 2021-01-02 12:30 +0100
                                            Re: mdadm usage Andrei POPESCU <andreimpopescu@gmail.com> - 2021-01-02 12:50 +0100
                                              Re: mdadm usage Andrei POPESCU <andreimpopescu@gmail.com> - 2021-01-02 13:10 +0100
                                                Re: mdadm usage The Wanderer <wanderer@fastmail.fm> - 2021-01-02 14:20 +0100
                                              Re: mdadm usage The Wanderer <wanderer@fastmail.fm> - 2021-01-02 14:10 +0100
                                          Re: mdadm usage deloptes <deloptes@gmail.com> - 2021-01-02 12:50 +0100
            Re: mdadm usage "Thomas A. Anderson" <thomas.anderson@little-beak.com> - 2020-12-30 11:50 +0100
              Re: mdadm usage "Alexander V. Makartsev" <avbetev@gmail.com> - 2020-12-30 13:30 +0100
              Re: mdadm usage Dan Ritter <dsr@randomstring.org> - 2020-12-30 13:30 +0100
              Re: mdadm usage Andy Smith <andy@strugglers.net> - 2020-12-30 15:00 +0100
              Re: mdadm usage deloptes <deloptes@gmail.com> - 2020-12-30 22:10 +0100
                Re: mdadm usage Nicholas Geovanis <nickgeovanis@gmail.com> - 2020-12-31 00:00 +0100
          Re: mdadm usage Andrei POPESCU <andreimpopescu@gmail.com> - 2020-12-30 09:10 +0100
        Re: mdadm usage Dan Ritter <dsr@randomstring.org> - 2020-12-30 04:00 +0100
    Re: mdadm usage Andy Smith <andy@strugglers.net> - 2020-12-29 14:20 +0100
      Re: mdadm usage mick crane <mick.crane@gmail.com> - 2020-12-29 16:40 +0100
        Re: mdadm usage "Alexander V. Makartsev" <avbetev@gmail.com> - 2020-12-29 20:40 +0100
        Re: mdadm usage Andy Smith <andy@strugglers.net> - 2020-12-30 14:40 +0100
          Re: mdadm usage The Wanderer <wanderer@fastmail.fm> - 2020-12-30 14:50 +0100
          Re: mdadm usage mick crane <mick.crane@gmail.com> - 2020-12-30 18:00 +0100
            Re: mdadm usage Andrei POPESCU <andreimpopescu@gmail.com> - 2020-12-30 19:40 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#230161

On Thu, Dec 31, 2020 at 07:25:54AM -0500, rhkramer@gmail.com wrote:
>What do you mean by power loss protection -- do you mean, for example, that
>the host computer is on a UPS, or is that a feature of some SSDs?

It's a feature of server SSDs. I wouldn't worry about it on a consumer 
device, especially if you have a UPS.

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

#230162

Hello,

On Thu, Dec 31, 2020 at 09:17:03AM -0500, Michael Stone wrote:
> On Thu, Dec 31, 2020 at 07:25:54AM -0500, rhkramer@gmail.com wrote:
> >What do you mean by power loss protection -- do you mean, for example, that
> >the host computer is on a UPS, or is that a feature of some SSDs?
> 
> It's a feature of server SSDs. I wouldn't worry about it on a consumer
> device, especially if you have a UPS.

Though OP did ask about NAS-quality SSDs for RAID use.

Cheers,
Andy

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

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

#230163

	Hi.

On Wed, Dec 30, 2020 at 11:14:37PM +0100, deloptes wrote:
> Can someone recommend server or NAS grade (SATA) SSD - a reliable one
> for RAID use?

It's a cheap model (relatively), and lack all those fancy BBU features,
but it works for my employer:

# smartctl -a /dev/sdj
...
Vendor:               SAMSUNG
Product:              MZILT1T9HAJQ/007
Revision:             GXF2
Compliance:           SPC-5
User Capacity:        1,920,383,410,176 bytes [1.92 TB]
Logical block size:   512 bytes
Physical block size:  4096 bytes
LU is resource provisioned, LBPRZ=1
Rotation Rate:        Solid State Device
Form Factor:          2.5 inches
Transport protocol:   SAS (SPL-3)
SMART support is:     Available - device has SMART capability.
SMART support is:     Enabled
Temperature Warning:  Enabled
...


Note that it's a SAS drive, not SATA.

Reco

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

#230164

Hello,

On Thu, Dec 31, 2020 at 05:42:35PM +0300, Reco wrote:
> It's a cheap model (relatively), and lack all those fancy BBU features,
> but it works for my employer:
> 
> # smartctl -a /dev/sdj
> ...
> Vendor:               SAMSUNG
> Product:              MZILT1T9HAJQ/007

Datasheet says:

* Enhanced Power-Loss Data Protection with Tantal capacitors

https://www.hyperscalers.com/image/catalog/!Petar/PM1643%202.5%20SAS%20SSD%20Datasheet_v1.0_for%20General%20(002).pdf

Also corroborated at:

    https://www.anandtech.com/show/12448/samsung-begins-mass-production-of-pm1643-sas-ssds-with-3072-tb-capacity

    "Some of the features of the PM1643 that Samsung is willing to
    discuss right now (metadata protection, power loss protection,
    data recovery, end-to-end data protection, encryption, etc.)
    confirm that the drives are indeed aimed at servers that require
    advanced reliability."

Cheers,
Andy

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

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

#230165

On Thu, Dec 31, 2020 at 03:06:34PM +0000, Andy Smith wrote:
> On Thu, Dec 31, 2020 at 05:42:35PM +0300, Reco wrote:
> > It's a cheap model (relatively), and lack all those fancy BBU features,
> > but it works for my employer:
> > 
> > # smartctl -a /dev/sdj
> > ...
> > Vendor:               SAMSUNG
> > Product:              MZILT1T9HAJQ/007
> 
> Datasheet says:
> 
> * Enhanced Power-Loss Data Protection with Tantal capacitors

It does not have a battery = it does not have a BBU.
Samsung can dance around that fact all they want, but it won't change.

The lack of BBU does not bother me though (there are backups for
worst-case scenarios), and that server is on UPS anyway. Possible
firmware bugs (these things are new, this unit was produced about a year
ago), and, of course, the scourge of modern Enterprise SSDs -
temperature loss - these I'm wary of.

Reco

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

#230166

Hello,

On Thu, Dec 31, 2020 at 06:18:29PM +0300, Reco wrote:
> On Thu, Dec 31, 2020 at 03:06:34PM +0000, Andy Smith wrote:
> > Datasheet says:
> > 
> > * Enhanced Power-Loss Data Protection with Tantal capacitors
> 
> It does not have a battery = it does not have a BBU.
> Samsung can dance around that fact all they want, but it won't change.

That is a really strange comment to me. No SSDs have batteries.
Almost no RAID cards have batteries anymore. Supercapacitors have
obsoleted the battery for such purposes. All SSD power loss
protection is supercaps. And if you try to buy a modern RAID card
with a BBU you will mostly just find cards with supercaps instead.
But OP was asking about SSDs not RAID cards so even that nuance
doesn't make much sense.

But okay, your SSD doesn't have pink elephants either. Samsung can
dance around that fact all they want.

Andy

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

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

#230212

Andy Smith wrote:

> That is a really strange comment to me. No SSDs have batteries.
> Almost no RAID cards have batteries anymore. Supercapacitors have
> obsoleted the battery for such purposes. All SSD power loss
> protection is supercaps. And if you try to buy a modern RAID card
> with a BBU you will mostly just find cards with supercaps instead.
> But OP was asking about SSDs not RAID cards so even that nuance
> doesn't make much sense.
> 
> But okay, your SSD doesn't have pink elephants either. Samsung can
> dance around that fact all they want.

I have LSI controllers that support SATA II. This is a custom build home
server (small business server) one friend assembled for me 8y ago.
It fits my needs perfectly well. I deliberately did not buy a server as they
consume much more power. This one is running at 70-80Watt when normal and
100-120 when for example compiling something. Also noise factor is very low
compared to a real server. Of course there are limits
(memory/CPU/periferals). The machine is on UPS - I don't care about tantal
super caps. 
Each LSI card has a 6 bay cage attached and I have raided 6x2TB WD RED
spinning discs (for data) and 2x1TB WD RED spinning discs (for OS)

I somehow can not convince myself that I need to replace any of these with
SSDs.
I don't want the cheapest but also not unnecessary expensive drives, I just
find it hard to evaluate which drives are reliable.

I saw there are 1TB WD RED SSDs targeting NAS for about €120,-
 WESTERN DIGITAL WD RED SA500 NAS 1TB SATA (WDS100T1R0A)

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

#230221

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

On Vi, 01 ian 21, 23:09:01, deloptes wrote:
>
> Each LSI card has a 6 bay cage attached and I have raided 6x2TB WD RED
> spinning discs (for data) and 2x1TB WD RED spinning discs (for OS)
 
1TB for OS (assuming RAID1) seems... excessive to me. All my current 
installations are in 10 GiB partitions with only a separate /home.

Even if I'd go "wild" with several desktops installed (I'm only using 
LXDE), LibreOffice, etc. I'd probably get away with 50 GiB or so. Check 
the output of:

    du -hx --max-depth=1 /

> I somehow can not convince myself that I need to replace any of these with
> SSDs.
> I don't want the cheapest but also not unnecessary expensive drives, I just
> find it hard to evaluate which drives are reliable.

The reliability matters much less with RAID1. By the way, the "I" in 
RAID stands for "inexpensive" ;)

If in doubt buy from two different manufacturers with similar specs. 
RAID devices should whenever possible be from different batches anyway.

> I saw there are 1TB WD RED SSDs targeting NAS for about €120,-
>  WESTERN DIGITAL WD RED SA500 NAS 1TB SATA (WDS100T1R0A)

The speed gain of SSD vs. spinning discs for the OS is hard to describe. 
Think jet aircraft vs. car.

I've done this for a laptop (partially out of necessity, after I dropped 
it) and it was like buying a new system, even if the processor was 
already significantly outdated at the time (one of the first non-Itanium 
Intel 64 bit processors).

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

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

#230227

Andrei POPESCU wrote:

>> Each LSI card has a 6 bay cage attached and I have raided 6x2TB WD RED
>> spinning discs (for data) and 2x1TB WD RED spinning discs (for OS)
> 
> 1TB for OS (assuming RAID1) seems... excessive to me. All my current
> installations are in 10 GiB partitions with only a separate /home.
> 
> Even if I'd go "wild" with several desktops installed (I'm only using
> LXDE), LibreOffice, etc. I'd probably get away with 50 GiB or so. Check
> the output of:
> 
> du -hx --max-depth=1 /
> 
This is true. the root partition is not big - the rest of the space I'll use
for data, but I do not want to use smaller disk, because I will loose two
bays and have the power consumption anyway. I think 1TB is good compromise.
I leave some disk space as spare for LVM and LVM snapshot. I put there the
OS and for example the NFS root/boot stuff or some QEMU machines.

>> I somehow can not convince myself that I need to replace any of these
>> with SSDs.
>> I don't want the cheapest but also not unnecessary expensive drives, I
>> just find it hard to evaluate which drives are reliable.
> 
> The reliability matters much less with RAID1. By the way, the "I" in
> RAID stands for "inexpensive" ;)
> 

For me it does not matter less, as I do not want to spent time. I had it
with Seagate disks before I moved to the WD RED NAS.

> If in doubt buy from two different manufacturers with similar specs.
> RAID devices should whenever possible be from different batches anyway.
> 

I am too old for blind experimenting. This is why I'm asking if someone has
experience with SSD in RAID with consumer grade disks. The once I see are
installed in servers are not available on the consumer market.

>> I saw there are 1TB WD RED SSDs targeting NAS for about €120,-
>> WESTERN DIGITAL WD RED SA500 NAS 1TB SATA (WDS100T1R0A)
> 
> The speed gain of SSD vs. spinning discs for the OS is hard to describe.
> Think jet aircraft vs. car.
> 
> I've done this for a laptop (partially out of necessity, after I dropped
> it) and it was like buying a new system, even if the processor was
> already significantly outdated at the time (one of the first non-Itanium
> Intel 64 bit processors).

Yes, but as mentioned the LSI I use in the server are SATA2 so it will stick
to bandwidth throughput of 300MB/s - does it make sense to replace the good
WD RED spinning disks with SSD?
I already heard one good argument.

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

#230234

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

On Sb, 02 ian 21, 10:05:11, deloptes wrote:
> Andrei POPESCU wrote:
> > 
> > The speed gain of SSD vs. spinning discs for the OS is hard to describe.
> > Think jet aircraft vs. car.
> > 
> > I've done this for a laptop (partially out of necessity, after I dropped
> > it) and it was like buying a new system, even if the processor was
> > already significantly outdated at the time (one of the first non-Itanium
> > Intel 64 bit processors).
> 
> Yes, but as mentioned the LSI I use in the server are SATA2 so it will stick
> to bandwidth throughput of 300MB/s - does it make sense to replace the good
> WD RED spinning disks with SSD?

Yes.

As far as I recall the laptop I mentioned above had SATA I only 
(definitely at least one SATA generation below the capability of the 
SSD) and the usability increase was huge.

When discussing "OS speed" the important difference between SSDs and 
HDDs is the random read speed, which is orders of magnitude higher.

Just compare for yourself the random read speed of your drives with the 
theoretical speed of SATA II. Now look at the random read speeds of some 
consumer SATA drives.

Even if the RAID1 helps with random read speeds, a single SSD will run 
circles around it. Over SATA II.

Sequential read / write speed matters only when copying large[1] files 
around. With smaller file sizes spinning drives waste a lot of time 
seeking. Add file fragmentation on top.

[1] for the purposes of this discussion let's consider "large" files to 
be files bigger than what your drives can transfer per second in real 
life, including the seek times. I'm hoping other readers will correct me 
if my assumption is way of.

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

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

#230252

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

deloptes writes:

> Andrei POPESCU wrote:
>
> >> Each LSI card has a 6 bay cage attached and I have raided 6x2TB WD RED
> >> spinning discs (for data) and 2x1TB WD RED spinning discs (for OS)
> >
> > 1TB for OS (assuming RAID1) seems... excessive to me. All my current
> > installations are in 10 GiB partitions with only a separate /home.
> >
> > Even if I'd go "wild" with several desktops installed (I'm only using
> > LXDE), LibreOffice, etc. I'd probably get away with 50 GiB or so. Check
> > the output of:
> >
> > du -hx --max-depth=1 /
> >
> This is true. the root partition is not big - the rest of the space I'll use
> for data, but I do not want to use smaller disk, because I will loose two
> bays and have the power consumption anyway. I think 1TB is good compromise.
> I leave some disk space as spare for LVM and LVM snapshot. I put there the
> OS and for example the NFS root/boot stuff or some QEMU machines.

Sounds OK to me :) From my point of view, I would work towards reducing the  
total number of disks, given that spinning disks of 8 TB capacity and SSDs  
of 4 TB capacity are readily available today. YMMV

> >> I somehow can not convince myself that I need to replace any of these
> >> with SSDs.
> >> I don't want the cheapest but also not unnecessary expensive drives, I
> >> just find it hard to evaluate which drives are reliable.
> >
> > The reliability matters much less with RAID1. By the way, the "I" in
> > RAID stands for "inexpensive" ;)

[...]

> I am too old for blind experimenting. This is why I'm asking if someone has
> experience with SSD in RAID with consumer grade disks. The once I see are
> installed in servers are not available on the consumer market.

If I understood it corretly, you initially asked about NAS-grade-SSDs. I  
believe that is quite "special" a purpose, because I tend to hink of NAS as  
slow but large storage spaces where SSDs are indeed rare.

I have had good experience with the following two "consumer-grade" SSDs in  
an mdadm RAID 1 (taking the I for inexpensive literally :) ). Both have  
about 8000 hours of operation according to SMART and when in use they ran  
about 12h/day (i.e. normally not 24/7):

 * Samsung 850 EVO 2TB
 * Crucial MX300 2TB

At the time, these were the cheapest SSDs I could get with 2TB. Despite  
their performance being "medicore" (for SSDs, that is), there were no  
problems with RAID operation whatsoever.

For my new system, I got two Intel DC P4510. These were actually available  
to me as a "consumer" despite them being (old) "datacenter" SSDs. They run  
much faster, but most of the time one does not notice the difference. My  
typical workload that benefits from the "faster" SSDs is installing packages  
and updates in multiple VMs and containers (e.g. 4--6 VMs and two  
containers) at once. Apart from the potential difficulties in getting to  
purchase such SSDs, they are also more difficult to put into systems due to  
different connectors: Server SSDs use either SAS or (in case of the DC  
P4510): U.2.

> >> I saw there are 1TB WD RED SSDs targeting NAS for about €120,-
> >> WESTERN DIGITAL WD RED SA500 NAS 1TB SATA (WDS100T1R0A)
> >
> > The speed gain of SSD vs. spinning discs for the OS is hard to describe.
> > Think jet aircraft vs. car.

[...]

> Yes, but as mentioned the LSI I use in the server are SATA2 so it will stick
> to bandwidth throughput of 300MB/s - does it make sense to replace the good
> WD RED spinning disks with SSD?
> I already heard one good argument.

How much do you rely on random access to the actual data? As others have  
already posted, putting an OS onto the SSD is an exceptional performance  
gain for all OS-startup related tasks including "running program x for the  
first time" or OS upgrades (apt-get operations in general). If, however, you  
are considering to use the SSD mostly for "data", it highly depends on what  
type of data you have:

 * If it is os-style data like VMs, containers, compiler toolchains, chroots
   etc. then there will be a significant performance improvement, because
   these all benefit from reduced latency of access.

 * If it is media like music, pictures etc. served over a typical network
   protocl, the performance of HDDs may be entirely sufficient. Some
   media-related tasks like "downscale 10000 images from 700x700 to 500x500"
   may also benefit from the SSD if files are small enough that the access
   time becomes relevant.

 * Additionally, if you have a small set of data that you are accessing all
   of the time and the OS manages to cache this into RAM, you will only
   benefit from the SSD performance upon first access. On systems that run
   24/7, the benefit of SSDs is gerater in database-style continouously
   random-access-intensive applications rather than typical file access
   patterns.

As others have noted, the performance gain of SSDs is largely independent of  
connector. You can get an improvement even on old connectors and to some  
extent also on old systems. Unless you are thinking of using IDE SSDs  
(special-purpose devices which are mostly _not_ used for performance),  
everything should be fine in that regard :)

HTH
Linux-Fan

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

#230258

Linux-Fan wrote:

> deloptes writes:
> 
>> Andrei POPESCU wrote:
>>
>> >> Each LSI card has a 6 bay cage attached and I have raided 6x2TB WD RED
>> >> spinning discs (for data) and 2x1TB WD RED spinning discs (for OS)
>> >
>> > 1TB for OS (assuming RAID1) seems... excessive to me. All my current
>> > installations are in 10 GiB partitions with only a separate /home.
>> >
>> > Even if I'd go "wild" with several desktops installed (I'm only using
>> > LXDE), LibreOffice, etc. I'd probably get away with 50 GiB or so. Check
>> > the output of:
>> >
>> > du -hx --max-depth=1 /
>> >
>> This is true. the root partition is not big - the rest of the space I'll
>> use for data, but I do not want to use smaller disk, because I will loose
>> two bays and have the power consumption anyway. I think 1TB is good
>> compromise. I leave some disk space as spare for LVM and LVM snapshot. I
>> put there the OS and for example the NFS root/boot stuff or some QEMU
>> machines.
> 
> Sounds OK to me :) From my point of view, I would work towards reducing
> the total number of disks, given that spinning disks of 8 TB capacity and
> SSDs of 4 TB capacity are readily available today. YMMV
> 

Yes, but the prices of these SSDs are very high compared to spinning disks.
When looking at the bigger WD RED disks (3-4TB) few years ago I found out
many people complained that disks do not have same quality as 2TB WD RED,
so I stick to those despite I could have saved at least 2bays. I still have
4 unused bays anyway. The only thing is the power consumption ... would be
at least 10W less ... but it is neglectable.

>> >> I somehow can not convince myself that I need to replace any of these
>> >> with SSDs.
>> >> I don't want the cheapest but also not unnecessary expensive drives, I
>> >> just find it hard to evaluate which drives are reliable.
>> >
>> > The reliability matters much less with RAID1. By the way, the "I" in
>> > RAID stands for "inexpensive" ;)
> 
> [...]
> 
>> I am too old for blind experimenting. This is why I'm asking if someone
>> has experience with SSD in RAID with consumer grade disks. The once I see
>> are installed in servers are not available on the consumer market.
> 
> If I understood it corretly, you initially asked about NAS-grade-SSDs. I
> believe that is quite "special" a purpose, because I tend to hink of NAS
> as slow but large storage spaces where SSDs are indeed rare.
> 

Yes I asked may be incorrectly - I use the WD RED NAS spinning disks and I
look a replacement for that. Most of the data is NAS grade data
(moves/music/documents) - a lot of read, but almost no write.
Virtual machines and development are a different type of data - I have them
on different pair of disks.
For these I also look for a replacement, but as mentioned it costs (2TB SSD
is about €250,-) and I think I would gain something, but given the LSI SATA
II controllers, I was not sure if it would indeed pay off.
After this discussion, I understand it is worth considering and it would pay
off. This is why I ask for recommendations - might be I correct to
replacement for both types. I must admit I now conclude considering putting
dedicated disks for development, VMs and OS (like SSDs - may be better buy
2 3TB SSDs and replace the 2x1 and 2x2TB WD RED NAS) or replace just the
2x1TB with SSDs for OS and VMs as for the development I do not care
compiling takes 20% more time.

> I have had good experience with the following two "consumer-grade" SSDs in
> an mdadm RAID 1 (taking the I for inexpensive literally :) ). Both have
> about 8000 hours of operation according to SMART and when in use they ran
> about 12h/day (i.e. normally not 24/7):
> 
> * Samsung 850 EVO 2TB
> * Crucial MX300 2TB
> 
> At the time, these were the cheapest SSDs I could get with 2TB. Despite
> their performance being "medicore" (for SSDs, that is), there were no
> problems with RAID operation whatsoever.
> 

Thank you this is what I am looking for -personal experience. I have been
looking at the Samsung 850 EVO 2TB. Can you share the exact model number,
please?

=== START OF INFORMATION SECTION ===
Model Family:     Western Digital Red
Device Model:     WDC WD20EFRX-68EUZN0

As mentioned before I had issues with Seagate drives - they failed
constantly - making me nervous - I had to keep always one spare around for
years - until I decommissioned the last one. Amazingly this last one worked
for 12y - was 500GB Seagate drive.

> For my new system, I got two Intel DC P4510. These were actually available
> to me as a "consumer" despite them being (old) "datacenter" SSDs. They run
> much faster, but most of the time one does not notice the difference. My
> typical workload that benefits from the "faster" SSDs is installing
> packages and updates in multiple VMs and containers (e.g. 4--6 VMs and two
> containers) at once. Apart from the potential difficulties in getting to
> purchase such SSDs, they are also more difficult to put into systems due
> to different connectors: Server SSDs use either SAS or (in case of the DC
> P4510): U.2.
> 

Well - you say new system - It is nice story, but I have the limitations I
already listed before.

>> >> I saw there are 1TB WD RED SSDs targeting NAS for about €120,-
>> >> WESTERN DIGITAL WD RED SA500 NAS 1TB SATA (WDS100T1R0A)
>> >
>> > The speed gain of SSD vs. spinning discs for the OS is hard to
>> > describe. Think jet aircraft vs. car.
> 
> [...]
> 
>> Yes, but as mentioned the LSI I use in the server are SATA2 so it will
>> stick to bandwidth throughput of 300MB/s - does it make sense to replace
>> the good WD RED spinning disks with SSD?
>> I already heard one good argument.
> 
> How much do you rely on random access to the actual data? As others have
> already posted, putting an OS onto the SSD is an exceptional performance
> gain for all OS-startup related tasks including "running program x for the
> first time" or OS upgrades (apt-get operations in general). If, however,
> you are considering to use the SSD mostly for "data", it highly depends on
> what type of data you have:
> 
> * If it is os-style data like VMs, containers, compiler toolchains,
> chroots etc. then there will be a significant performance improvement,
> because these all benefit from reduced latency of access.
> 
> * If it is media like music, pictures etc. served over a typical network
> protocl, the performance of HDDs may be entirely sufficient. Some
> media-related tasks like "downscale 10000 images from 700x700 to 500x500"
> may also benefit from the SSD if files are small enough that the access
> time becomes relevant.
> 
> * Additionally, if you have a small set of data that you are accessing all
> of the time and the OS manages to cache this into RAM, you will only
> benefit from the SSD performance upon first access. On systems that run
> 24/7, the benefit of SSDs is gerater in database-style continouously
> random-access-intensive applications rather than typical file access
> patterns.
> 
> As others have noted, the performance gain of SSDs is largely independent
> of connector. You can get an improvement even on old connectors and to
> some extent also on old systems. Unless you are thinking of using IDE SSDs
> (special-purpose devices which are mostly _not_ used for performance),
> everything should be fine in that regard :)

OK - thank you - this is the most complete answer I accept and I must once
again admit, that the discussion helped me put some order in my thoughts.

As mentioned I also think of splitting up the disks depending on use. The
multimedia would stay on the WD RED, but I will look forward to replace the
OS, VM and for development disks.

If someone has good experience with SSDs in RAID please share the device
model, family and manufacturer.

thank you once again
regards

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

#230264

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

deloptes writes:
> Linux-Fan wrote:
> > deloptes writes:
> >> Andrei POPESCU wrote:
> >> >> Each LSI card has a 6 bay cage attached and I have raided 6x2TB WD RED
> >> >> spinning discs (for data) and 2x1TB WD RED spinning discs (for OS)

[...]

> > Sounds OK to me :) From my point of view, I would work towards reducing
> > the total number of disks, given that spinning disks of 8 TB capacity and
> > SSDs of 4 TB capacity are readily available today. YMMV
> >
>
> Yes, but the prices of these SSDs are very high compared to spinning disks.
> When looking at the bigger WD RED disks (3-4TB) few years ago I found out
> many people complained that disks do not have same quality as 2TB WD RED,
> so I stick to those despite I could have saved at least 2bays. I still have
> 4 unused bays anyway. The only thing is the power consumption ... would be
> at least 10W less ... but it is neglectable.

There was some discussion about newer+larger WD Red drives using SMR  
rather than CMR recording [1] which indeed makes them almost unusable for  
RAID purposes. Buying HDDs today is more difficult due to the different  
recording types -- which are not always identified clearly, not even by the  
manufacturers themselves...

For my new system, I went with 2x6TB Toshiba N300 which are performing well  
so far (still not much experience with them, yet). Only odd thing is that  
they actually make audible sounds every five to ten seconds or so -- it's  
the same sound that you would hear from accessing a very old IDE/PATA HDD...  
(rattle rattle). According to Toshiba, it is normal though.

[...]

> After this discussion, I understand it is worth considering and it would pay
> off. This is why I ask for recommendations - might be I correct to
> replacement for both types. I must admit I now conclude considering putting
> dedicated disks for development, VMs and OS (like SSDs - may be better buy
> 2 3TB SSDs and replace the 2x1 and 2x2TB WD RED NAS) or replace just the
> 2x1TB with SSDs for OS and VMs as for the development I do not care
> compiling takes 20% more time.

Both sound like solid plans.

> > I have had good experience with the following two "consumer-grade" SSDs in
> > an mdadm RAID 1 (taking the I for inexpensive literally :) ). Both have
> > about 8000 hours of operation according to SMART and when in use they ran

Correction: They are beyond the 10000 already, see SMART output.

> > about 12h/day (i.e. normally not 24/7):
> >
> > * Samsung 850 EVO 2TB
> > * Crucial MX300 2TB
> >
> > At the time, these were the cheapest SSDs I could get with 2TB. Despite
> > their performance being "medicore" (for SSDs, that is), there were no
> > problems with RAID operation whatsoever.
>
> Thank you this is what I am looking for -personal experience. I have been
> looking at the Samsung 850 EVO 2TB. Can you share the exact model number,
> please?

Here is the smartctl -a output (shortened by serial numbers and less  
relevant parts). Not sure if it has a proper "model number".

~~~
# smartctl -a /dev/disk/by-id/ata-Samsung_SSD_850_EVO_2TB_...
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.19.0-12-amd64] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Samsung based SSDs
Device Model:     Samsung SSD 850 EVO 2TB
Serial Number:    ...
LU WWN Device Id: ...
Firmware Version: EMT02B6Q
User Capacity:    2,000,398,934,016 bytes [2.00 TB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Form Factor:      2.5 inches
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ACS-2, ATA8-ACS T13/1699-D revision 4c
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Sat Jan  2 17:23:05 2021 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

...

SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  9 Power_On_Hours          0x0032   097   097   000    Old_age   Always       -       10369
 12 Power_Cycle_Count       0x0032   098   098   000    Old_age   Always       -       1777
177 Wear_Leveling_Count     0x0013   098   098   000    Pre-fail  Always       -       30
179 Used_Rsvd_Blk_Cnt_Tot   0x0013   100   100   010    Pre-fail  Always       -       0
181 Program_Fail_Cnt_Total  0x0032   100   100   010    Old_age   Always       -       0
182 Erase_Fail_Count_Total  0x0032   100   100   010    Old_age   Always       -       0
183 Runtime_Bad_Block       0x0013   100   100   010    Pre-fail  Always       -       0
187 Uncorrectable_Error_Cnt 0x0032   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0032   074   055   000    Old_age   Always       -       26
195 ECC_Error_Rate          0x001a   200   200   000    Old_age   Always       -       0
199 CRC_Error_Count         0x003e   100   100   000    Old_age   Always       -       0
235 POR_Recovery_Count      0x0012   099   099   000    Old_age   Always       -       17
241 Total_LBAs_Written      0x0032   099   099   000    Old_age   Always       -       53692285287
~~~

For comparison, there is also the Crucial MX300 (model number:  
CT2050MX300SSD1):

~~~
# smartctl -a /dev/disk/by-id/ata-Crucial_CT2050MX300SSD1_...
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.19.0-12-amd64] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Crucial/Micron MX1/2/300, M5/600, 1100 Client SSDs
Device Model:     Crucial_CT2050MX300SSD1
Serial Number:    ...
LU WWN Device Id: ...
Firmware Version: M0CR031
User Capacity:    2,050,408,636,416 bytes [2.05 TB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Form Factor:      2.5 inches
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ACS-3 T13/2161-D revision 5
SATA Version is:  SATA 3.2, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Sat Jan  2 17:40:33 2021 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

...

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   100   100   000    Pre-fail  Always       -       104
  5 Reallocate_NAND_Blk_Cnt 0x0032   099   099   010    Old_age   Always       -       90
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       10193
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       1747
171 Program_Fail_Count      0x0032   100   100   000    Old_age   Always       -       0
172 Erase_Fail_Count        0x0032   100   100   000    Old_age   Always       -       0
173 Ave_Block-Erase_Count   0x0032   098   098   000    Old_age   Always       -       33
174 Unexpect_Power_Loss_Ct  0x0032   100   100   000    Old_age   Always       -       21
183 SATA_Interfac_Downshift 0x0032   100   100   000    Old_age   Always       -       0
184 Error_Correction_Count  0x0032   100   100   000    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       56
194 Temperature_Celsius     0x0022   074   051   000    Old_age   Always       -       26 (Min/Max 13/49)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       90
197 Current_Pending_Sector  0x0032   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   100   100   000    Old_age   Always       -       0
202 Percent_Lifetime_Used   0x0030   098   098   001    Old_age   Offline      -       2
206 Write_Error_Rate        0x000e   100   100   000    Old_age   Always       -       0
246 Total_Host_Sector_Write 0x0032   100   100   000    Old_age   Always       -       54316149898
247 Host_Program_Page_Count 0x0032   100   100   000    Old_age   Always       -       1714640403
248 Bckgnd_Program_Page_Cnt 0x0032   100   100   000    Old_age   Always       -       2182825060
180 Unused_Reserve_NAND_Blk 0x0033   000   000   000    Pre-fail  Always       -       8994
210 Success_RAIN_Recov_Cnt  0x0032   100   100   000    Old_age   Always       -       210
~~~

IIRC both drives are rated for 300 TBW i.e. not "write-intensive" workloads.  
There are other (more expensive) SSDs rated for higher workloads.  
Additionally, I bought them years ago (2016?) -- I would expect that  
nowdays, they have been superseded by follow-up models with similar  
specifications.

While the SMART output shows that they are now running at SATA III, I  
remember using them in my old workstation (HP Z400) whith SATA II, too. It  
worked just as well (despite the obvious limit to 3 Gbit/s from the SATA II  
interface).

[...]

> OK - thank you - this is the most complete answer I accept and I must once
> again admit, that the discussion helped me put some order in my thoughts.

You're welcome :)

> As mentioned I also think of splitting up the disks depending on use. The
> multimedia would stay on the WD RED, but I will look forward to replace the
> OS, VM and for development disks.

It's basically what I do, too.

> If someone has good experience with SSDs in RAID please share the device
> model, family and manufacturer.

See above. The drives hold MDADM RAID 1 arrays, one for OS, VMs and Swap  
respectively:

~~~
# lsblk
NAME      MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda         8:0    0   1.8T  0 disk
├─sda1      8:1    0   256G  0 part
│ └─md5     9:5    0 255.9G  0 raid1 /
├─sda2      8:2    0    18G  0 part
│ └─md6     9:6    0    18G  0 raid1 [SWAP]
└─sda3      8:3    0   1.6T  0 part
  └─md7     9:7    0   1.6T  0 raid1 /fs/ll
sdb         8:16   0   1.9T  0 disk
├─sdb1      8:17   0   256G  0 part
│ └─md5     9:5    0 255.9G  0 raid1 /
├─sdb2      8:18   0    18G  0 part
│ └─md6     9:6    0    18G  0 raid1 [SWAP]
└─sdb3      8:19   0   1.6T  0 part
  └─md7     9:7    0   1.6T  0 raid1 /fs/ll
~~~

[1] https://blog.westerndigital.com/wd-red-nas-drives/
    https://raid.wiki.kernel.org/index.php/Timeout_Mismatch
    https://hardware.slashdot.org/story/20/06/08/1513222/western-digitals-smr-disks-wont-work-for-zfs-but-theyre-okay-for-most-nases
    search keywords: <WD RED SMR> or <SMR MDADM RAID>

HTH
Linux-Fan

öö

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

#230229

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

On 2021-01-02 at 03:36, Andrei POPESCU wrote:

> On Vi, 01 ian 21, 23:09:01, deloptes wrote:
>> 
>> Each LSI card has a 6 bay cage attached and I have raided 6x2TB WD
>> RED spinning discs (for data) and 2x1TB WD RED spinning discs (for
>> OS)
> 
> 1TB for OS (assuming RAID1) seems... excessive to me. All my current
> installations are in 10 GiB partitions with only a separate /home.
> 
> Even if I'd go "wild" with several desktops installed (I'm only
> using LXDE), LibreOffice, etc. I'd probably get away with 50 GiB or
> so. Check the output of:
> 
> du -hx --max-depth=1 /

That would take a while to run, so I'm not going to do it just offhand,
but here's what I for my part get from a remotely analogous 'df' command
(piped through grep to include only actual on-disk partitions, since I
do everything through LVM whenever possible):

$ df -h | grep vg_
/dev/mapper/vg_system-lv_root 92G 23G 65G 26% /
/dev/mapper/vg_system-lv_usr 92G 19G 69G 22% /usr
/dev/mapper/vg_system-lv_boot 22G 137M 21G 1% /boot
/dev/mapper/vg_data-lv_home 9.9T 4.9T 4.5T 53% /home
/dev/mapper/vg_data-lv_opt 503G 33G 445G 7% /opt
/dev/mapper/vg_system-lv_tmp 7.3G 321M 6.6G 5% /tmp
/dev/mapper/vg_data-lv_var 503G 247G 231G 52% /var

vg_system totals something on the vague order of 750GB to 800GB.

/ itself (excluding child filesystems) contains 23GB of data. 22GB of
that is under /root. 17GB of *that* consists of backups of other
data that isn't read-time-accessible to any other user - both because it
isn't convenient to create the backup without that access, and because
some of that data may be read-restricted for good reason and I don't
want to put it somewhere more generally accessible in backed-up form any
more than in its production form. Another 2.4GB of the 22GB is in a
"packaging" subdirectory, and comes from an earlier point in my work
with Debian packages, when there was a reason for part of the process to
be done with root access.

/usr contains another 19GB.

/boot contains only 137MB, and could definitely stand to be way, way
less than 22GB in size.

/tmp is irrelevant here because it gets wiped on every reboot, but I
*have* actually managed to fill it up at least once; I'd probably make
it bigger on a full from-scratch system rebuild.

/var (which is part of my "data" LV, because of its tendency towards
large size, even though apparently the installed system won't operate
correctly without its exact contents and so it should properly go in the
"system" LV) contains 247GB - but that includes at least three
at-least-partial copies of the rest of the partition, from a recovery
operation from when the RAID array failed, as well as a mass redownload
of the damaged-at-array-failure-time contents of
/var/cache/apt/archives/. After I subtract off those, however, the
"real" size of that partition is still in the vicinity of 100GB (give or
take about 5GB) - of which 94GB is under /var/cache/apt/archives/.

Add those up and you get at least 120GB, even excluding the 22GB of data
under /root and the extra copies under /var.

Maybe 1TB of space for the installed OS is excessive, although I'm not
entirely convinced - but I don't see how you get away with 10GB, except
in the very short term after installation.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

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

#230237

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

On Sb, 02 ian 21, 04:35:59, The Wanderer wrote:
> 
> / itself (excluding child filesystems) contains 23GB of data. 22GB of
> that is under /root. 17GB of *that* consists of backups of other
> data that isn't read-time-accessible to any other user - both because it
> isn't convenient to create the backup without that access, and because
> some of that data may be read-restricted for good reason and I don't
> want to put it somewhere more generally accessible in backed-up form any
> more than in its production form. Another 2.4GB of the 22GB is in a
> "packaging" subdirectory, and comes from an earlier point in my work
> with Debian packages, when there was a reason for part of the process to
> be done with root access.

Storing lots of stuff under /root is your choice.

In such a scenario I'd probably be using a separate /root partition or 
more likely just put that stuff somewhere else (on some data partition).

> /usr contains another 19GB.

Ok.

> /boot contains only 137MB, and could definitely stand to be way, way
> less than 22GB in size.
> 
> /tmp is irrelevant here because it gets wiped on every reboot, but I
> *have* actually managed to fill it up at least once; I'd probably make
> it bigger on a full from-scratch system rebuild.
 
That adds up to about 20 GiB, excluding /var.

> /var (which is part of my "data" LV, because of its tendency towards
> large size, even though apparently the installed system won't operate
> correctly without its exact contents and so it should properly go in the
> "system" LV) contains 247GB - but that includes at least three
> at-least-partial copies of the rest of the partition, from a recovery
> operation from when the RAID array failed, as well as a mass redownload
> of the damaged-at-array-failure-time contents of
> /var/cache/apt/archives/. After I subtract off those, however, the
> "real" size of that partition is still in the vicinity of 100GB (give or
> take about 5GB) - of which 94GB is under /var/cache/apt/archives/.
 
The size of the entire amd64 archive is 426 GB according to

https://www.debian.org/mirror/size

As far as I understand that includes oldstable, stable, testing and 
unstable.

How many package versions do you keep around?

Considering your /usr is 19 GiB a package cache with .deb files for all 
your installed packages should be significantly less than that[1].

> Add those up and you get at least 120GB, even excluding the 22GB of data
> under /root and the extra copies under /var.
> 
> Maybe 1TB of space for the installed OS is excessive, although I'm not
> entirely convinced - but I don't see how you get away with 10GB, except
> in the very short term after installation.

Sorry, I was mistaken.

My laptop is indeed on a 30 GiB partition, but using only 14 GiB. I do 
(auto)clean the package cache more or less regularly though, even on 
unstable installs.

It's probably best to define what I mean by "installation". For me this 
means that if I were to install the same set of packages on a blank 
partition I would end up with about the same size.

100 GiB (excluding /home and other "data" storages) should be plenty.


[1] e.g. the .deb for firefox-esr on buster arm64 is 51,9 MiB whereas 
the Installed-Size is 197 MiB).

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

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

#230239

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

On 2021-01-02 at 05:58, Andrei POPESCU wrote:

> On Sb, 02 ian 21, 04:35:59, The Wanderer wrote:
> 
>> / itself (excluding child filesystems) contains 23GB of data. 22GB
>> of that is under /root. 17GB of *that* consists of backups of
>> other data that isn't read-time-accessible to any other user - both
>> because it isn't convenient to create the backup without that
>> access, and because some of that data may be read-restricted for
>> good reason and I don't want to put it somewhere more generally
>> accessible in backed-up form any more than in its production form.
>> Another 2.4GB of the 22GB is in a "packaging" subdirectory, and
>> comes from an earlier point in my work with Debian packages, when
>> there was a reason for part of the process to be done with root
>> access.
> 
> Storing lots of stuff under /root is your choice.
> 
> In such a scenario I'd probably be using a separate /root partition
> or more likely just put that stuff somewhere else (on some data
> partition).

Reasonable. I just haven't backfilled my partition arrangement since
discovering this use case for doing so.

>> /var (which is part of my "data" LV, because of its tendency
>> towards large size, even though apparently the installed system
>> won't operate correctly without its exact contents and so it should
>> properly go in the "system" LV) contains 247GB - but that includes
>> at least three at-least-partial copies of the rest of the
>> partition, from a recovery operation from when the RAID array
>> failed, as well as a mass redownload of the
>> damaged-at-array-failure-time contents of /var/cache/apt/archives/.
>> After I subtract off those, however, the "real" size of that
>> partition is still in the vicinity of 100GB (give or take about
>> 5GB) - of which 94GB is under /var/cache/apt/archives/.
> 
> The size of the entire amd64 archive is 426 GB according to
> 
> https://www.debian.org/mirror/size
> 
> As far as I understand that includes oldstable, stable, testing and
> unstable.

According to https://wiki.debian.org/DebianReleases, oldstable is
stretch, which (per that same page) was released in 2017.

Going by the table of release dates on that page, this computer would
probably have been installed with squeeze (in 2011, or possibly 2010
while it was still testing), and upgraded tracking testing ever since.

> How many package versions do you keep around?

Basically all of them. In theory I go in and delete the oldest unneeded
ones from time to time, but in practice that hasn't happened much.

On previous systems I investigated things like autoclean, but AFAIR I
never identified a way to get such a mechanism to keep the .deb files I
might want to use for reinstallation without keeping more than
necessary, and after a while it stopped being worth the while.

I believe I remember at least one mechanism which specifically provides
a way to delete only .deb files which cannot be re-downloaded. While
that's sensible from a clean-out-old-files perspective, from a
keep-important-files one it strikes me as backwards; if they can be
re-downloaded, then I don't strictly need the local copy in order to
reinstall them.

At the very least, I'd need to be able to keep the .deb files for
whatever version is presently installed - and probably more than that,
given that I do sometimes try installing a newer version and then decide
to downgrade again (thus requiring not only the older version's .deb,
but those for some of the packages it depends on).

Once in the past, on a different computer with different partition
layout, I managed to run out of space on /var because the APT package
archive got too big. One of my motivations for the partition sizes I
chose when installing this system was to avoid needing to do that ever
again if I could manage it.

>> Add those up and you get at least 120GB, even excluding the 22GB of
>> data under /root and the extra copies under /var.
>> 
>> Maybe 1TB of space for the installed OS is excessive, although I'm
>> not entirely convinced - but I don't see how you get away with
>> 10GB, except in the very short term after installation.
> 
> Sorry, I was mistaken.
> 
> My laptop is indeed on a 30 GiB partition, but using only 14 GiB. I
> do (auto)clean the package cache more or less regularly though, even
> on unstable installs.

That's a bit more sensible, although it still strikes me as fairly
limiting in terms of how much can be installed.

> It's probably best to define what I mean by "installation". For me
> this means that if I were to install the same set of packages on a
> blank partition I would end up with about the same size.

That's roughly the definition I was using, yes.

> 100 GiB (excluding /home and other "data" storages) should be
> plenty.

Yeah, if you'd given that figure initially I probably wouldn't have even
replied to begin with. It's less than I'd allocate, given the disk sizes
I have to work with, but it's well within sane ranges for a sysadmin to
choose even by my standards.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

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

#230240

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

On Sb, 02 ian 21, 06:28:24, The Wanderer wrote:
> On 2021-01-02 at 05:58, Andrei POPESCU wrote:
> 
> > How many package versions do you keep around?
> 
> Basically all of them. In theory I go in and delete the oldest unneeded
> ones from time to time, but in practice that hasn't happened much.
> 
> On previous systems I investigated things like autoclean, but AFAIR I
> never identified a way to get such a mechanism to keep the .deb files I
> might want to use for reinstallation without keeping more than
> necessary, and after a while it stopped being worth the while.
> 
> I believe I remember at least one mechanism which specifically provides
> a way to delete only .deb files which cannot be re-downloaded. While
> that's sensible from a clean-out-old-files perspective, from a
> keep-important-files one it strikes me as backwards; if they can be
> re-downloaded, then I don't strictly need the local copy in order to
> reinstall them.
> 
> At the very least, I'd need to be able to keep the .deb files for
> whatever version is presently installed - and probably more than that,
> given that I do sometimes try installing a newer version and then decide
> to downgrade again (thus requiring not only the older version's .deb,
> but those for some of the packages it depends on).
 
'apt[-get] autoclean' with APT:Clean-Installed set to off might be a 
good start, see apt-get(8).

> > My laptop is indeed on a 30 GiB partition, but using only 14 GiB. I
> > do (auto)clean the package cache more or less regularly though, even
> > on unstable installs.
> 
> That's a bit more sensible, although it still strikes me as fairly
> limiting in terms of how much can be installed.
 
With all packages I need already installed I'm barely using 50%. How is 
that limiting?

> > It's probably best to define what I mean by "installation". For me
> > this means that if I were to install the same set of packages on a
> > blank partition I would end up with about the same size.
> 
> That's roughly the definition I was using, yes.
> 
> > 100 GiB (excluding /home and other "data" storages) should be
> > plenty.
> 
> Yeah, if you'd given that figure initially I probably wouldn't have even
> replied to begin with. It's less than I'd allocate, given the disk sizes
> I have to work with, but it's well within sane ranges for a sysadmin to
> choose even by my standards.

I meant "plenty" as in "almost wasteful" ;)

But then again, I'm used to getting by with limited storage space. I 
could probably fit all my data in 1 TiB.

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

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

#230244

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

On Sb, 02 ian 21, 13:49:27, Andrei POPESCU wrote:
> On Sb, 02 ian 21, 06:28:24, The Wanderer wrote:
> > 
> > At the very least, I'd need to be able to keep the .deb files for
> > whatever version is presently installed - and probably more than that,
> > given that I do sometimes try installing a newer version and then decide
> > to downgrade again (thus requiring not only the older version's .deb,
> > but those for some of the packages it depends on).
>  
> 'apt[-get] autoclean' with APT:Clean-Installed set to off might be a 
> good start, see apt-get(8).

Forgot to mention: for Debian packages there is snapshot.debian.org, so 
there is no such thing as a package you can't download (from somewhere).

It also supports date-based sources.list entries.

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

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

#230248

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

On 2021-01-02 at 07:09, Andrei POPESCU wrote:

> On Sb, 02 ian 21, 13:49:27, Andrei POPESCU wrote:
> 
>> On Sb, 02 ian 21, 06:28:24, The Wanderer wrote:

>>> On previous systems I investigated things like autoclean, but
>>> AFAIR I never identified a way to get such a mechanism to keep
>>> the .deb files I might want to use for reinstallation without
>>> keeping more than necessary, and after a while it stopped being
>>> worth the while.
>>> 
>>> I believe I remember at least one mechanism which specifically
>>> provides a way to delete only .deb files which cannot be
>>> re-downloaded. While that's sensible from a clean-out-old-files
>>> perspective, from a keep-important-files one it strikes me as
>>> backwards; if they can be re-downloaded, then I don't strictly
>>> need the local copy in order to reinstall them.
>>> 
>>> At the very least, I'd need to be able to keep the .deb files
>>> for whatever version is presently installed - and probably more
>>> than that, given that I do sometimes try installing a newer
>>> version and then decide to downgrade again (thus requiring not
>>> only the older version's .deb, but those for some of the packages
>>> it depends on).
>> 
>> 'apt[-get] autoclean' with APT:Clean-Installed set to off might be
>> a good start, see apt-get(8).

I think that was one of the mechanisms I investigated before, but it may
be worth looking at again.

> Forgot to mention: for Debian packages there is snapshot.debian.org,
> so there is no such thing as a package you can't download (from
> somewhere).
> 
> It also supports date-based sources.list entries.

Yes - I considered mentioning this in my previous mail, but decided it
wasn't worth complexifying the phrasing any more than I was already
doing. I was of course using the definition of "downloadable" which
would be used by the cleanup mechanism making the decision, which is
naturally based on the availability of that package version in the
configured sources.list.

That said, I haven't experimented with using snapshot.debian.org as a
sources.list origin (IIRC it may not have worked that way when I first
learned of its existence), and that may be worth looking at too. Then
again, one of the advantages of keeping the local .deb is as a record of
which version I want to use, so it's not guaranteed that the sdo-based
source would be as good in that regard.


I actually once rebuilt the contents of /var/cache/apt/archives/ on this
machine from filenames, by downloading every single .deb involved from
snapshot.debian.org using wget and similar, after some unknown subset of
them got corrupted in (the data-recovery process from) that RAID-array
failure I mentioned before. That's where some of those extra (partial)
copies came from.

That took some coding to automate, particularly given that I was working
entirely in shell and from a recovery environment. I still have the
scripts involved; they're not perfect by any means, but they were enough
for what I needed at the time.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

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

#230246

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

On 2021-01-02 at 06:49, Andrei POPESCU wrote:

> On Sb, 02 ian 21, 06:28:24, The Wanderer wrote:
> 
>> On 2021-01-02 at 05:58, Andrei POPESCU wrote:
>> 
>>> How many package versions do you keep around?

>>> My laptop is indeed on a 30 GiB partition, but using only 14 GiB.
>>> I do (auto)clean the package cache more or less regularly though,
>>> even on unstable installs.
>> 
>> That's a bit more sensible, although it still strikes me as fairly 
>> limiting in terms of how much can be installed.
> 
> With all packages I need already installed I'm barely using 50%. How
> is that limiting?

In that you don't know what you may turn out to need to install later,
or how big that's going to be. I know of some *programs* which are
multiple gigabytes in size (though to be fair, they're all A: for
Windows or Mac, B: games, or C: both), and I'd hate to discover the need
to install them and not have enough capacity to do so.

ISTR having also once run out of space on / because of filling up /usr
(etc.) due to installed packages, again on a previous machine, and I
*definitely* don't want to risk doing *that* again.

>>> It's probably best to define what I mean by "installation". For
>>> me this means that if I were to install the same set of packages
>>> on a blank partition I would end up with about the same size.
>> 
>> That's roughly the definition I was using, yes.
>> 
>>> 100 GiB (excluding /home and other "data" storages) should be 
>>> plenty.
>> 
>> Yeah, if you'd given that figure initially I probably wouldn't have
>> even replied to begin with. It's less than I'd allocate, given the
>> disk sizes I have to work with, but it's well within sane ranges
>> for a sysadmin to choose even by my standards.
> 
> I meant "plenty" as in "almost wasteful" ;)
> 
> But then again, I'm used to getting by with limited storage space. I
>  could probably fit all my data in 1 TiB.

Whereas I'm more the pack-rat type. Even excluding the redundant copies
that I haven't properly unified from various past system-migration and
data-recovery scenarios, I have multiple TB of total data, some of it
decades old and irreplaceable.

Though the large majority of that isn't installed-system, it's
user-data, i.e. (quite properly) stored under /home.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web