[gentoo-user] SSDs, swap, caching, other unusual uses

[gentoo-user] SSDs, swap, caching, other unusual uses

[Michael Mol]

Something that's been tickling my brain for a couple years now, and
you guys are probably the right ones to ask.

I haven't dropped coin for an SSD (yet), but I was wondering about
uses for them beyond using them for / or /home.

1) What about sitting swap (partition, file, whatever) on the SSD?
Presumably, in scenarios where expanding the RAM in a system is
prohibitively expensive, an SSD could reduce the impact of swap
thrash.


2) While my system rarely goes above using 2-2.5GB of RAM, I enjoy
having 6-8GB of RAM, just for the file cache. Of course, I lose that
when I reboot; the cache needs to be repopulated. Has there been any
work in the kernel for doing things like Vista/Win7's ReadyBoost?
ReadyBoost has a ridiculous limit to only using 4GB of a flash drive,
but I'd think that an 80GB SSD would be a massive performance
improvement.

Obviously, for something like Gentoo, putting an SSD-based filesystem
under /var/tmp makes a lot of sense, but what other uses have been
tried? How'd they work out?

-- 
:wq

Re: [gentoo-user] SSDs, swap, caching, other unusual uses

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 1617 bytes --]

Am 29.07.2011 20:18, schrieb Michael Mol:
> Something that's been tickling my brain for a couple years now, and
> you guys are probably the right ones to ask.
> 
> I haven't dropped coin for an SSD (yet), but I was wondering about
> uses for them beyond using them for / or /home.
> 
> 1) What about sitting swap (partition, file, whatever) on the SSD?
> Presumably, in scenarios where expanding the RAM in a system is
> prohibitively expensive, an SSD could reduce the impact of swap
> thrash.
> 

Sure why not. However, if you plan to swap constantly, I'd recommend
doing a prediction of the life-time. For normal usage, the number of
possible write cycles should be sufficient.
> 
> 2) While my system rarely goes above using 2-2.5GB of RAM, I enjoy
> having 6-8GB of RAM, just for the file cache. Of course, I lose that
> when I reboot; the cache needs to be repopulated. Has there been any
> work in the kernel for doing things like Vista/Win7's ReadyBoost?
> ReadyBoost has a ridiculous limit to only using 4GB of a flash drive,
> but I'd think that an 80GB SSD would be a massive performance
> improvement.
> 

You should try sys-kernel/tuxonice-sources for suspend-to-disk. It
preserves the cache as well.

> Obviously, for something like Gentoo, putting an SSD-based filesystem
> under /var/tmp makes a lot of sense, but what other uses have been
> tried? How'd they work out?
> 

Ruggedized PC sitting on top of the rotor head of a helicopter, making
videos of the blade movement. Works well, but the SATA connectors tend
to fall off. ;-)

Regards,
Florian Philipp


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-user] SSDs, swap, caching, other unusual uses

[Volker Armin Hemmann]

On Friday 29 July 2011 14:18:41 Michael Mol wrote:
> Something that's been tickling my brain for a couple years now, and
> you guys are probably the right ones to ask.
> 
> I haven't dropped coin for an SSD (yet), but I was wondering about
> uses for them beyond using them for / or /home.
> 
> 1) What about sitting swap (partition, file, whatever) on the SSD?

NO! 

For $DEITY's sake- NO!

ssds can't withstand many writes (yeah, I know, millions blablabla... earlier 
done than you think). Do Not Do This.

SSDs are not meant for such a scenario.

> Presumably, in scenarios where expanding the RAM in a system is
> prohibitively expensive, an SSD could reduce the impact of swap
> thrash.

no, it is increasing the impact of SSD trash.

> 2) While my system rarely goes above using 2-2.5GB of RAM, I enjoy
> having 6-8GB of RAM, just for the file cache. Of course, I lose that
> when I reboot; the cache needs to be repopulated. Has there been any
> work in the kernel for doing things like Vista/Win7's ReadyBoost?
> ReadyBoost has a ridiculous limit to only using 4GB of a flash drive,
> but I'd think that an 80GB SSD would be a massive performance
> improvement.
> 

with a SSD filecache is not that important anymore - and every usb-stick is 
slower than a SSD.

> Obviously, for something like Gentoo, putting an SSD-based filesystem
> under /var/tmp makes a lot of sense, but what other uses have been
> tried? How'd they work out?

no, /var/tmp is very not important from a performance point of view - with the 
exception of /var/tmp/portage - and that is a candidate for tempfs.

-- 
#163933

Re: [gentoo-user] SSDs, swap, caching, other unusual uses

[Michael Mol]

