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

Groups > comp.os.linux.hardware > #812 > unrolled thread

Full SSD support?

Back to article view | Back to comp.os.linux.hardware

Contents

  Full SSD support? ANTant@zimage.com (Ant) - 2011-11-17 20:40 -0600
    Re: Full SSD support? Fredrik Jonson <fredrik@jonson.org> - 2011-11-18 06:31 +0000
      Re: Full SSD support? Ant <ant@zimage.comANT> - 2011-11-18 03:45 -0800
        Re: Full SSD support? David Brown <david@westcontrol.removethisbit.com> - 2011-11-18 14:19 +0100
          Re: Full SSD support? Ant <ant@zimage.comANT> - 2011-11-18 05:46 -0800
          Re: Full SSD support? jnh@VictorTangoEleven.net.invalid (Jordan) - 2011-11-20 03:14 +0000
            Re: Full SSD support? Ant <ant@zimage.comANT> - 2011-11-20 04:26 -0800
              Re: Full SSD support? Richard Kettlewell <rjk@greenend.org.uk> - 2011-11-20 12:41 +0000
                Re: Full SSD support? Ant <ant@zimage.comANT> - 2011-11-20 04:55 -0800
              Re: Full SSD support? jnh@VictorTangoEleven.net.invalid (Jordan) - 2011-11-24 08:42 +0000
                Re: Full SSD support? jnh@VictorTangoEleven.net.invalid (Jordan) - 2011-11-24 08:48 +0000
                  Re: Full SSD support? Richard Kettlewell <rjk@greenend.org.uk> - 2011-11-24 09:18 +0000
                    Re: Full SSD support? David Brown <david@westcontrol.removethisbit.com> - 2011-11-24 11:43 +0100
                      Re: Full SSD support? Richard Kettlewell <rjk@greenend.org.uk> - 2011-11-24 11:21 +0000
                        Re: Full SSD support? David Brown <david@westcontrol.removethisbit.com> - 2011-11-24 13:57 +0100
                          Re: Full SSD support? Richard Kettlewell <rjk@greenend.org.uk> - 2011-11-24 13:20 +0000
                Re: Full SSD support? David Brown <david@westcontrol.removethisbit.com> - 2011-11-24 10:04 +0100
                  Re: Full SSD support? jnh@VictorTangoEleven.net.invalid (Jordan) - 2011-11-27 00:08 +0000
                    Re: Full SSD support? Ant <ant@zimage.comANT> - 2011-11-26 17:57 -0800
                    Re: Full SSD support? David Brown <david@westcontrol.removethisbit.com> - 2011-11-28 09:34 +0100
                Re: Full SSD support? Ant <ant@zimage.comANT> - 2011-11-24 02:26 -0800
                  Re: Full SSD support? jnh@VictorTangoEleven.net.invalid (Jordan) - 2011-11-27 00:12 +0000
                    Re: Full SSD support? Ant <ant@zimage.comANT> - 2011-11-26 17:58 -0800
                      Re: Full SSD support? David Brown <david@westcontrol.removethisbit.com> - 2011-11-28 09:42 +0100
                        Re: Full SSD support? Ant <ant@zimage.comANT> - 2011-11-28 07:14 -0800
                          Re: Full SSD support? David Brown <david@westcontrol.removethisbit.com> - 2011-11-29 09:09 +0100
                            Re: Full SSD support? Ant <ant@zimage.comANT> - 2011-11-29 02:27 -0800
                              Re: Full SSD support? David Brown <david@westcontrol.removethisbit.com> - 2011-11-29 12:43 +0100
                                Re: Full SSD support? Ant <ant@zimage.comANT> - 2011-11-29 05:45 -0800
      Re: Full SSD support? Andreas Dehmel <blackhole.8.zarquon42@spamgourmet.com> - 2011-11-20 14:54 +0100
        Re: Full SSD support? Richard Kettlewell <rjk@greenend.org.uk> - 2011-11-20 19:06 +0000
    Re: Full SSD support? 7 <email_at_www_at_enemygadgets_dot_com@enemygadgets.com> - 2011-11-20 01:20 +0000
      Re: Full SSD support? jnh@VictorTangoEleven.net.invalid (Jordan) - 2011-11-20 03:20 +0000
      Re: Full SSD support? Ant <ant@zimage.comANT> - 2011-11-20 04:27 -0800
    Re: Full SSD support? chris <chrisdhaag@googlemail.com> - 2011-11-20 17:12 +0100
      Re: Full SSD support? Ant <ant@zimage.comANT> - 2011-11-20 08:54 -0800
        Re: Full SSD support? David Brown <david.brown@removethis.hesbynett.no> - 2011-11-20 19:32 +0100
          Re: Full SSD support? Ant <ant@zimage.comANT> - 2011-11-20 11:02 -0800
            Re: Full SSD support? David Brown <david.brown@removethis.hesbynett.no> - 2011-11-20 22:02 +0100
              Re: Full SSD support? Ant <ant@zimage.comANT> - 2011-11-20 14:03 -0800
                Re: Full SSD support? David Brown <david@westcontrol.removethisbit.com> - 2011-11-21 10:12 +0100
                  Re: Full SSD support? Ant <ant@zimage.comANT> - 2011-11-21 01:38 -0800
              Re: Full SSD support? Ant <ant@zimage.comANT> - 2011-11-23 23:27 -0800
              Re: Full SSD support? Ant <ant@zimage.comANT> - 2011-11-24 22:07 -0800
                Re: Full SSD support? david <none@nospam.com> - 2011-11-25 12:30 +0000
                  Re: Full SSD support? Ant <ant@zimage.comANT> - 2011-11-25 07:00 -0800
          Re: Full SSD support? André Gillibert <MetaEntropy.removeThis@gmail.com> - 2011-11-22 00:56 +0100

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

