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

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

Recommendation on partition sizes

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Recommendation on partition sizes D&P Dimov <lddimov@yahoo.com> - 2018-11-04 04:30 +0100
    Re: Recommendation on partition sizes Andy Smith <andy@strugglers.net> - 2018-11-04 05:50 +0100
      Re: Recommendation on partition sizes Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-11-04 10:30 +0100
        Re: Recommendation on partition sizes Andy Smith <andy@strugglers.net> - 2018-11-04 14:00 +0100
          Re: Recommendation on partition sizes Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-11-04 14:40 +0100
            Re: Recommendation on partition sizes Andy Smith <andy@strugglers.net> - 2018-11-04 14:50 +0100
              Re: Recommendation on partition sizes Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-11-04 16:00 +0100
        Re: Recommendation on partition sizes Rick Thomas <rbthomas@pobox.com> - 2018-11-05 09:20 +0100
          Re: Recommendation on partition sizes Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-11-05 19:50 +0100
      Re: Recommendation on partition sizes Stefan Monnier <monnier@iro.umontreal.ca> - 2018-11-04 16:50 +0100
        Re: Recommendation on partition sizes Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-11-04 17:30 +0100
          Re: Recommendation on partition sizes Stefan Monnier <monnier@iro.umontreal.ca> - 2018-11-04 21:00 +0100
            Re: Recommendation on partition sizes Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-11-04 23:30 +0100
              Re: Recommendation on partition sizes Stefan Monnier <monnier@iro.umontreal.ca> - 2018-11-05 00:20 +0100
                Re: Recommendation on partition sizes Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-11-05 20:20 +0100
              Re: Recommendation on partition sizes Curt <curty@free.fr> - 2018-11-05 09:40 +0100
                Re: Recommendation on partition sizes Michael Stone <mstone@debian.org> - 2018-11-05 16:20 +0100
                Re: Recommendation on partition sizes Stefan Monnier <monnier@iro.umontreal.ca> - 2018-11-06 15:10 +0100
                  Re: Recommendation on partition sizes Michael Stone <mstone@debian.org> - 2018-11-06 16:20 +0100
        Re: Recommendation on partition sizes Michael Stone <mstone@debian.org> - 2018-11-04 17:40 +0100
    Re: Recommendation on partition sizes David Christensen <dpchrist@holgerdanske.com> - 2018-11-04 08:40 +0100
      Re: Recommendation on partition sizes Michael Stone <mstone@debian.org> - 2018-11-04 15:10 +0100
    Re: Recommendation on partition sizes Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-11-04 10:30 +0100

Page 1 of 2  [1] 2  Next page →

#202076 — Recommendation on partition sizes

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