On Sun, Jul 31, 2011 at 10:02 AM, Volker Armin Hemmann
<volkerarmin@googlemail.com> wrote:
> On Friday 29 July 2011 14:18:41 Michael Mol wrote:
>> Something that's been tickling my brain for a couple years now, and
>> you guys are probably the right ones to ask.
>>
>> I haven't dropped coin for an SSD (yet), but I was wondering about
>> uses for them beyond using them for / or /home.
>>
>> 1) What about sitting swap (partition, file, whatever) on the SSD?
>
> NO!
>
> For $DEITY's sake- NO!
>
> ssds can't withstand many writes (yeah, I know, millions blablabla... earlier
> done than you think). Do Not Do This.
>
> SSDs are not meant for such a scenario.

I'm not one to care what a tool was meant for, only what it can be used for.

While I take your point about write-cycle limitations, and I would
*assume* you're familiar with the various improvements on
wear-leveling technique that have happened over the past *ten years*
since those concerns were first raised, I could probably raise an
argument that a fresh SSD is likely to last longer as a swap device
than as a filesystem.

Swap is only touched as-needed, while there's been an explosion in
programs and user software which demands synchronous writes to disk
for data integrity purposes. (Firefox uses sqlite in such a way, for
example; I discovered this when I was using sqlite heavily in my *own*
application, and Firefox hung for a couple minutes during every batch
insert.)

Also, despite the MBTF data provided by the manufacturers, there's
more empirical evidence that the drives expire faster than expected,
anyway. I'm aware of this, and not particularly concerned about it.

>
>> Presumably, in scenarios where expanding the RAM in a system is
>> prohibitively expensive, an SSD could reduce the impact of swap
>> thrash.
>
> no, it is increasing the impact of SSD trash.

False dichotomy. Yes, it increases the wear on the device. That says
nothing of its impact on system performance, which was the nature of
my point.

>
>> 2) While my system rarely goes above using 2-2.5GB of RAM, I enjoy
>> having 6-8GB of RAM, just for the file cache. Of course, I lose that
>> when I reboot; the cache needs to be repopulated. Has there been any
>> work in the kernel for doing things like Vista/Win7's ReadyBoost?
>> ReadyBoost has a ridiculous limit to only using 4GB of a flash drive,
>> but I'd think that an 80GB SSD would be a massive performance
>> improvement.
>>
>
> with a SSD filecache is not that important anymore - and every usb-stick is
> slower than a SSD.

I'll poke the second argument first. I wouldn't use USB for something
like this. USB2 is a painfully slow polling architecture. Something
like this would need to be done with SATA. I'm *not* that daft.

As for a filecache not being that important, that's only the case if
your data of interest exists on the filesystem you put on the SSD.

Let's say you're someone like me, who would tend to go with 60GB for /
and 3TB for /home. At various times, I'll be doing HDR photo
processing, some video transcoding, some random non-portage compile
jobs, web browsing, coding, etc.

If I take a 160GB SSD, I could put / (or, at least, /var/ and /usr),
and have some space left over for scratch--but it's going to be a pain
trying to figure out which of my 3TB of /home data I want in that fast
scratch.

File cache is great, because it takes caches your most-used data from
*anywhere* and keeps it in a fast-access datastore. I could have a 3
*petabyte* volume, not be particularly concerned about data
distribution, and have just as response from the filecache as if I had
a mere 30GB volume. Putting a filesystem on an SSD simply cannot scale
that way.

Actually, this conversation reminds me of another idea I'd had at one
point...putting ext3/ext4's journal on an SSD, while keeping the bulk
of the data on large, dense spinning platters.

>
>> Obviously, for something like Gentoo, putting an SSD-based filesystem
>> under /var/tmp makes a lot of sense, but what other uses have been
>> tried? How'd they work out?
>
> no, /var/tmp is very not important from a performance point of view - with the
> exception of /var/tmp/portage - and that is a candidate for tempfs.

Did you miss the last week's worth of discussion of memory limits on tmpfs?

-- 
:wq

Re: [gentoo-user] SSDs, swap, caching, other unusual uses

[Dale]

Volker Armin Hemmann wrote:
>
> no, /var/tmp is very not important from a performance point of view - with the
> exception of /var/tmp/portage - and that is a candidate for tempfs.
>
>    

Actually I recently tested that theory and it was faster when 
/var/tmp/portage was on a hard drive instead of tmpfs.  I do plan to 
test this again tho.  It doesn't make sense but that was the results.

Dale

:-)  :-)

Re: [gentoo-user] SSDs, swap, caching, other unusual uses

[Volker Armin Hemmann]

