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

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

WiFi without Network Manager

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

Contents

  WiFi without Network Manager Kenneth Parker <sea7kenp@gmail.com> - 2019-02-12 15:20 +0100
    Re: WiFi without Network Manager <tomas@tuxteam.de> - 2019-02-12 15:40 +0100
      Re: WiFi without Network Manager Kenneth Parker <sea7kenp@gmail.com> - 2019-02-12 15:50 +0100
        Re: WiFi without Network Manager <tomas@tuxteam.de> - 2019-02-12 16:00 +0100
          Re: WiFi without Network Manager Kenneth Parker <sea7kenp@gmail.com> - 2019-02-12 19:00 +0100
            Re: WiFi without Network Manager Eduardo M KALINOWSKI <eduardo@kalinowski.com.br> - 2019-02-12 19:50 +0100
              Re: WiFi without Network Manager Kenneth Parker <sea7kenp@gmail.com> - 2019-02-12 20:10 +0100
      Re: WiFi without Network Manager Kenneth Parker <sea7kenp@gmail.com> - 2019-02-15 00:30 +0100
        Re: WiFi without Network Manager mett <mett@pmars.jp> - 2019-02-15 05:00 +0100
          Re: WiFi without Network Manager Kenneth Parker <sea7kenp@gmail.com> - 2019-02-15 06:00 +0100
            Re: WiFi without Network Manager didier gaumet <didier.gaumet@gmail.com> - 2019-02-15 09:10 +0100
    Re: WiFi without Network Manager ghe <ghe@slsware.net> - 2019-02-12 15:50 +0100
      Glenn -> Re: WiFi without Network Manager deb <deb@rangingthoughts.org> - 2019-02-12 17:20 +0100
        Re: WiFi without Network Manager ghe <ghe@slsware.net> - 2019-02-12 21:10 +0100
          Re: WiFi without Network Manager deb <deb@rangingthoughts.org> - 2019-02-13 14:40 +0100
            Re: WiFi without Network Manager rhkramer@gmail.com - 2019-02-13 14:50 +0100
              Re: WiFi without Network Manager John Hasler <jhasler@newsguy.com> - 2019-02-13 15:20 +0100
                Re: WiFi without Network Manager Ric Moore <wayward4now@gmail.com> - 2019-02-13 17:40 +0100
            Re: WiFi without Network Manager mick crane <mick.crane@gmail.com> - 2019-02-13 15:00 +0100
          Swap space choice on a SSD <- Current best practice on? deb <deb@rangingthoughts.org> - 2019-02-13 14:50 +0100
            Re: Swap space choice on a SSD <- Current best practice on? Michael Stone <mstone@debian.org> - 2019-02-13 14:50 +0100
              Re: Swap space choice on a SSD <- Current best practice on? deb <deb@rangingthoughts.org> - 2019-02-13 15:00 +0100
                Re: Swap space choice on a SSD <- Current best practice on? Dan Ritter <dsr@randomstring.org> - 2019-02-13 15:20 +0100
                  Thanks Dan. Re: Swap space choice on a SSD <- Current best practice  on? deb <deb@rangingthoughts.org> - 2019-02-13 15:40 +0100
            Re: Swap space choice on a SSD <- Current best practice on? David Christensen <dpchrist@holgerdanske.com> - 2019-02-13 22:20 +0100
              Re: Swap space choice on a SSD <- Current best practice on? Dan Ritter <dsr@randomstring.org> - 2019-02-13 22:30 +0100
                Re: Swap space choice on a SSD <- Current best practice on? Andy Smith <andy@strugglers.net> - 2019-02-13 22:50 +0100
                Re: Swap space choice on a SSD <- Current best practice on? David Christensen <dpchrist@holgerdanske.com> - 2019-02-14 05:20 +0100
              Re: Swap space choice on a SSD <- Current best practice on? Andy Smith <andy@strugglers.net> - 2019-02-13 22:30 +0100
                Re: Swap space choice on a SSD <- Current best practice on? David Christensen <dpchrist@holgerdanske.com> - 2019-02-14 05:30 +0100
              Re: Swap space choice on a SSD <- Current best practice on? Michael Stone <mstone@debian.org> - 2019-02-13 22:30 +0100

Page 2 of 2 — ← Prev page 1 [2]

#205281 — Re: Swap space choice on a SSD <- Current best practice on?

On Wed, Feb 13, 2019 at 08:41:33AM -0500, deb wrote:
>#1 Given that it's not great to pound the same area of a SSD with 
>writes; is it indeed still best practice to go with a swap partition 
>on a SSD rather than a swap FILE?