#812 — Full SSD support?

Hello.

I am thinking of replacing my old PATA/IDE HDDs with a big SSD. Does 
Linux/Debian fully support this with the latest Kernels? I am planning 
to do a clean net-install.

Thank you in advance. :)
-- 
Quote of the Week: "Trivial hurts, tiny human accidents," said Firenze, 
as his hooves thudded over the mossy floor. "These are of no more 
significance than the scurryings of ants to the wide universe, and are 
unaffected by planetary movements." --Harry Potter book
  /\___/\         Ant @ http://antfarm.home.dhs.org (Personal Web Site)
 / /\ /\ \                 Ant's Quality Foraged Links: http://aqfl.net
| |o   o| |
   \ _ /           Please nuke ANT if replying by e-mail. If crediting,
    ( )          then please kindly use Ant nickname and AQFL URL/link.

[toc] | [next] | [standalone]

#813

Ant wrote:

>  I am thinking of replacing my old PATA/IDE HDDs with a big SSD. Does
>  Linux/Debian fully support this with the latest Kernels?

I've used ssd disks on my debian system for two years now. Just did a
standard install back then, so you should have no problem here. SSD disks
show up in the installer just like any other hard disk does.

I'm not aware of any ssd disk with pata though, only sata, so I assume that
your computer supports sata?

--
Fredrik Jonson

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

#814

On 11/17/2011 10:31 PM PT, Fredrik Jonson typed:

>>   I am thinking of replacing my old PATA/IDE HDDs with a big SSD. Does
>>   Linux/Debian fully support this with the latest Kernels?
>
> I've used ssd disks on my debian system for two years now. Just did a
> standard install back then, so you should have no problem here. SSD disks
> show up in the installer just like any other hard disk does.
>
> I'm not aware of any ssd disk with pata though, only sata, so I assume that
> your computer supports sata?

Yeah, it does it looks like. I was going to buy SATA HDDs, but they're 
expensive due to Thailand's floods. :( So, no limitation on maximum 
sizes, old BIOS limitations, Kernel versions, etc.?
-- 
"No, I'd prefer a cooler WITHOUT an ant-door, thank you..." --unknown
    /\___/\               Ant @ http://antfarm.ma.cx (Personal Web Site)
   / /\ /\ \                Ant's Quality Foraged Links: http://aqfl.net
  | |o   o| |
     \ _ /        If crediting, then use Ant nickname and AQFL URL/link.
      ( )         If e-mailing, then axe ANT from its address if needed.
Ant is currently not listening to any songs on this computer.

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

#815

On 18/11/2011 12:45, Ant wrote:
> On 11/17/2011 10:31 PM PT, Fredrik Jonson typed:
>
>>> I am thinking of replacing my old PATA/IDE HDDs with a big SSD. Does
>>> Linux/Debian fully support this with the latest Kernels?
>>
>> I've used ssd disks on my debian system for two years now. Just did a
>> standard install back then, so you should have no problem here. SSD disks
>> show up in the installer just like any other hard disk does.
>>
>> I'm not aware of any ssd disk with pata though, only sata, so I assume
>> that
>> your computer supports sata?
>
> Yeah, it does it looks like. I was going to buy SATA HDDs, but they're
> expensive due to Thailand's floods. :( So, no limitation on maximum
> sizes, old BIOS limitations, Kernel versions, etc.?

SSD's act exactly like HD's, just smaller, lower power, faster and more 
expensive.  If your system works with a SATA HD, then it will work with 
a SATA SSD.

There are a few things that can make them even faster, however.  One is 
making sure that your partitions are nicely aligned - the modern 
standard is to align to 1 MB to be future proof, but 128 KB is usually 
good enough.  Any recent version of fdisk or other partitioning tools 
will do that automatically.