Am Sonntag 31 Juli 2011, 10:44:28 schrieb Michael Mol:
> On Sun, Jul 31, 2011 at 10:02 AM, Volker Armin Hemmann
> 
> <volkerarmin@googlemail.com> wrote:
> > On Friday 29 July 2011 14:18:41 Michael Mol wrote:
> >> Something that's been tickling my brain for a couple years now, and
> >> you guys are probably the right ones to ask.
> >> 
> >> I haven't dropped coin for an SSD (yet), but I was wondering about
> >> uses for them beyond using them for / or /home.
> >> 
> >> 1) What about sitting swap (partition, file, whatever) on the SSD?
> > 
> > NO!
> > 
> > For $DEITY's sake- NO!
> > 
> > ssds can't withstand many writes (yeah, I know, millions blablabla...
> > earlier done than you think). Do Not Do This.
> > 
> > SSDs are not meant for such a scenario.
> 
> I'm not one to care what a tool was meant for, only what it can be used for.
> 
> While I take your point about write-cycle limitations, and I would
> *assume* you're familiar with the various improvements on
> wear-leveling technique that have happened over the past *ten years*

yeah, I am. Or let it phrase it differently:
I know what is claimed.

The problem is, the best wear leveling does not help you if your disk is 
pretty filled up and you still do a lot of writing. 1 000 000 write cycles 
aren't much. 

> since those concerns were first raised, I could probably raise an
> argument that a fresh SSD is likely to last longer as a swap device
> than as a filesystem.

depends - because thanks to wear leveling that 'swap partition' is just 
something the firmware makes the kernel believe to be there. 


> 
> Swap is only touched as-needed, while there's been an explosion in
> programs and user software which demands synchronous writes to disk
> for data integrity purposes. (Firefox uses sqlite in such a way, for
> example; I discovered this when I was using sqlite heavily in my *own*
> application, and Firefox hung for a couple minutes during every batch
> insert.)

which is another goof reason not to use firefox - but 
             total       used       free     shared    buffers     cached
Mem:       8182556    7373736     808820          0      56252    2197064
-/+ buffers/cache:    5120420    3062136
Swap:     23446848      82868   23363980

even with lots of ram, you will hit swap. And since you are using the wear-
leveling of the drive's firmware it does not matter that your swap resides on 
its own partition - every page written means a block-rewrite somewhere. Really 
not good for your ssd.

> 
> Also, despite the MBTF data provided by the manufacturers, there's
> more empirical evidence that the drives expire faster than expected,
> anyway. I'm aware of this, and not particularly concerned about it.

well, it is your money to burn.

> 
> >> Presumably, in scenarios where expanding the RAM in a system is
> >> prohibitively expensive, an SSD could reduce the impact of swap
> >> thrash.
> > 
> > no, it is increasing the impact of SSD trash.
> 
> False dichotomy. Yes, it increases the wear on the device. That says
> nothing of its impact on system performance, which was the nature of
> my point.

if you are so concerned of swap performance you should probably go with a 
smaller ssd, get more ram and let that few mb of swap you need been handled by 
several swap partitions.

> 
> >> 2) While my system rarely goes above using 2-2.5GB of RAM, I enjoy
> >> having 6-8GB of RAM, just for the file cache. Of course, I lose that
> >> when I reboot; the cache needs to be repopulated. Has there been any
> >> work in the kernel for doing things like Vista/Win7's ReadyBoost?
> >> ReadyBoost has a ridiculous limit to only using 4GB of a flash drive,
> >> but I'd think that an 80GB SSD would be a massive performance
> >> improvement.
> > 
> > with a SSD filecache is not that important anymore - and every usb-stick
> > is slower than a SSD.
> 
> I'll poke the second argument first. I wouldn't use USB for something
> like this. USB2 is a painfully slow polling architecture. Something
> like this would need to be done with SATA. I'm *not* that daft.
> 
> As for a filecache not being that important, that's only the case if
> your data of interest exists on the filesystem you put on the SSD.
> 
> Let's say you're someone like me, who would tend to go with 60GB for /
> and 3TB for /home. At various times, I'll be doing HDR photo
> processing, some video transcoding, some random non-portage compile
> jobs, web browsing, coding, etc.

60gb for /, 75gb for /var, and 2.5tb data...
my current setup.

> 
> If I take a 160GB SSD, I could put / (or, at least, /var/ and /usr),
> and have some space left over for scratch--but it's going to be a pain
> trying to figure out which of my 3TB of /home data I want in that fast
> scratch.
> 
> File cache is great, because it takes caches your most-used data from
> *anywhere* and keeps it in a fast-access datastore. I could have a 3
> *petabyte* volume, not be particularly concerned about data
> distribution, and have just as response from the filecache as if I had
> a mere 30GB volume. Putting a filesystem on an SSD simply cannot scale
> that way.