That's not a thing: the SSD will balance writes physically across the 
drive regardless of where they are logically.

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

#205283 — Re: Swap space choice on a SSD <- Current best practice on?

On 2/13/2019 8:46 AM, Michael Stone wrote:
> On Wed, Feb 13, 2019 at 08:41:33AM -0500, deb wrote:
>> #1 Given that it's not great to pound the same area of a SSD with 
>> writes; is it indeed still best practice to go with a swap partition 
>> on a SSD rather than a swap FILE?
>
> That's not a thing: the SSD will balance writes physically across the 
> drive regardless of where they are logically.
>
>
OK, that's interesting.

I though the partition might physically lock a section of writes.

Is there a link that goes into that *partitions are not a boundary on 
physical SSD writes* further?

If I'm sure, I'll just let Debian partition for Swap.


... I'm still curious how to get the installer to go with a swap FILE 
rather than a swap PARTITION though.


Thanks

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

#205288 — Re: Swap space choice on a SSD <- Current best practice on?

deb wrote: 
> 
> On 2/13/2019 8:46 AM, Michael Stone wrote:
> > On Wed, Feb 13, 2019 at 08:41:33AM -0500, deb wrote:
> > > #1 Given that it's not great to pound the same area of a SSD with
> > > writes; is it indeed still best practice to go with a swap partition
> > > on a SSD rather than a swap FILE?
> > 
> > That's not a thing: the SSD will balance writes physically across the
> > drive regardless of where they are logically.
> > 
> > 
> OK, that's interesting.
> 
> I though the partition might physically lock a section of writes.
> 
> Is there a link that goes into that *partitions are not a boundary on
> physical SSD writes* further?

For a spinning disk, your OS generally has control of what will
go where*. For an SSD, the incentive to not rewrite a sector
until absolutely necessary is so high that the geometry of the
disk is completely mythical. The SSD controller will pretend
that there are contiguous sectors for partitions to be in, but
they can all be remapped anywhere at any time.

If you want maximum SSD longevity, increase the amount of space
that the SSD can use for remapping by never writing to some
amount of space. Easiest is to not fill the disk with partitions
-- leave 5-10% empty.

*The disk may remap a known bad sector to a pool of reserve
sectors without the OS being told about it. Or not.

> If I'm sure, I'll just let Debian partition for Swap.
> 
> ... I'm still curious how to get the installer to go with a swap FILE rather
> than a swap PARTITION though.

The installer doesn't have that option, but if you tell it to go
ahead without a swap partition, you can create a swapfile
later. Or multiple swapfiles. Or use the swapspace package, 
which will create and destroy swapfiles as memory requirements
dictate. 

-dsr-

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

#205294 — Thanks Dan. Re: Swap space choice on a SSD <- Current best practice on?

Thank you.

On 2/13/2019 9:11 AM, Dan Ritter wrote:
> deb wrote:
>> On 2/13/2019 8:46 AM, Michael Stone wrote:
>>> On Wed, Feb 13, 2019 at 08:41:33AM -0500, deb wrote:
>>>> #1 Given that it's not great to pound the same area of a SSD with
>>>> writes; is it indeed still best practice to go with a swap partition
>>>> on a SSD rather than a swap FILE?
>>> That's not a thing: the SSD will balance writes physically across the
>>> drive regardless of where they are logically.
>>>
>>>
>> OK, that's interesting.
>>
>> I though the partition might physically lock a section of writes.
>>
>> Is there a link that goes into that *partitions are not a boundary on
>> physical SSD writes* further?
> For a spinning disk, your OS generally has control of what will
> go where*. For an SSD, the incentive to not rewrite a sector
> until absolutely necessary is so high that the geometry of the
> disk is completely mythical. The SSD controller will pretend
> that there are contiguous sectors for partitions to be in, but
> they can all be remapped anywhere at any time.
>
> If you want maximum SSD longevity, increase the amount of space
> that the SSD can use for remapping by never writing to some
> amount of space. Easiest is to not fill the disk with partitions
> -- leave 5-10% empty.
>
> *The disk may remap a known bad sector to a pool of reserve
> sectors without the OS being told about it. Or not.
>
>> If I'm sure, I'll just let Debian partition for Swap.
>>
>> ... I'm still curious how to get the installer to go with a swap FILE rather
>> than a swap PARTITION though.
> The installer doesn't have that option, but if you tell it to go
> ahead without a swap partition, you can create a swapfile
> later. Or multiple swapfiles. Or use the swapspace package,
> which will create and destroy swapfiles as memory requirements
> dictate.
>
> -dsr-
>
>

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

#205314 — Re: Swap space choice on a SSD <- Current best practice on?