"Trim" support has some benefits for earlier SSD's, but it's effect is 
often overrated.  It makes little difference if you buy a modern SSD of 
good size (over 64 GB) with decent garbage collection.

IO scheduling can also make a little difference.  Since there is no need 
to order operations to suit the disk head (there being no disk head in 
an SSD), the NOOP scheduler is a bit more efficient.  Modern distros and 
kernels will identify the SSD and do this automatically, with older 
kernels you can specify it manually.

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

#816

On 11/18/2011 5:19 AM PT, David Brown typed:

> On 18/11/2011 12:45, Ant wrote:
>> On 11/17/2011 10:31 PM PT, Fredrik Jonson typed:
>>
>>>> I am thinking of replacing my old PATA/IDE HDDs with a big SSD. Does
>>>> Linux/Debian fully support this with the latest Kernels?
>>>
>>> I've used ssd disks on my debian system for two years now. Just did a
>>> standard install back then, so you should have no problem here. SSD
>>> disks
>>> show up in the installer just like any other hard disk does.
>>>
>>> I'm not aware of any ssd disk with pata though, only sata, so I assume
>>> that
>>> your computer supports sata?
>>
>> Yeah, it does it looks like. I was going to buy SATA HDDs, but they're
>> expensive due to Thailand's floods. :( So, no limitation on maximum
>> sizes, old BIOS limitations, Kernel versions, etc.?
>
> SSD's act exactly like HD's, just smaller, lower power, faster and more
> expensive. If your system works with a SATA HD, then it will work with a
> SATA SSD.
>
> There are a few things that can make them even faster, however. One is
> making sure that your partitions are nicely aligned - the modern
> standard is to align to 1 MB to be future proof, but 128 KB is usually
> good enough. Any recent version of fdisk or other partitioning tools
> will do that automatically.

Cool, so the default settings in Debian and Ubuntu's net-installers will 
do that. =)


> "Trim" support has some benefits for earlier SSD's, but it's effect is
> often overrated. It makes little difference if you buy a modern SSD of
> good size (over 64 GB) with decent garbage collection.
>
> IO scheduling can also make a little difference. Since there is no need
> to order operations to suit the disk head (there being no disk head in
> an SSD), the NOOP scheduler is a bit more efficient. Modern distros and
> kernels will identify the SSD and do this automatically, with older
> kernels you can specify it manually.

Cool. Hopefully, Debian and Ubuntu's net-installers will do handle them. :)
-- 
"No, I'd prefer a cooler WITHOUT an ant-door, thank you..." --unknown
    /\___/\               Ant @ http://antfarm.ma.cx (Personal Web Site)
   / /\ /\ \                Ant's Quality Foraged Links: http://aqfl.net
  | |o   o| |
     \ _ /        If crediting, then use Ant nickname and AQFL URL/link.
      ( )         If e-mailing, then axe ANT from its address if needed.
Ant is currently not listening to any songs on this computer.

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

#818

In article <jLidnUreEd-WwFvTnZ2dnUVZ8tCdnZ2d@lyse.net>,
David Brown  <david@westcontrol.removethisbit.com> wrote:
>
>SSD's act exactly like HD's, just smaller, lower power, faster and more 
>expensive.  If your system works with a SATA HD, then it will work with 
>a SATA SSD.
>
>There are a few things that can make them even faster, however.  One is 
>making sure that your partitions are nicely aligned - the modern 
>standard is to align to 1 MB to be future proof, but 128 KB is usually 
>good enough.  Any recent version of fdisk or other partitioning tools 
>will do that automatically.
>
>"Trim" support has some benefits for earlier SSD's, but it's effect is 
>often overrated.  It makes little difference if you buy a modern SSD of 
>good size (over 64 GB) with decent garbage collection.

I think TRIM is still worth turning on if you're starting from
scratch.  There should be no downside to using it, except that
it restricts your choice of filesystems... the only Linux fs I
know of supporting TRIM so far is 'ext4.'

After choosing this fs, just add 'discard' to the mount options in
/etc/fstab.  Some distributions' installers may be smart enough now
to do that on their own when an SSD is detected.


>IO scheduling can also make a little difference.  Since there is no need 
>to order operations to suit the disk head (there being no disk head in 
>an SSD), the NOOP scheduler is a bit more efficient.  Modern distros and 
>kernels will identify the SSD and do this automatically, with older 
>kernels you can specify it manually.

echo noop > /sys/block/sda/queue/scheduler

 or (my preference):

echo deadline > /sys/block/sda/queue/scheduler

which seems to give slightly better responsiveness when heavy
writes are going on.  Be sure any mechanical drives in the system
remain set at cfq (or anticipatory).
-- 
Jordan.

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

#820

On 11/19/2011 7:14 PM PT, Jordan typed:

> I think TRIM is still worth turning on if you're starting from
> scratch.  There should be no downside to using it, except that
> it restricts your choice of filesystems... the only Linux fs I
> know of supporting TRIM so far is 'ext4.'
 >