true, but all those microseconds saved with swap on ssd won't offset the pain 
when the ssd dies earlier.

> 
> Actually, this conversation reminds me of another idea I'd had at one
> point...putting ext3/ext4's journal on an SSD, while keeping the bulk
> of the data on large, dense spinning platters.

which sounds nice in theory.

> 
> >> Obviously, for something like Gentoo, putting an SSD-based filesystem
> >> under /var/tmp makes a lot of sense, but what other uses have been
> >> tried? How'd they work out?
> > 
> > no, /var/tmp is very not important from a performance point of view -
> > with the exception of /var/tmp/portage - and that is a candidate for
> > tempfs.
> Did you miss the last week's worth of discussion of memory limits on tmpfs?

probably. Because I am using tempfs for /var/tmp/portage for ages and the only 
problematic packet is openoffice/libreoffice.

-- 
#163933

Re: [gentoo-user] SSDs, swap, caching, other unusual uses

[Michael Mol]

On Sun, Jul 31, 2011 at 6:37 PM, Volker Armin Hemmann
<volkerarmin@googlemail.com> wrote:
> Am Sonntag 31 Juli 2011, 10:44:28 schrieb Michael Mol:
>> While I take your point about write-cycle limitations, and I would
>> *assume* you're familiar with the various improvements on
>> wear-leveling technique that have happened over the past *ten years*
>
> yeah, I am. Or let it phrase it differently:
> I know what is claimed.
>
> The problem is, the best wear leveling does not help you if your disk is
> pretty filled up and you still do a lot of writing. 1 000 000 write cycles
> aren't much.