On 2/13/19 5:41 AM, deb wrote:
> Again -- fussing with a full (not from a live .iso) 9.7 install; the
> Debian GUI installer is suggesting a Swap partition on a Kingston
> SSD.
> 
> #1 Given that it's not great to pound the same area of a SSD with 
> writes; is it indeed still best practice to go with a swap partition
> on a SSD rather than a swap FILE?
> 
> (Or is this a legacy spinning hard disk install suggestion?)

On 2/13/19 5:46 AM, Michael Stone wrote:
> That's not a thing: the SSD will balance writes physically across
> the drive regardless of where they are logically.

+1

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


On 2/13/19 5:41 AM, deb wrote:
> #2 How DO you get the installer to go with a Swap FILE?
> 
> Just delete that recommended Swap partition during the install?
> 
> I looked; but did not run across any best practice docs for Swap on
> SSD.

On 2/13/19 6:11 AM, Dan Ritter wrote:
> The installer doesn't have that option...

+1 AFAIK


A swap partition is faster than a swap file.


Backing up, archiving, imaging, restoring, etc., swap files is
wasteful, but modifying those operations to exclude/ regenerate swap
files adds complexity (and risk).


In my SOHO environment, all my machines have a single system drive and
my bulk data is in a file server.  When I first started using SSD's and
USB flash drives as system drives, I was worried about swap wearing out
the drive.  So, I tried running without swap.  This worked until
memory got low, then the machines crashed.  So, I added memory and
reinstalled with 1 GB swap partitions.


On 2/13/19 6:11 AM, Dan Ritter wrote:
> If you want maximum SSD longevity, increase the amount of space that
> the SSD can use for remapping by never writing to some amount of
> space. Easiest is to not fill the disk with partitions -- leave 5-10%
> empty.

AFAIK over-provisioning has no effect on longevity -- longevity is
proportional to total number of cells times rated erase/ write cycles
per cell divided by write throughput.


But, over-provisioning can improve write performance:

https://en.wikipedia.org/wiki/Write_amplification#Over-provisioning


Other SSD considerations include choice of file system, mount options,
kernel tuning, etc.:

https://btrfs.wiki.kernel.org/index.php/FAQ

https://en.wikipedia.org/wiki/Trim_(computing)

mount(8)

https://cromwell-intl.com/open-source/performance-tuning/disks.html


David

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

#205316 — Re: Swap space choice on a SSD <- Current best practice on?

David Christensen wrote: 
> On 2/13/19 6:11 AM, Dan Ritter wrote:
> > If you want maximum SSD longevity, increase the amount of space that
> > the SSD can use for remapping by never writing to some amount of
> > space. Easiest is to not fill the disk with partitions -- leave 5-10%
> > empty.
> 
> AFAIK over-provisioning has no effect on longevity -- longevity is
> proportional to total number of cells times rated erase/ write cycles
> per cell divided by write throughput.
> 
> 
> But, over-provisioning can improve write performance:
> 
> https://en.wikipedia.org/wiki/Write_amplification#Over-provisioning

Effective longevity depends on the number of times a block is
erased and written to. You can reduce that over the course of an
SSD's lifetime by limiting the space you think you have
available.

>From the article you cited:

"Over-provisioning often takes away from user capacity, either
temporarily or permanently, but it gives back reduced write
amplification, increased endurance, and increased performance."

Increased endurance is increased longevity.

-dsr-

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

#205320 — Re: Swap space choice on a SSD <- Current best practice on?

Hello,

On Wed, Feb 13, 2019 at 04:23:56PM -0500, Dan Ritter wrote:
> "Over-provisioning often takes away from user capacity, either
> temporarily or permanently, but it gives back reduced write
> amplification, increased endurance, and increased performance."
> 
> Increased endurance is increased longevity.

That is also my understanding and matches many articles advising how to
choose the best enterprise SSD for a particular workload. However, I
know that SSDs are a lot more "black box" than your typical HDD so I
think especially with consumer devices it could be hard to generalise
and reason about. At that level the device specs often do not specify
numbers for "terabytes written" or "drive writes per day".

It can also be surprising sometimes how little is written. For example,
I have some servers with flash memory for their operating system
install, with data on other storage:

    https://www.supermicro.com/products/nfo/SATADOM.cfm

At the 16GB capacity these offer only 17TB of writes over 5 years and I
was a bit worried, so I was thinking of spending some effort making sure
that things which are regularly doing writes do so to a RAM disk
instead.

Luckily there's a SMART attribute (241) you can use to tell how much has
been written to the drive to date and when I checked that I found the
servers were typically writing only ~14GiB per month. So that would take
about 100 years to reach 17TB! Of course, the 5 year warranty covers
other factors too.