> After choosing this fs, just add 'discard' to the mount options in
> /etc/fstab.  Some distributions' installers may be smart enough now
> to do that on their own when an SSD is detected.

Is EXT4 FS the default FS in Debian's net-installer? The last time I had 
to I had to do a Debian installation was back in 2005 (using EXT3 FS). I 
think so many things might have changed over the years. I might be 
getting a SSD and doing a clean Debian installation for my long 
Thanksgiving 2011 weekend (Thursday). :)


>> IO scheduling can also make a little difference.  Since there is no need
>> to order operations to suit the disk head (there being no disk head in
>> an SSD), the NOOP scheduler is a bit more efficient.  Modern distros and
>> kernels will identify the SSD and do this automatically, with older
>> kernels you can specify it manually.
>
> echo noop>  /sys/block/sda/queue/scheduler
>
>   or (my preference):
>
> echo deadline>  /sys/block/sda/queue/scheduler
>
> which seems to give slightly better responsiveness when heavy
> writes are going on.  Be sure any mechanical drives in the system
> remain set at cfq (or anticipatory).

I am hoping I don't have to tweak the technical parts like discard, 
TRIM, etc. I just want to install (have lots of softwares!), 
reconfigure, and be done by the time my long weekend is over (Monday). :(
-- 
"All good work is done the way ants do things: Little by little." 
--Lafcadio Hearn
    /\___/\               Ant @ http://antfarm.ma.cx (Personal Web Site)
   / /\ /\ \                Ant's Quality Foraged Links: http://aqfl.net
  | |o   o| |
     \ _ /        If crediting, then use Ant nickname and AQFL URL/link.
      ( )         If e-mailing, then axe ANT from its address if needed.
Ant is currently not listening to any songs on this computer.

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

#822

Ant <ant@zimage.comANT> writes:
> I am hoping I don't have to tweak the technical parts like discard,
> TRIM, etc. I just want to install (have lots of softwares!),
> reconfigure, and be done by the time my long weekend is over
> (Monday). :(

You don't have to tweak anything if you don't have the time or
inclination to do so.

-- 
http://www.greenend.org.uk/rjk/

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

#823

On 11/20/2011 4:41 AM PT, Richard Kettlewell typed:

>> I am hoping I don't have to tweak the technical parts like discard,
>> TRIM, etc. I just want to install (have lots of softwares!),
>> reconfigure, and be done by the time my long weekend is over
>> (Monday). :(
>
> You don't have to tweak anything if you don't have the time or
> inclination to do so.

OK good. Whew. :)
-- 
"If they are offered winged ants, people will eat them." --African
    /\___/\               Ant @ http://antfarm.ma.cx (Personal Web Site)
   / /\ /\ \                Ant's Quality Foraged Links: http://aqfl.net
  | |o   o| |
     \ _ /        If crediting, then use Ant nickname and AQFL URL/link.
      ( )         If e-mailing, then axe ANT from its address if needed.
Ant is currently not listening to any songs on this computer.

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

#852

In article <y4OdnfUdopWKb1XTnZ2dnUVZ_sSdnZ2d@earthlink.com>,
Ant  <ant@zimage.comANT> wrote:
>On 11/19/2011 7:14 PM PT, Jordan typed:
>
>> I think TRIM is still worth turning on if you're starting from
>> scratch.  There should be no downside to using it, except that
>> it restricts your choice of filesystems... the only Linux fs I
>> know of supporting TRIM so far is 'ext4.'
> >
>> After choosing this fs, just add 'discard' to the mount options in
>> /etc/fstab.  Some distributions' installers may be smart enough now
>> to do that on their own when an SSD is detected.
>
>Is EXT4 FS the default FS in Debian's net-installer? The last time I had 
>to I had to do a Debian installation was back in 2005 (using EXT3 FS).

ext3 is still the default as of 6.0.3 Squeeze.  I remember this
because I net-installed it on a new server yesterday.

http://wiki.debian.org/Ext4  suggests the installer allows ext4 as an
option, though.

It's also possible to convert an existing ext3 filesystem to ext4.

>I think so many things might have changed over the years. I might
>be getting a SSD and doing a clean Debian installation for my long
>Thanksgiving 2011 weekend (Thursday). :)

If you have a large amount of RAM, you might want to consider
running without swap (create the partition, but only swapon when
you need it, for huge complies, etc.), and use a tmpfs RAMdisk for
things like browser caches.  Or put these on a standard HD if one
is present.

This can greatly reduce unnecesssary writes to the SSD, which I
still try to minimize even though modern devices are supposed to
have such good wear-leveling that it doesn't matter as much as it
once did.

>[...]

>I am hoping I don't have to tweak the technical parts like discard, 
>TRIM, etc. I just want to install (have lots of softwares!), 
>reconfigure, and be done by the time my long weekend is over (Monday). :(

None of it's really necessary... just a matter of how obsessive you
want to be about minor optimizations ;)

-- 
Jordan.

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

#853

In article <jal014$ij5$1@dont-email.me>,
Jordan <jnh@VictorTangoEleven.net.invalid> wrote:
>
>If you have a large amount of RAM, you might want to consider
>running without swap (create the partition, but only swapon when
>you need it, for huge complies, etc.), and use a tmpfs RAMdisk for
>things like browser caches.  Or put these on a standard HD if one
>is present.

Also /tmp on tmpfs, as someone else mentioned, which is a good idea
whether you have an SSD or not (unless you're in the dangerous
habit of dumping huge files in /tmp, as a friend of mine insists on
doing...)


-- 
Jordan.

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

#855

jnh@VictorTangoEleven.net.invalid (Jordan) writes:
> Jordan <jnh@VictorTangoEleven.net.invalid> wrote:

>> If you have a large amount of RAM, you might want to consider running
>> without swap (create the partition, but only swapon when you need it,
>> for huge complies, etc.), and use a tmpfs RAMdisk for things like
>> browser caches.  Or put these on a standard HD if one is present.
>
> Also /tmp on tmpfs, as someone else mentioned, which is a good idea
> whether you have an SSD or not (unless you're in the dangerous habit
> of dumping huge files in /tmp, as a friend of mine insists on
> doing...)

That just means you need more swap.

Now what would be interesting is if filesystems could automatically
allow free space to be used as swap...

-- 
http://www.greenend.org.uk/rjk/

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

#858

On 24/11/2011 10:18, Richard Kettlewell wrote:
> jnh@VictorTangoEleven.net.invalid (Jordan) writes:
>> Jordan<jnh@VictorTangoEleven.net.invalid>  wrote:
>
>>> If you have a large amount of RAM, you might want to consider running
>>> without swap (create the partition, but only swapon when you need it,
>>> for huge complies, etc.), and use a tmpfs RAMdisk for things like
>>> browser caches.  Or put these on a standard HD if one is present.
>>
>> Also /tmp on tmpfs, as someone else mentioned, which is a good idea
>> whether you have an SSD or not (unless you're in the dangerous habit
>> of dumping huge files in /tmp, as a friend of mine insists on
>> doing...)
>
> That just means you need more swap.
>

Correct.

But it is more efficient (both in terms of speed and in terms of number 
of writes to the SSD) to put temporary files in tmpfs even if they end 
up written out to swap, as compared to a normal filesystem on the disk.

> Now what would be interesting is if filesystems could automatically
> allow free space to be used as swap...
>

In most cases, the size of the disk far outweighs the size of the 
memory, and therefore an appropriately sized swap partition only takes a 
small part of the disk.  Thus it is easy enough just to dedicate a 
single partition to swap - it makes little difference to the free space 
of the disk.

The balance is a bit different now as machines get more memory, and 
SSD's have smaller capacities than HD's - memory is now a more 
significant proportion of the disk size.

Normally you don't want to have /too/ big a swap - there comes a point 
when you want the kernel to kill overweight processes rather than 
slowing down everything.  But if you are a heavy tmpfs user, you might 
want more swap.

Fortunately, you can use files for swap as well as partitions.  So you 
could fairly easily write a user-mode daemon that monitors free memory 
and swap usage, and adds in or removes swap files as needed.  It could 
also monitor your tmpfs filesystems and grow them as needed.

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

#859

David Brown <david@westcontrol.removethisbit.com> writes:
> Richard Kettlewell wrote:

>> Now what would be interesting is if filesystems could automatically
>> allow free space to be used as swap...
>
> In most cases, the size of the disk far outweighs the size of the
> memory, and therefore an appropriately sized swap partition only takes
> a small part of the disk.  Thus it is easy enough just to dedicate a
> single partition to swap - it makes little difference to the free
> space of the disk.
>
> The balance is a bit different now as machines get more memory, and
> SSD's have smaller capacities than HD's - memory is now a more
> significant proportion of the disk size.

We were discussing use of swap for /tmp, in which case the size of
memory is completely irrelevant; what matters is the size of files you
may want to put in /tmp.

> Normally you don't want to have /too/ big a swap - there comes a point
> when you want the kernel to kill overweight processes rather than
> slowing down everything.

Total swap space isn't the only way to achieve this; RLIMIT_AS can do it
on a per-process basis, for instance.  AFAICT it measures slightly the
wrong thing but it's probably good enough for this particular purpose.

In any case you could have a configurable limit on the total swap
available to processes too (just like there's a limit on how much a
tmpfs can use).

> But if you are a heavy tmpfs user, you might want more swap.
> 
> Fortunately, you can use files for swap as well as partitions.  So you
> could fairly easily write a user-mode daemon that monitors free memory
> and swap usage, and adds in or removes swap files as needed.  It could
> also monitor your tmpfs filesystems and grow them as needed.

Indeed, Apple have already done the first part of that.  Having the
filesystem do it automatically is just a lower-level variant on the same
idea.

-- 
http://www.greenend.org.uk/rjk/

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

#860

On 24/11/2011 12:21, Richard Kettlewell wrote:
> David Brown<david@westcontrol.removethisbit.com>  writes:
>> Richard Kettlewell wrote:
>
>>> Now what would be interesting is if filesystems could automatically
>>> allow free space to be used as swap...
>>
>> In most cases, the size of the disk far outweighs the size of the
>> memory, and therefore an appropriately sized swap partition only takes
>> a small part of the disk.  Thus it is easy enough just to dedicate a
>> single partition to swap - it makes little difference to the free
>> space of the disk.
>>
>> The balance is a bit different now as machines get more memory, and
>> SSD's have smaller capacities than HD's - memory is now a more
>> significant proportion of the disk size.
>
> We were discussing use of swap for /tmp, in which case the size of
> memory is completely irrelevant; what matters is the size of files you
> may want to put in /tmp.

It's not irrelevant.  You can't enable some swap space but somehow 
reserve it for only tmpfs - the system will use it for any swap needs, 
including tmpfs.  So you do need to keep an overall picture in mind.

However, tmpfs is the main reason I use swap on my big machines - with 
12 or 16 GB main memory I don't often run out of real memory (though 
virtual machines eat up quite a lot).