Ok; I wasn't certain, but it sounded like you'd had your head in the
sand (if you'll pardon the expression). It's clear you didn't. I'm
sorry.

>
>> since those concerns were first raised, I could probably raise an
>> argument that a fresh SSD is likely to last longer as a swap device
>> than as a filesystem.
>
> depends - because thanks to wear leveling that 'swap partition' is just
> something the firmware makes the kernel believe to be there.
>
>
>>
>> Swap is only touched as-needed, while there's been an explosion in
>> programs and user software which demands synchronous writes to disk
>> for data integrity purposes. (Firefox uses sqlite in such a way, for
>> example; I discovered this when I was using sqlite heavily in my *own*
>> application, and Firefox hung for a couple minutes during every batch
>> insert.)
>
> which is another goof reason not to use firefox - but
>             total       used       free     shared    buffers     cached
> Mem:       8182556    7373736     808820          0      56252    2197064
> -/+ buffers/cache:    5120420    3062136
> Swap:     23446848      82868   23363980
>
> even with lots of ram, you will hit swap. And since you are using the wear-
> leveling of the drive's firmware it does not matter that your swap resides on
> its own partition - every page written means a block-rewrite somewhere. Really
> not good for your ssd.

Fair enough.

It Would Be Nice(tm) if the SSD's block size and alignment matched
that of the kernel's pagesize. Not certain if it's possible to tune
those settings (reliably) in the kernel.

Also, my stats, from three different systems (they appear to be using
trivial amounts of swap, though my Gentoo box doesn't appear to be
using any)

(Desktop box)
shortcircuit:1@serenity~
Sun Jul 31 07:03 PM
!499 #1 j0 ?0 $ free -m
             total       used       free     shared    buffers     cached
Mem:          5975       3718       2256          0        617       1106
-/+ buffers/cache:       1994       3980
Swap:         9993          0       9993

(laptop)
shortcircuit@saffron:~$ free -m
             total       used       free     shared    buffers     cached
Mem:          1995       1732        263          0        169        913
-/+ buffers/cache:        648       1347
Swap:         3921          3       3918

(server)
shortcircuit@rosettacode.xen.prgmr.com~
23:05:34 $ free -m
             total       used       free     shared    buffers     cached
Mem:          2048       2000         47          0        285        488
-/+ buffers/cache:       1225        822
Swap:          511          1        510

>> Also, despite the MBTF data provided by the manufacturers, there's
>> more empirical evidence that the drives expire faster than expected,
>> anyway. I'm aware of this, and not particularly concerned about it.
>
> well, it is your money to burn.

Best evidence I've read lately is that the drives last about a year
under heavy use. I was going to include a reference in the last email,
but I can't find a link to the post. I thought it was something Joel
Spolsky (or *someone* at StackOverflow) wrote, but I was unable to
find it quickly.

My parts usually last 3-5 years, so that's pretty low. Still, having
my swap partition drop (and the entire system halt) would be generally
less damaging to me than having real data on the drive.

>> False dichotomy. Yes, it increases the wear on the device. That says
>> nothing of its impact on system performance, which was the nature of
>> my point.
>
> if you are so concerned of swap performance you should probably go with a
> smaller ssd, get more ram and let that few mb of swap you need been handled by
> several swap partitions.

This is where I get back to my original, 'prohibitively expensive'
bit. I can get 16GB of RAM into my system for about $200. The use
cases where I've been contemplating this have been where I wanted to
have 60GB to 80GB of data quickly accessible in a random-access
fashion, but where that type of load wasn't what I normally spent my
time doing. (Hence the idea to have a broader improvement from
something such as the file cache)

And, really, the whole point of the thread was for thought
experiments. Posits are occasionally required.

>> As for a filecache not being that important, that's only the case if
>> your data of interest exists on the filesystem you put on the SSD.
>>
>> Let's say you're someone like me, who would tend to go with 60GB for /
>> and 3TB for /home. At various times, I'll be doing HDR photo
>> processing, some video transcoding, some random non-portage compile
>> jobs, web browsing, coding, etc.
>
> 60gb for /, 75gb for /var, and 2.5tb data...
> my current setup.

Handy; we'll have common frames of reference.

>> If I take a 160GB SSD, I could put / (or, at least, /var/ and /usr),
>> and have some space left over for scratch--but it's going to be a pain
>> trying to figure out which of my 3TB of /home data I want in that fast
>> scratch.
>>
>> File cache is great, because it takes caches your most-used data from
>> *anywhere* and keeps it in a fast-access datastore. I could have a 3
>> *petabyte* volume, not be particularly concerned about data
>> distribution, and have just as response from the filecache as if I had
>> a mere 30GB volume. Putting a filesystem on an SSD simply cannot scale
>> that way.
>
> true, but all those microseconds saved with swap on ssd won't offset the pain
> when the ssd dies earlier.

It really depends on the quantity and nature of the pain. When the
things I'm toying around with have projected completion times of a
*week* rather than an hour or two, and when I don't normally need so
much memory, it wouldn't be too much of a hassle to remove the dead
drive from fstab and boot back up. (after fsck, etc, natch). In the
words of the Architect, "There are levels of existence we are prepared
to accept..."

>> Actually, this conversation reminds me of another idea I'd had at one
>> point...putting ext3/ext4's journal on an SSD, while keeping the bulk
>> of the data on large, dense spinning platters.
>
> which sounds nice in theory.

Yet would potentially run afoul of the SSD's write block resolution.
And, of course, having the journal fail out from under me would be a
fair bit worse than the kernel panicking during a swap operation.

>> Did you miss the last week's worth of discussion of memory limits on tmpfs?
>
> probably. Because I am using tempfs for /var/tmp/portage for ages and the only
> problematic packet is openoffice/libreoffice.

I ran into trouble with Thunderbird a couple months ago, which is why
I had to drop from using tmpfs. (Also, I compile with -ggdb in CFLAGS,
so I expect my build sizes bloat a bit more than most)

Anyway, the edge cases and caveats like the ones discussed are why I
ask about what people have tried, and what mitigators, workarounds and
technological improvements people have been working on.

-- 
:wq

Re: [gentoo-user] SSDs, swap, caching, other unusual uses

[Paul Hartman]

On Fri, Jul 29, 2011 at 1:18 PM, Michael Mol <mikemol@gmail.com> wrote:
> Something that's been tickling my brain for a couple years now, and
> you guys are probably the right ones to ask.
>
> I haven't dropped coin for an SSD (yet), but I was wondering about
> uses for them beyond using them for / or /home.
>
> 1) What about sitting swap (partition, file, whatever) on the SSD?
> Presumably, in scenarios where expanding the RAM in a system is
> prohibitively expensive, an SSD could reduce the impact of swap
> thrash.

Swap on flash memory is faster than on disk, but it is still swap and
still sucks. :) There's no reason why it won't work, but I doubt it'll
have as much of a positive impact as you're hoping. In fact depending
on the SSD some don't cope with a storm of tiny simultaneous random
reads and writes and might block even worse than a fast HDD. IMO.

> 2) While my system rarely goes above using 2-2.5GB of RAM, I enjoy
> having 6-8GB of RAM, just for the file cache. Of course, I lose that
> when I reboot; the cache needs to be repopulated. Has there been any
> work in the kernel for doing things like Vista/Win7's ReadyBoost?
> ReadyBoost has a ridiculous limit to only using 4GB of a flash drive,
> but I'd think that an 80GB SSD would be a massive performance
> improvement.

