On Sun, Jul 31, 2011 at 6:37 PM, Volker Armin Hemmann
<volkerar...@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)
shortcirc...@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