>
>> Normally you don't want to have /too/ big a swap - there comes a point
>> when you want the kernel to kill overweight processes rather than
>> slowing down everything.
>
> Total swap space isn't the only way to achieve this; RLIMIT_AS can do it
> on a per-process basis, for instance.  AFAICT it measures slightly the
> wrong thing but it's probably good enough for this particular purpose.
>

Good idea.

There is certainly lots you can do to limit or control processes, 
depending on your needs.

> In any case you could have a configurable limit on the total swap
> available to processes too (just like there's a limit on how much a
> tmpfs can use).
>

Correct.

You probably already know, but others might not - tmpfs defaults to a 
limit of half the physical ram size.  But it's easy to give a new limit 
when creating it, or by using something like "mount -o remount,size=4G 
/tmp" to change size on the fly.

>> But if you are a heavy tmpfs user, you might want more swap.
>>
>> Fortunately, you can use files for swap as well as partitions.  So you
>> could fairly easily write a user-mode daemon that monitors free memory
>> and swap usage, and adds in or removes swap files as needed.  It could
>> also monitor your tmpfs filesystems and grow them as needed.
>
> Indeed, Apple have already done the first part of that.  Having the
> filesystem do it automatically is just a lower-level variant on the same
> idea.
>

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

#861

David Brown <david@westcontrol.removethisbit.com> writes:
> On 24/11/2011 12:21, Richard Kettlewell wrote:
>> David Brown<david@westcontrol.removethisbit.com>  writes:
>>> Richard Kettlewell wrote:

>>>> Now what would be interesting is if filesystems could automatically
>>>> allow free space to be used as swap...
>>>
>>> In most cases, the size of the disk far outweighs the size of the
>>> memory, and therefore an appropriately sized swap partition only takes
>>> a small part of the disk.  Thus it is easy enough just to dedicate a
>>> single partition to swap - it makes little difference to the free
>>> space of the disk.
>>>
>>> The balance is a bit different now as machines get more memory, and
>>> SSD's have smaller capacities than HD's - memory is now a more
>>> significant proportion of the disk size.
>>
>> We were discussing use of swap for /tmp, in which case the size of
>> memory is completely irrelevant; what matters is the size of files you
>> may want to put in /tmp.
>
> It's not irrelevant.  You can't enable some swap space but somehow
> reserve it for only tmpfs - the system will use it for any swap needs,
> including tmpfs.  So you do need to keep an overall picture in mind.

I already addressed that point.  Do try to keep up.

-- 
http://www.greenend.org.uk/rjk/

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

#854

On 24/11/2011 09:42, Jordan wrote:
> In article<y4OdnfUdopWKb1XTnZ2dnUVZ_sSdnZ2d@earthlink.com>,
> Ant<ant@zimage.comANT>  wrote:
>> On 11/19/2011 7:14 PM PT, Jordan typed:
>>
>>> I think TRIM is still worth turning on if you're starting from
>>> scratch.  There should be no downside to using it, except that
>>> it restricts your choice of filesystems... the only Linux fs I
>>> know of supporting TRIM so far is 'ext4.'
>>>
>>> After choosing this fs, just add 'discard' to the mount options in
>>> /etc/fstab.  Some distributions' installers may be smart enough now
>>> to do that on their own when an SSD is detected.
>>
>> Is EXT4 FS the default FS in Debian's net-installer? The last time I had
>> to I had to do a Debian installation was back in 2005 (using EXT3 FS).
>
> ext3 is still the default as of 6.0.3 Squeeze.  I remember this
> because I net-installed it on a new server yesterday.
>
> http://wiki.debian.org/Ext4  suggests the installer allows ext4 as an
> option, though.
>
> It's also possible to convert an existing ext3 filesystem to ext4.
>