I believe DM-Cache provides this kind of functionality in Linux. I've
never tried it.

You can also buy a hybrid hard drive, it is a traditional HDD with SSD
built-in for caching. That is transparent to the operating system.

Re: [gentoo-user] SSDs, swap, caching, other unusual uses

[Michael Mol]

On Mon, Aug 1, 2011 at 12:29 PM, Paul Hartman
<paul.hartman+gentoo@gmail.com> wrote:
> On Fri, Jul 29, 2011 at 1:18 PM, Michael Mol <mikemol@gmail.com> wrote:
>> Something that's been tickling my brain for a couple years now, and
>> you guys are probably the right ones to ask.
>>
>> I haven't dropped coin for an SSD (yet), but I was wondering about
>> uses for them beyond using them for / or /home.
>>
>> 1) What about sitting swap (partition, file, whatever) on the SSD?
>> Presumably, in scenarios where expanding the RAM in a system is
>> prohibitively expensive, an SSD could reduce the impact of swap
>> thrash.
>
> Swap on flash memory is faster than on disk, but it is still swap and
> still sucks. :) There's no reason why it won't work, but I doubt it'll
> have as much of a positive impact as you're hoping. In fact depending
> on the SSD some don't cope with a storm of tiny simultaneous random
> reads and writes and might block even worse than a fast HDD. IMO.

Yeah, true; the write caching and queuing of some of the lower-end
drives are crap, from what I've heard. The primary reason I haven't
spent on and SSD yet is while I could afford a low-end drive, I can't
afford a smaller-size drive that's a good implementation.

>
>> 2) While my system rarely goes above using 2-2.5GB of RAM, I enjoy
>> having 6-8GB of RAM, just for the file cache. Of course, I lose that
>> when I reboot; the cache needs to be repopulated. Has there been any
>> work in the kernel for doing things like Vista/Win7's ReadyBoost?
>> ReadyBoost has a ridiculous limit to only using 4GB of a flash drive,
>> but I'd think that an 80GB SSD would be a massive performance
>> improvement.
>
> I believe DM-Cache provides this kind of functionality in Linux. I've
> never tried it.

That's *exactly* the kind of thing I was hoping was being worked on. I
hadn't heard anyone was actually *doing* it.

>
> You can also buy a hybrid hard drive, it is a traditional HDD with SSD
> built-in for caching. That is transparent to the operating system.

They've sounded interesting, yes.

-- 
:wq

Re: [gentoo-user] SSDs, swap, caching, other unusual uses

[Volker Armin Hemmann]