Considering that I will be installing Debian 9.5 Stable on a new Dell laptop with 512 GB SSD and 16 GB RAM, and intend to also run Windows 10 as a virtual machine from the /home partition (so it doesn't get affected during kernel updates and upgrades),
does this seem like an adequate space allocation:
1MB free space (as per a recent post on this forum)
boot partition, not encrypted, 1.5 GB/ root, encrypted, 40 GB 
/swap, encrypted, 16GB (same as RAM)/home, encrypted, contains the virtual Windows 10 and documents, the remaining approximately 454 GB

Thanks!

[toc] | [next] | [standalone]

#202078

Hi,

On Sun, Nov 04, 2018 at 03:20:11AM +0000, D&P Dimov wrote:
> does this seem like an adequate space allocation:

You're probably going to receive as many different opinions as there
are different people responding, but my recommendation in nearly any
situation is to have a reasonable /boot and swap and then the rest
of the space inside an LVM volume group.

Out of the volume group I'd initially carve only a couple of logical
volumes depending on the intended use of the machine, and I'd keep
them fairly small, because enlarging them later will be simple and
can generally be done online.

This gives you flexibility to respond to how your intended use of
the system changes over time, as very little is set in stone at the
beginning.

> boot partition, not encrypted, 1.5 GB

A little large, but not stupidly so. It's rare for any of my systems
to use more than a couple of hundred MiB in /boot.

> / root, encrypted, 40 GB 

Seems excessive. Without service-specific data or /var, my servers
generally use under 2GiB for /, so dedicating 40GiB to it is likely
to be wasteful.

> /swap, encrypted, 16GB (same as RAM)

Hugely overkill. You do not need for your swap to be as large as
your RAM unless you are intending to hibernate to disk. If you are
intending to do that, fair enough, but if not, that's probably 12+
GiB of expensive SSD that sits idle forever.

If you ever got to the point were anything like double figures GiB
of swap space is used for running processes, then it is likely that
your system would be performing like a dog and you'd want to get out
of that state as quickly as you could.

There are exceptions to that, but for those times you can simply
create a swap file and add it. There is no performance difference
between a swap file and a dedicated swap partition.

"How much swap do I require?" is a little bit of a holy war, with
some even taking the position that the answer is "zero". Unless
planning for hibernation though, "16 GiB" is not a sensible answer
in my opinion.

I'd go no higher than 2GiB regardless of RAM.

> /home, encrypted, contains the virtual Windows 10 and documents, the remaining approximately 454 GB

The problem with this plan is that should any other part of your
system run out of space, you're going to have to start putting
things under /home (or re-partition). While that will work, it will
be messy and counter-intuitive.

You may also decide later that you wish to separate the storage for
your virtual machines from your home directory and documents.

Finally, although your virtual machines initially might be fine
using image files, at some point you may want to dedicate logical
volumes to each VM.

So, if I were you, I'd be doing something like:

- 512MiB /boot
- 2 GiB swap, or 16GiB if you intend to use it as a hibernate device
- Rest as LVM volume group
    - 4 GiB / as logical volume
    - 4 GiB /var as logical volume
    - 50GiB (or whatever satisfies initial demand) /home as logical
      volume

If you suddenly find yourself needing something extra, you can
easily create a new logical volume and mount it. When you get close
to filling your /home, you can just grow it a bit and grow the
filesystem online¹.

I would want to be putting all of this on top of software RAID, so
my system doesn't die when one of the storage devices dies. So, for
example, given two identical drives sda and sdb, /boot and swap
would actually be on RAID-1 mirrors of pairs of partitions
(sd{a,b}1, sd{a,b}2 respectively).

You mentioned encryption, and the good news is that all of the above
can be done from the Debian installer with everything except /boot
encrypted. The encrypted container will be an LVM volume group, and
in manual partitioning just ensure that it does not immediately
dedicate all the space in the VG to logical volumes, so you can add
and grow your own LVs later.

Grub bootloader does understand LVM now so you could also put /boot
inside LVM, but for my tastes it is too much added complexity for
the sake of a such a small partition, so I prefer not to.

If you've never used LVM before then all of this may seem like
unwanted complexity, but it's a small set of self-contained concepts
that are very well supported by the Debian installer so to me it's
well worth getting to grips with. It will provide you with a lot of
flexibility throughout the life of the system.

Cheers,
Andy

¹ Something like:

  # lvresize -r -L+5g /dev/my_vg/home_lv

  The -r does an online grow of the filesystem as well. If you
  wanted to do those steps separately for some reason then drop the
  -r and afterwards do something like:

  # resize2fs -p /dev/my_vg/home_lv

  (Assuming ext filesystem; other filesystems have their own resize
  commands.)

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

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

#202084

Le 04/11/2018 à 05:45, Andy Smith a écrit :
> 
> You're probably going to receive as many different opinions as there
> are different people responding, but my recommendation in nearly any
> situation is to have a reasonable /boot and swap and then the rest
> of the space inside an LVM volume group.
(...)
> So, if I were you, I'd be doing something like:
> 
> - 512MiB /boot
> - 2 GiB swap, or 16GiB if you intend to use it as a hibernate device
> - Rest as LVM volume group
>      - 4 GiB / as logical volume
>      - 4 GiB /var as logical volume
>      - 50GiB (or whatever satisfies initial demand) /home as logical
>        volume

Why don't you include the swap in LVM ?

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

#202090

Hello,

On Sun, Nov 04, 2018 at 10:19:59AM +0100, Pascal Hambourg wrote:
> Le 04/11/2018 à 05:45, Andy Smith a écrit :
> Why don't you include the swap in LVM ?

I don't see the point as it will never change in size.

But in the case where encryption is used, it would have to be inside
the encrypted volume group of course.

Cheers,
Andy

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

#202092

Le 04/11/2018 à 13:53, Andy Smith a écrit :
> 
> On Sun, Nov 04, 2018 at 10:19:59AM +0100, Pascal Hambourg wrote:
>> Le 04/11/2018 à 05:45, Andy Smith a écrit :
>> Why don't you include the swap in LVM ?
> 
> I don't see the point as it will never change in size.

Why not ? You could decide that you don't need swap any more and reclaim 
the space. Or if you use hibernation and add some RAM, you could decide 
to increase the swap size accordingly.

> But in the case where encryption is used, it would have to be inside
> the encrypted volume group of course.

Not necessarily. Swap could also use its own encrypted volume. Swap 
encryption could use a one-time random key if hibernation is not needed.

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

#202094

Hello,

On Sun, Nov 04, 2018 at 02:31:14PM +0100, Pascal Hambourg wrote:
> Le 04/11/2018 à 13:53, Andy Smith a écrit :
> >
> >On Sun, Nov 04, 2018 at 10:19:59AM +0100, Pascal Hambourg wrote:
> >>Le 04/11/2018 à 05:45, Andy Smith a écrit :
> >>Why don't you include the swap in LVM ?
> >
> >I don't see the point as it will never change in size.
> 
> Why not ? You could decide that you don't need swap any more and reclaim the
> space. Or if you use hibernation and add some RAM, you could decide to
> increase the swap size accordingly.

I am never going to decide that I don't want any swap at all. In the
unlikely event I want more, I can add it from inside the VG.

If there is a person who regularly removes their swap entirely and
then puts it back again later then I imagine it would make much more
sense to have it inside LVM as well. I struggle to imagine such a
person, but I'm sure they exist in life's rich tapestry. For me,
it's not something I'm ever likely to mess with and if I did it
would be to add more, not take away.

Cheers,
Andy

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

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

#202100

Le 04/11/2018 à 14:43, Andy Smith a écrit :
> 
> On Sun, Nov 04, 2018 at 02:31:14PM +0100, Pascal Hambourg wrote:
>> Le 04/11/2018 à 13:53, Andy Smith a écrit :
>>>
>>> On Sun, Nov 04, 2018 at 10:19:59AM +0100, Pascal Hambourg wrote:
>>>> Le 04/11/2018 à 05:45, Andy Smith a écrit :
>>>> Why don't you include the swap in LVM ?
>>>
>>> I don't see the point as it will never change in size.
>>
>> Why not ? You could decide that you don't need swap any more and reclaim the
>> space. Or if you use hibernation and add some RAM, you could decide to
>> increase the swap size accordingly.
> 
> I am never going to decide that I don't want any swap at all. In the
> unlikely event I want more, I can add it from inside the VG.

AFAIK, hibernation can only use one swap, which must be large enough to 
store the resume image.

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

#202124

> On Nov 4, 2018, at 1:19 AM, Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
> 
> Le 04/11/2018 à 05:45, Andy Smith a écrit :
>> You're probably going to receive as many different opinions as there
>> are different people responding, but my recommendation in nearly any
>> situation is to have a reasonable /boot and swap and then the rest
>> of the space inside an LVM volume group.
> (...)
>> So, if I were you, I'd be doing something like:
>> - 512MiB /boot
>> - 2 GiB swap, or 16GiB if you intend to use it as a hibernate device
>> - Rest as LVM volume group
>>     - 4 GiB / as logical volume
>>     - 4 GiB /var as logical volume
>>     - 50GiB (or whatever satisfies initial demand) /home as logical
>>       volume
> 
> Why don’t you include the swap in LVM ?

You want the swap partition to be encrypted with a random key. Putting it in a LV in the encrypted VG would result in double encryption, which would slow the system down.

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

#202156

Le 05/11/2018 à 09:11, Rick Thomas a écrit :
> 
>> On Nov 4, 2018, at 1:19 AM, Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
>>
>> Le 04/11/2018 à 05:45, Andy Smith a écrit :
>>> 
>>> So, if I were you, I'd be doing something like:
>>> - 512MiB /boot
>>> - 2 GiB swap, or 16GiB if you intend to use it as a hibernate device
>>> - Rest as LVM volume group
>>>      - 4 GiB / as logical volume
>>>      - 4 GiB /var as logical volume
>>>      - 50GiB (or whatever satisfies initial demand) /home as logical
>>>        volume
>>
>> Why don’t you include the swap in LVM ?
> 
> You want the swap partition to be encrypted with a random key.

Why ? What's wrong with a static key ?

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

#202103

Andy Smith <andy@strugglers.net> writes:

I definitely stand by your recommendation of LVM and most of what you
said, but you seem to assume a "server" context, whereas we're talking
about a laptop, so there are a few differences:

> Seems excessive. Without service-specific data or /var, my servers
> generally use under 2GiB for /, so dedicating 40GiB to it is likely
> to be wasteful.

Not sure what your servers run, but my desktops and laptops use up
somewhere between 10GB and 15GB in / (with no special data in /var).
That will largely depend on the amount and kind of packages you install.

>> /swap, encrypted, 16GB (same as RAM)
> Hugely overkill. You do not need for your swap to be as large as
> your RAM unless you are intending to hibernate to disk. If you are
> intending to do that, fair enough, but if not, that's probably 12+
> GiB of expensive SSD that sits idle forever.

A large part of the data in RAM is made up of the disk-cache, and that
doesn't need to go to swap during hibernation.  Furthermore, the
remaining data can be compressed before being written to swap, so the
hibernation data takes a lot less space than your RAM, something like
1/3 maybe, in my experience.

IOW 8GB of swap should be plenty even in case of hibernation.

> There are exceptions to that, but for those times you can simply
> create a swap file and add it.  There is no performance difference
> between a swap file and a dedicated swap partition.

I use LVM volumes for my swap space, which is yet another option, one
that can be grown and shrunk easily, online.

> "How much swap do I require?" is a little bit of a holy war, with
> some even taking the position that the answer is "zero".

It depends on your use case, indeed (e.g. if you store large files in
tmpfs you may like swap space to match).

> So, if I were you, I'd be doing something like:
>
> - 512MiB /boot
> - 2 GiB swap, or 16GiB if you intend to use it as a hibernate device
> - Rest as LVM volume group
>     - 4 GiB / as logical volume
>     - 4 GiB /var as logical volume
>     - 50GiB (or whatever satisfies initial demand) /home as logical
>       volume

I don't see a strong reason to put swap space in a dedicated partition,
so I put mine in LVM.

> If you suddenly find yourself needing something extra, you can
> easily create a new logical volume and mount it. When you get close
> to filling your /home, you can just grow it a bit and grow the
> filesystem online¹.

Indeed, I'd likely use an LVM volume for the VM, for example.

> I would want to be putting all of this on top of software RAID, so
> my system doesn't die when one of the storage devices dies.

But since we're talking about a laptop, it might be impractical.

> If you've never used LVM before then all of this may seem like
> unwanted complexity, but it's a small set of self-contained concepts
> that are very well supported by the Debian installer so to me it's
> well worth getting to grips with.  It will provide you with a lot of
> flexibility throughout the life of the system.

Very much so.  One of the benefits also is that you get to *name* your
volumes, so you don't need to mess with meaningless UUIDs.


        Stefan

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

#202106

Le 04/11/2018 à 16:45, Stefan Monnier a écrit :
> Andy Smith <andy@strugglers.net> writes:
> 
>> Seems excessive. Without service-specific data or /var, my servers
>> generally use under 2GiB for /, so dedicating 40GiB to it is likely
>> to be wasteful.

IMO on a server setup service specific data should be stored in a 
separate filesystem mounted on /srv, not in the / filesystem.

> I use LVM volumes for my swap space, which is yet another option, one
> that can be grown and shrunk easily, online.

You can resize a logical volume online, but AFAIK you cannot resize a 
swap area online (while in use) ; you must disable it (i.e. reload its 
contents back into memory), re-create it with the new size and re-enable 
it. Not an option when the swap space is filling up and you quickly need 
to add some more. Fortunately LVM allows to easily create a new volume 
for extra swap.

> One of the benefits [of LVM] also is that you get to *name* your
> volumes, so you don't need to mess with meaningless UUIDs.

And please, folks, don't :
- give meaningless names such as vg1, vg2, lv1, lv2... to your VGs and LVs ;
- add affixes such as "vg" or "lv" to your VG and LV names. This 
produces ugly device names and is really not needed. You already know 
they are VG or LV names.

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

#202111

>> I use LVM volumes for my swap space, which is yet another option, one
>> that can be grown and shrunk easily, online.
> You can resize a logical volume online, but AFAIK you cannot resize a swap
> area online (while in use) ;

Indeed, in the general case you'll need to do it like:

    lvcreate --name tmpswap --size NNg <VG>
    mkswap /dev/<VG>/tmpswap
    swapon /dev/<VG>/tmpswap
    swapoff /dev/<VG>/swap
    lvresize --size +2g /dev/<VG>/swap
    mkswap /dev/<VG>/swap
    swapon /dev/<VG>/swap
    swapoff /dev/<VG>/tmpswap
    lvremove /dev/<VG>/tmpswap

but in my case, the need to resize was typically when hibernate failed
because the swap was not sized accordingly, so I could just do:

    swapoff /dev/<VG>/swap
    lvresize --size +2g /dev/<VG>/swap
    mkswap /dev/<VG>/swap
    swapon /dev/<VG>/swap

[ Sadly --resizefs doesn't work on a swap partition, AFAICT.  ]


        Stefan

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

#202115

Le 04/11/2018 à 20:56, Stefan Monnier a écrit :
>>> I use LVM volumes for my swap space, which is yet another option, one
>>> that can be grown and shrunk easily, online.
>> You can resize a logical volume online, but AFAIK you cannot resize a swap
>> area online (while in use) ;
> 
> Indeed, in the general case you'll need to do it like:
> 
>      lvcreate --name tmpswap --size NNg <VG>
>      mkswap /dev/<VG>/tmpswap
>      swapon /dev/<VG>/tmpswap
>      swapoff /dev/<VG>/swap
>      lvresize --size +2g /dev/<VG>/swap
>      mkswap /dev/<VG>/swap
>      swapon /dev/<VG>/swap
>      swapoff /dev/<VG>/tmpswap
>      lvremove /dev/<VG>/tmpswap

Or you can just delete the old swap and rename the new one.

       lvcreate --name newswap --size NNg <VG>
       mkswap /dev/<VG>/newswap
       swapon /dev/<VG>/newswap
       swapoff /dev/<VG>/swap
       lvremove /dev/<VG>/swap
       lvrename <VG> newswap swap

> [ Sadly --resizefs doesn't work on a swap partition, AFAICT.  ]

Because there is no swap resizing tool.

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

#202116

>> [ Sadly --resizefs doesn't work on a swap partition, AFAICT.  ]
> Because there is no swap resizing tool.

There is no "online" swap resizing tool, but `mkswap` should work to
resize a (currently unused) swap.


        Stefan

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

#202159

Le 05/11/2018 à 00:10, Stefan Monnier a écrit :
>>> [ Sadly --resizefs doesn't work on a swap partition, AFAICT.  ]
>> Because there is no swap resizing tool.
> 
> There is no "online" swap resizing tool, but `mkswap` should work to
> resize a (currently unused) swap.

mkswap does not even qualify as an offline resizing resizing tool. Such 
tool would preserve existing metadata and data. mkswap just creates a 
brand new swap area and erases previous metadata. The best you can do is 
force the UUID and/or label value when creating the new swap area.

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

#202125

On 2018-11-04, Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
> Le 04/11/2018 à 20:56, Stefan Monnier a écrit :
>>>> I use LVM volumes for my swap space, which is yet another option, one
>>>> that can be grown and shrunk easily, online.
>>> You can resize a logical volume online, but AFAIK you cannot resize a swap
>>> area online (while in use) ;
>> 
>> Indeed, in the general case you'll need to do it like:
>> 
>>      lvcreate --name tmpswap --size NNg <VG>
>>      mkswap /dev/<VG>/tmpswap
>>      swapon /dev/<VG>/tmpswap
>>      swapoff /dev/<VG>/swap
>>      lvresize --size +2g /dev/<VG>/swap
>>      mkswap /dev/<VG>/swap
>>      swapon /dev/<VG>/swap
>>      swapoff /dev/<VG>/tmpswap
>>      lvremove /dev/<VG>/tmpswap
>
> Or you can just delete the old swap and rename the new one.
>
>        lvcreate --name newswap --size NNg <VG>
>        mkswap /dev/<VG>/newswap
>        swapon /dev/<VG>/newswap
>        swapoff /dev/<VG>/swap
>        lvremove /dev/<VG>/swap
>        lvrename <VG> newswap swap
>
>> [ Sadly --resizefs doesn't work on a swap partition, AFAICT.  ]
>
> Because there is no swap resizing tool.
>

I was reading about swap recently and fell upon (like a sword) this
remark from 2005 from Andrew Morton:

  Create the swapfile when the filesystem is young and empty,
  it'll be nice and contiguous.  Once created the kernel will never add
  or remove blocks.

Can it be inferred that excessive (LVM) resizing would be detrimental
contiguity-wise, and thus also performance-wise, or is this
insignificant and not a concern?



-- 
“If a person is not talented enough to be a novelist, not smart enough to be a
lawyer, and his hands are too shaky to perform operations, he becomes a
journalist.” --Norman Mailer 

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

#202144

On Mon, Nov 05, 2018 at 08:34:41AM +0000, Curt wrote:
>I was reading about swap recently and fell upon (like a sword) this
>remark from 2005 from Andrew Morton:
>
>  Create the swapfile when the filesystem is young and empty,
>  it'll be nice and contiguous.  Once created the kernel will never add
>  or remove blocks.
>
>Can it be inferred that excessive (LVM) resizing would be detrimental
>contiguity-wise, and thus also performance-wise, or is this
>insignificant and not a concern?

LVs grow at a multiple of the physical extent size, which is at least 
several MBytes, and usually grow in increments of hundreds or thousands 
of MBytes. It is extremely unlikely that a given LV would end up with 
significant fragmentation in normal operation.

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

#202185

> I was reading about swap recently and fell upon (like a sword) this
> remark from 2005 from Andrew Morton:
>
>   Create the swapfile when the filesystem is young and empty, it'll be
>   nice and contiguous.  Once created the kernel will never add or
>   remove blocks.

He's talking about swap *files*: space in file systems tends to fragment.

> Can it be inferred that excessive (LVM) resizing would be detrimental
> contiguity-wise, and thus also performance-wise, or is this
> insignificant and not a concern?

The issue also exists, but it's *much* less significant, since there's
*much* less activity of adding/removing/resizing, and it's done in much
larger increments and LVM imposes a minimum granularity, so even if it
ends up not 100% contiguous in practice it can be ignored.


        Stefan

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

#202196

On Tue, Nov 06, 2018 at 09:09:16AM -0500, Stefan Monnier wrote:
>> I was reading about swap recently and fell upon (like a sword) this
>> remark from 2005 from Andrew Morton:
>>
>>   Create the swapfile when the filesystem is young and empty, it'll be
>>   nice and contiguous.  Once created the kernel will never add or
>>   remove blocks.
>
>He's talking about swap *files*: space in file systems tends to fragment.

It's pretty unusal for a typical filesystem to be so fragmented these 
days that a new swapfile would have issues, unless the filesystem is 
really full. (All of the current major fs's use extent-based allocation 
and will write a file in a single contiguous block if possible.) So 
overall I'd consider this an issue of mostly historical interest.

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

#202107

On Sun, Nov 04, 2018 at 10:45:04AM -0500, Stefan Monnier wrote:
>>> /swap, encrypted, 16GB (same as RAM)
>> Hugely overkill. You do not need for your swap to be as large as
>> your RAM unless you are intending to hibernate to disk. If you are
>> intending to do that, fair enough, but if not, that's probably 12+
>> GiB of expensive SSD that sits idle forever.
>
>A large part of the data in RAM is made up of the disk-cache, and that
>doesn't need to go to swap during hibernation.  Furthermore, the
>remaining data can be compressed before being written to swap, so the
>hibernation data takes a lot less space than your RAM, something like
>1/3 maybe, in my experience.
>
>IOW 8GB of swap should be plenty even in case of hibernation.

Telling people how much swap they need is just silly. The amount of swap 
you need depends on how much memory it takes to run all of your 
programs, minus the amount of physical ram that you have, plus a safety 
factor and possibly plus the amount of ram it takes to hibernate, if 
you're going to try to do that. My desktop has 16G of RAM, and the other 
day I had 12G consumed by a web browser and 13G consumed by another 
program. If I followed your "8GB is plenty of space" rule I'd have run 
out. In this case I was fine because the swap is SSD backed and 
reasonably fast, and because most of the consumption was a browser being 
stupid and holding onto memory that wasn't actively trying to use. On 
servers I tend to see much less swap pressure because the apps aren't as 
dumb about memory management, or there's much more physical RAM anyway.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web