It is better to make it ext4 in the first place.  As well as being 
faster to create (ext4 delays creation of inode tables), it is easier to 
ensure that you are using newer ext4 features such as extents.  Even if 
they are enabled after the conversion, files that were on the system 
while it is ext3 will not suddenly start using extents once you change 
to ext4.

>> I think so many things might have changed over the years. I might
>> be getting a SSD and doing a clean Debian installation for my long
>> Thanksgiving 2011 weekend (Thursday). :)
>
> If you have a large amount of RAM, you might want to consider
> running without swap (create the partition, but only swapon when
> you need it, for huge complies, etc.), and use a tmpfs RAMdisk for
> things like browser caches.  Or put these on a standard HD if one
> is present.
>

Just make the swap like normal, and enable it like normal.  If it's not 
needed, it won't be used - and if it /is/ needed, it /will/ be used. 
Why make things more awkward for yourself by having to manually enable 
it when you need it?

If you have a small or medium amount of RAM (these things are all 
relative), then the system may choose to push applications into swap 
even if it has enough ram, if it thinks the ram is better used as cache 
space.  Usually, the system is correct.  But if you are seeing this and 
you want to avoid it (perhaps you are using an older SSD), you can 
adjust the swapiness parameter rather than manually enabling and 
disabling the swap.


> This can greatly reduce unnecesssary writes to the SSD, which I
> still try to minimize even though modern devices are supposed to
> have such good wear-leveling that it doesn't matter as much as it
> once did.
>
>> [...]
>
>> I am hoping I don't have to tweak the technical parts like discard,
>> TRIM, etc. I just want to install (have lots of softwares!),
>> reconfigure, and be done by the time my long weekend is over (Monday). :(
>
> None of it's really necessary... just a matter of how obsessive you
> want to be about minor optimizations ;)
>

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

#867

In article <kIWdnao6nYjZl1PTnZ2dnUVZ8oGdnZ2d@lyse.net>,
David Brown  <david@westcontrol.removethisbit.com> wrote:
>On 24/11/2011 09:42, Jordan wrote:
>>
>> It's also possible to convert an existing ext3 filesystem to ext4.
>>
>
>It is better to make it ext4 in the first place.  As well as being 
>faster to create (ext4 delays creation of inode tables), it is easier to 
>ensure that you are using newer ext4 features such as extents.  Even if 
>they are enabled after the conversion, files that were on the system 
>while it is ext3 will not suddenly start using extents once you change 
>to ext4.

Good points.

>> If you have a large amount of RAM, you might want to consider
>> running without swap (create the partition, but only swapon when
>> you need it, for huge complies, etc.), and use a tmpfs RAMdisk for
>> things like browser caches.  Or put these on a standard HD if one
>> is present.
>
>Just make the swap like normal, and enable it like normal.  If it's not 
>needed, it won't be used - and if it /is/ needed, it /will/ be used. 
>Why make things more awkward for yourself by having to manually enable 
>it when you need it?

The only reason I do this on my main workstation is that the swap
partition lives on a mechanical HD, which is normally kept spun
down to save power/heat and maintain zero noise whenever possible
(this is a fanless system also).

>If you have a small or medium amount of RAM (these things are all 
>relative), then the system may choose to push applications into swap 
>even if it has enough ram, if it thinks the ram is better used as cache 
>space.  Usually, the system is correct.  But if you are seeing this and 
>you want to avoid it (perhaps you are using an older SSD), you can 
>adjust the swapiness parameter rather than manually enabling and 
>disabling the swap.

True enough.


-- 
Jordan.

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

#869

On 11/26/2011 4:08 PM PT, Jordan typed:

>>> It's also possible to convert an existing ext3 filesystem to ext4.
>>
>> It is better to make it ext4 in the first place.  As well as being
>> faster to create (ext4 delays creation of inode tables), it is easier to
>> ensure that you are using newer ext4 features such as extents.  Even if
>> they are enabled after the conversion, files that were on the system
>> while it is ext3 will not suddenly start using extents once you change
>> to ext4.
>
> Good points.

My 115 GB SSD is all EXT4 FS with the latest stable Debian installation.