Am Sonntag 31 Juli 2011, 19:11:06 schrieb Michael Mol:
> On Sun, Jul 31, 2011 at 6:37 PM, Volker Armin Hemmann
> 
> <volkerarmin@googlemail.com> wrote:
> > Am Sonntag 31 Juli 2011, 10:44:28 schrieb Michael Mol:
> >> While I take your point about write-cycle limitations, and I would
> >> *assume* you're familiar with the various improvements on
> >> wear-leveling technique that have happened over the past *ten years*
> > 
> > yeah, I am. Or let it phrase it differently:
> > I know what is claimed.
> > 
> > The problem is, the best wear leveling does not help you if your disk is
> > pretty filled up and you still do a lot of writing. 1 000 000 write
> > cycles aren't much.
> 
> Ok; I wasn't certain, but it sounded like you'd had your head in the
> sand (if you'll pardon the expression). It's clear you didn't. I'm
> sorry.
> 
> >> since those concerns were first raised, I could probably raise an
> >> argument that a fresh SSD is likely to last longer as a swap device
> >> than as a filesystem.
> > 
> > depends - because thanks to wear leveling that 'swap partition' is just
> > something the firmware makes the kernel believe to be there.
> > 
> >> Swap is only touched as-needed, while there's been an explosion in
> >> programs and user software which demands synchronous writes to disk
> >> for data integrity purposes. (Firefox uses sqlite in such a way, for
> >> example; I discovered this when I was using sqlite heavily in my *own*
> >> application, and Firefox hung for a couple minutes during every batch
> >> insert.)
> > 
> > which is another goof reason not to use firefox - but
> >             total       used       free     shared    buffers     cached
> > Mem:       8182556    7373736     808820          0      56252  
> >  2197064
> > -/+ buffers/cache:    5120420    3062136
> > Swap:     23446848      82868   23363980
> > 
> > even with lots of ram, you will hit swap. And since you are using the
> > wear- leveling of the drive's firmware it does not matter that your
> > swap resides on its own partition - every page written means a
> > block-rewrite somewhere. Really not good for your ssd.
> 
> Fair enough.
> 
> It Would Be Nice(tm) if the SSD's block size and alignment matched
> that of the kernel's pagesize. Not certain if it's possible to tune
> those settings (reliably) in the kernel.
> 
> Also, my stats, from three different systems (they appear to be using
> trivial amounts of swap, though my Gentoo box doesn't appear to be
> using any)
> 
> (Desktop box)
> shortcircuit:1@serenity~
> Sun Jul 31 07:03 PM
> !499 #1 j0 ?0 $ free -m
>              total       used       free     shared    buffers     cached
> Mem:          5975       3718       2256          0        617       1106
> -/+ buffers/cache:       1994       3980
> Swap:         9993          0       9993
> 
> (laptop)
> shortcircuit@saffron:~$ free -m
>              total       used       free     shared    buffers     cached
> Mem:          1995       1732        263          0        169        913
> -/+ buffers/cache:        648       1347
> Swap:         3921          3       3918
> 
> (server)
> shortcircuit@rosettacode.xen.prgmr.com~
> 23:05:34 $ free -m
>              total       used       free     shared    buffers     cached
> Mem:          2048       2000         47          0        285        488
> -/+ buffers/cache:       1225        822
> Swap:          511          1        510
> 
> >> Also, despite the MBTF data provided by the manufacturers, there's
> >> more empirical evidence that the drives expire faster than expected,
> >> anyway. I'm aware of this, and not particularly concerned about it.
> > 
> > well, it is your money to burn.
> 
> Best evidence I've read lately is that the drives last about a year
> under heavy use. I was going to include a reference in the last email,
> but I can't find a link to the post. I thought it was something Joel
> Spolsky (or *someone* at StackOverflow) wrote, but I was unable to
> find it quickly.
> 
> My parts usually last 3-5 years, so that's pretty low. Still, having
> my swap partition drop (and the entire system halt) would be generally
> less damaging to me than having real data on the drive.
> 
> >> False dichotomy. Yes, it increases the wear on the device. That says
> >> nothing of its impact on system performance, which was the nature of
> >> my point.
> > 
> > if you are so concerned of swap performance you should probably go with
> > a
> > smaller ssd, get more ram and let that few mb of swap you need been
> > handled by several swap partitions.
> 
> This is where I get back to my original, 'prohibitively expensive'
> bit. I can get 16GB of RAM into my system for about $200. The use
> cases where I've been contemplating this have been where I wanted to
> have 60GB to 80GB of data quickly accessible in a random-access
> fashion, but where that type of load wasn't what I normally spent my
> time doing. (Hence the idea to have a broader improvement from
> something such as the file cache)
> 
> And, really, the whole point of the thread was for thought
> experiments. Posits are occasionally required.
> 
> >> As for a filecache not being that important, that's only the case if
> >> your data of interest exists on the filesystem you put on the SSD.
> >> 
> >> Let's say you're someone like me, who would tend to go with 60GB for /
> >> and 3TB for /home. At various times, I'll be doing HDR photo
> >> processing, some video transcoding, some random non-portage compile
> >> jobs, web browsing, coding, etc.
> > 
> > 60gb for /, 75gb for /var, and 2.5tb data...
> > my current setup.
> 
> Handy; we'll have common frames of reference.
> 
> >> If I take a 160GB SSD, I could put / (or, at least, /var/ and /usr),
> >> and have some space left over for scratch--but it's going to be a pain
> >> trying to figure out which of my 3TB of /home data I want in that fast
> >> scratch.
> >> 
> >> File cache is great, because it takes caches your most-used data from
> >> *anywhere* and keeps it in a fast-access datastore. I could have a 3
> >> *petabyte* volume, not be particularly concerned about data
> >> distribution, and have just as response from the filecache as if I had
> >> a mere 30GB volume. Putting a filesystem on an SSD simply cannot scale
> >> that way.
> > 
> > true, but all those microseconds saved with swap on ssd won't offset the
> > pain when the ssd dies earlier.
> 
> It really depends on the quantity and nature of the pain. When the
> things I'm toying around with have projected completion times of a
> *week* rather than an hour or two, and when I don't normally need so
> much memory, it wouldn't be too much of a hassle to remove the dead
> drive from fstab and boot back up. (after fsck, etc, natch). In the
> words of the Architect, "There are levels of existence we are prepared
> to accept..."
> 
> >> Actually, this conversation reminds me of another idea I'd had at one
> >> point...putting ext3/ext4's journal on an SSD, while keeping the bulk
> >> of the data on large, dense spinning platters.
> > 
> > which sounds nice in theory.
> 
> Yet would potentially run afoul of the SSD's write block resolution.
> And, of course, having the journal fail out from under me would be a
> fair bit worse than the kernel panicking during a swap operation.
> 
> >> Did you miss the last week's worth of discussion of memory limits on
> >> tmpfs?> 
> > probably. Because I am using tempfs for /var/tmp/portage for ages and
> > the only problematic packet is openoffice/libreoffice.
> 
> I ran into trouble with Thunderbird a couple months ago, which is why
> I had to drop from using tmpfs. (Also, I compile with -ggdb in CFLAGS,
> so I expect my build sizes bloat a bit more than most)
> 
> Anyway, the edge cases and caveats like the ones discussed are why I
> ask about what people have tried, and what mitigators, workarounds and
> technological improvements people have been working on.
-- 
#163933

Re: [gentoo-user] SSDs, swap, caching, other unusual uses

[Volker Armin Hemmann]

Am Sonntag 31 Juli 2011, 19:11:06 schrieb Michael Mol:

> > which is another goof reason not to use firefox - but
> >             total       used       free     shared    buffers     cached
> > Mem:       8182556    7373736     808820          0      56252  
> >  2197064
> > -/+ buffers/cache:    5120420    3062136
> > Swap:     23446848      82868   23363980
> > 
> > even with lots of ram, you will hit swap. And since you are using the
> > wear- leveling of the drive's firmware it does not matter that your
> > swap resides on its own partition - every page written means a
> > block-rewrite somewhere. Really not good for your ssd.
> 
> Fair enough.
> 
> It Would Be Nice(tm) if the SSD's block size and alignment matched
> that of the kernel's pagesize. Not certain if it's possible to tune
> those settings (reliably) in the kernel.
> 

it would be enough if the write/delete blocks were a little bit smaller..

> Yet would potentially run afoul of the SSD's write block resolution.
> And, of course, having the journal fail out from under me would be a
> fair bit worse than the kernel panicking during a swap operation.
> 

SSDs have this nice feature - it is called sudden violent death. Good chance 
that when it fails, all of it fails ;)