It all depends on use case, as clearly there are uses that are
write-intensive which would burn through 17TB in a matter of hours. I do
not put swap on these devices. Measuring is still essential in my view,
but things are indeed a lot easier than they were a decade ago.

Cheers,
Andy

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

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

#205326 — Re: Swap space choice on a SSD <- Current best practice on?

On 2/13/19 1:23 PM, Dan Ritter wrote:
> David Christensen wrote:
>> On 2/13/19 6:11 AM, Dan Ritter wrote:
>>> If you want maximum SSD longevity, increase the amount of space that
>>> the SSD can use for remapping by never writing to some amount of
>>> space. Easiest is to not fill the disk with partitions -- leave 5-10%
>>> empty.
>>
>> AFAIK over-provisioning has no effect on longevity -- longevity is
>> proportional to total number of cells times rated erase/ write cycles
>> per cell divided by write throughput.
>>
>>
>> But, over-provisioning can improve write performance:
>>
>> https://en.wikipedia.org/wiki/Write_amplification#Over-provisioning
> 
> Effective longevity depends on the number of times a block is
> erased and written to. You can reduce that over the course of an
> SSD's lifetime by limiting the space you think you have
> available.
> 
> From the article you cited:
> 
> "Over-provisioning often takes away from user capacity, either
> temporarily or permanently, but it gives back reduced write
> amplification, increased endurance, and increased performance."
> 
> Increased endurance is increased longevity.

SSD manufacturers taking away part of the capacity and then telling us 
the drive has increased endurance measured against the reduced size is 
marketing speak.  (Similar rant for kB, MB, GB, etc..)


I use the term "over-provisioning" in the context of this mailing list 
-- e.g. what we can do as Debian users (and system administrators):

"Furthermore, if any SSD is set up with an overall partitioning layout 
smaller than 100% of the available space, that unpartitioned space will 
be automatically used by the SSD as over-provisioning as well."


Whether you partition the first 90% of an SSD and write X blocks at 
random intervals over some time period T, or partition 100% and do the 
same, the number of Program/ Erase (P/E) cycles will be the same.  (But 
the timing/ performance of clustered writes may differ.)  When X gets 
large enough, the drive will eventually fail.  I would call that X the 
endurance of the drive.  (Intel converts it to a MTBF of 1,200,000 hours 
for my Series 520 SSD's.)


So, over-provisioning *by Debian users* has no effect on longevity.


David

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

#205317 — Re: Swap space choice on a SSD <- Current best practice on?

Hello,

On Wed, Feb 13, 2019 at 01:14:36PM -0800, David Christensen wrote:
> A swap partition is faster than a swap file.

Has something changed in this regard since kernel version 2.6 then?

http://lkml.iu.edu/hypermail/linux/kernel/0507.0/1690.html

Cheers,
Andy

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

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

#205327 — Re: Swap space choice on a SSD <- Current best practice on?

On 2/13/19 1:28 PM, Andy Smith wrote:
> On Wed, Feb 13, 2019 at 01:14:36PM -0800, David Christensen wrote:
>> A swap partition is faster than a swap file.
> 
> Has something changed in this regard since kernel version 2.6 then?
> 
> http://lkml.iu.edu/hypermail/linux/kernel/0507.0/1690.html

I do not follow Linux kernel development.  Apparently, people wanted 
faster swap files badly enough to implement optimizations in kernel 2.6. 
  I can only wonder how much complexity and KLOC are required (overall 
and per file system), if all Linux file systems support it, and are 
there benchmarks?


David

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

#205318 — Re: Swap space choice on a SSD <- Current best practice on?

On Wed, Feb 13, 2019 at 01:14:36PM -0800, David Christensen wrote:
>AFAIK over-provisioning has no effect on longevity -- longevity is
>proportional to total number of cells times rated erase/ write cycles
>per cell divided by write throughput.

In the absence of trim, restricting the logical capacity of the drive 
ensures a larger pool of cells known to the drive to be unused and 
available for wear leveling. Otherwise, if you write to a cell the drive 
has to always preserve the data in that cell even if you later erase the 
file you wrote there (because the drive doesn't know it was erased).  
This is essentially what the drive manufacturers do: they build a drive 
with capacity N but sell it as N-S where S is the amount of spare 
capacity held in reserve for wear leveling and to allow for cells to be 
removed from service as they reach end of life. In general, the more 
expensive the drive, the more it is overprovisioned to increase the 
longevity of the device.

On modern SSDs in light duty the difference is probably negligeable, 
especially if you occasionally fstrim to communicate how much of the 
drive is actually unused.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web