>>> If you have a large amount of RAM, you might want to consider
>>> running without swap (create the partition, but only swapon when
>>> you need it, for huge complies, etc.), and use a tmpfs RAMdisk for
>>> things like browser caches.  Or put these on a standard HD if one
>>> is present.
>>
>> Just make the swap like normal, and enable it like normal.  If it's not
>> needed, it won't be used - and if it /is/ needed, it /will/ be used.
>> Why make things more awkward for yourself by having to manually enable
>> it when you need it?
>
> The only reason I do this on my main workstation is that the swap
> partition lives on a mechanical HD, which is normally kept spun
> down to save power/heat and maintain zero noise whenever possible
> (this is a fanless system also).

>> If you have a small or medium amount of RAM (these things are all
>> relative), then the system may choose to push applications into swap
>> even if it has enough ram, if it thinks the ram is better used as cache
>> space.  Usually, the system is correct.  But if you are seeing this and
>> you want to avoid it (perhaps you are using an older SSD), you can
>> adjust the swapiness parameter rather than manually enabling and
>> disabling the swap.
>
> True enough.

$ df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sdb1               960504    184760    726952  21% /
tmpfs                  1030332         0   1030332   0% /lib/init/rw
udev                   1025472       272   1025200   1% /dev
tmpfs                  1030332        88   1030244   1% /dev/shm
/dev/sdb9             50013916   6856324  40617000  15% /home
/dev/sdb5               960504     17640    894072   2% /tmp
/dev/sdb8             49982172   6040980  41402184  13% /usr
/dev/sdb6              4804736   1691104   2869564  38% /var

top - 17:55:39 up 35 min,  1 user,  load average: 0.08, 0.02, 0.04
Tasks: 206 total,   1 running, 205 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.2%us,  0.3%sy,  0.0%ni, 99.5%id,  0.0%wa,  0.0%hi,  0.0%si, 
0.0%st
Mem:   2060668k total,   724436k used,  1336232k free,    41660k buffers
Swap:  3905528k total,        0k used,  3905528k free,   400232k cached
...

I hope that swap isn't too big/small. I only have two GB of RAM. I gave 
it bigger size in case the newer software products need more swap memory 
usage.


Ugh, reinstalling and reconfiguring my programs is such a pain evne if I 
have backups to look at old configurations and stuff. :(
-- 
"Everything tastes better at a picnic... the ants, the sand, 
everything." --unknown
    /\___/\               Ant @ http://antfarm.ma.cx (Personal Web Site)
   / /\ /\ \                Ant's Quality Foraged Links: http://aqfl.net
  | |o   o| |
     \ _ /        If crediting, then use Ant nickname and AQFL URL/link.
      ( )         If e-mailing, then axe ANT from its address if needed.
Ant is currently not listening to any songs on this computer.

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

#874

On 27/11/2011 01:08, Jordan wrote:
> In article<kIWdnao6nYjZl1PTnZ2dnUVZ8oGdnZ2d@lyse.net>,
> David Brown<david@westcontrol.removethisbit.com>  wrote:
>> On 24/11/2011 09:42, Jordan wrote:
>>>
>>> It's also possible to convert an existing ext3 filesystem to ext4.
>>>
>>
>> It is better to make it ext4 in the first place.  As well as being
>> faster to create (ext4 delays creation of inode tables), it is easier to
>> ensure that you are using newer ext4 features such as extents.  Even if
>> they are enabled after the conversion, files that were on the system
>> while it is ext3 will not suddenly start using extents once you change
>> to ext4.
>
> Good points.
>
>>> If you have a large amount of RAM, you might want to consider
>>> running without swap (create the partition, but only swapon when
>>> you need it, for huge complies, etc.), and use a tmpfs RAMdisk for
>>> things like browser caches.  Or put these on a standard HD if one
>>> is present.
>>
>> Just make the swap like normal, and enable it like normal.  If it's not
>> needed, it won't be used - and if it /is/ needed, it /will/ be used.
>> Why make things more awkward for yourself by having to manually enable
>> it when you need it?
>
> The only reason I do this on my main workstation is that the swap
> partition lives on a mechanical HD, which is normally kept spun
> down to save power/heat and maintain zero noise whenever possible
> (this is a fanless system also).
>

That's no problem - enable your swap at startup, and tell the system to 
keep the harddisks spun down when possible (use the "power management" 
settings of your distro).  Linux will not access the swap partition 
unless it needs to, and will only spin up the disk when it has a reason 
for it.  You might get some brief disk activity at boot time, but that's 
all.  Again, depending on the size of your ram, you may want to change 
swapiness to discourage the use of swap.

>> If you have a small or medium amount of RAM (these things are all
>> relative), then the system may choose to push applications into swap
>> even if it has enough ram, if it thinks the ram is better used as cache
>> space.  Usually, the system is correct.  But if you are seeing this and
>> you want to avoid it (perhaps you are using an older SSD), you can
>> adjust the swapiness parameter rather than manually enabling and
>> disabling the swap.
>
> True enough.
>
>

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

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

Back to top | Article view | comp.os.linux.hardware

csiph-web