I am backing up my ssd once a week. One week is the amount of emails and non-
essential documents I am willing to risk.

> >> Did you miss the last week's worth of discussion of memory limits on
> >> tmpfs?> 
> > probably. Because I am using tempfs for /var/tmp/portage for ages and
> > the only problematic packet is openoffice/libreoffice.
> 
> I ran into trouble with Thunderbird a couple months ago, which is why
> I had to drop from using tmpfs. (Also, I compile with -ggdb in CFLAGS,
> so I expect my build sizes bloat a bit more than most)

uuuh.. yeah.. 'a bit'.. you are a man of understatement.

> 
> Anyway, the edge cases and caveats like the ones discussed are why I
> ask about what people have tried, and what mitigators, workarounds and
> technological improvements people have been working on.

Well, you could always get a couple of 15k rpm u320 drives in a RAID 10 setup 
and use that for swap.

Fucking fast (I have two in a spare box) but the noise is... extrem. 


-- 
#163933

Re: [gentoo-user] SSDs, swap, caching, other unusual uses

[Michael Mol]

On Mon, Aug 1, 2011 at 1:28 PM, Volker Armin Hemmann
<volkerarmin@googlemail.com> wrote:
> Am Sonntag 31 Juli 2011, 19:11:06 schrieb Michael Mol:
>
>> Yet would potentially run afoul of the SSD's write block resolution.
>> And, of course, having the journal fail out from under me would be a
>> fair bit worse than the kernel panicking during a swap operation.
>>
>
> SSDs have this nice feature - it is called sudden violent death. Good chance
> that when it fails, all of it fails ;)

Yeah, which is why I haven't been keen on putting an entire filesystem
on one, and would rather have it as a cache; caches are, by nature,
temporary.

>>
>> I ran into trouble with Thunderbird a couple months ago, which is why
>> I had to drop from using tmpfs. (Also, I compile with -ggdb in CFLAGS,
>> so I expect my build sizes bloat a bit more than most)
>
> uuuh.. yeah.. 'a bit'.. you are a man of understatement.

:)

-- 
:wq

Re: [gentoo-user] SSDs, swap, caching, other unusual uses

[Stroller]

On 1 August 2011, at 17:29, Paul Hartman wrote:
> ...
> You can also buy a hybrid hard drive, it is a traditional HDD with SSD
> built-in for caching. That is transparent to the operating system.

I looked at these earlier this year. They seem a good compromise of price vs performance.

They're faster than a 2.5" SATA hard-drive, they're about 3x the price.

They're about 1/3 "as fast" as an SSD, and about ⅓ the price.

Stroller.