|
Rationale
Solid State Drives (SSD) are becoming more popular and less expensive all the time. Many people are using SSD drives either exclusively or in conjunction with hard drives.
Solid State Drives, unlike RAM or hard drives, do not have unlimited write cycles. That is, with repeated "disk" writes to the SSD (on the order of 100,000), the memory bits can wear out and fail to store data properly.
Therefore, it would be very useful if Ubuntu had an INSTALLATION OPTION that could setup a "Boot to ram" configuration (where the SSD is copied to system ram, then run from ram)
-OR-
The installation option could place heavily written but expendable directories into TMPFS or RAMDISK.
Also, internal system parameters such as the elevator, sync and cache flushing back to the SSD would need to be configured for optimal SSD use.
The goal, of course, being to minimize or eliminate write cycles to the Solid State Drive and maximize it's working life.
=== end ===
|
|
68
votes
|
|
76
0
8
|
|
|
|
|
Propose your solution
Attachments
No attachments.
Duplicates
Comments
|
Auzy
wrote on the 15 Sep 08 at 14:16
|
|
|
Intel have just released new ones recently that they reckon will last even longer. The reality is, harddisk MTBF's are optimistic too.
I'd need better stats to see how useful this really is..
|
|
dino
wrote on the 15 Sep 08 at 15:44
|
|
|
"Normal" harddisks dont have unlimited write cycles and SSD are improving all the time. So... I dont think this is in the long run important.
More important is that most filesystems (and programs often too) are optimized to avoid seeks since they are extrem slow on harddisks but not so on SSDs! A lot Optmization can happen there.
|
|
Auzy
wrote on the 16 Sep 08 at 04:47
|
|
|
Actually, i just found proof this idea is now mostly obsolete, so -1 (and this is early SSD days still).
Intels new SSD's support writing 100GB PER DAY for 5years without failing http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3403&p=4.
So it doesn't matter how you swing the RAM, its unlikely you will save enough cycles to make it last any longer then 2 or 3 weeks (1GB of non-saved temporary data per day should be considered overly excessive, and even that will make barely any difference). For most users, I'd be surprised if they write even 2GB of data out to their harddisk every day (unless they are doing a lot of swapping), so if this is the case, the harddisks will last ages anyway.
Any form of seeking will slow down any harddisk (even random access), because pointers are needed to point to the other data. So the same optimisations will still apply. Sure seeking will be less significant, but I cant really imagine any cases where there could be a speedup.
Storing temp files in ram will speed things up anyway, irrespective of this idea, and I feel should be posted in another idea (because its generic).
So the main core of this idea is fixed simply by using NCQ and a newer intel SSD now. The stats and basic computer science shows show that nothing really needs to be done for SSD now. Those of us who make a large amount of write operations, such as database servers, also will want all operations to be atomic, so nothing is lost in a power outage.
Unless someone proves me wrong, -1. But the idea was good in theory.
|
|
|
Can you really measure this in GB/day? Isn't is so that you can only change a given bit of data on a SSD a limited number of times?
Then it's a problem if a certain file is changed very often, even though you don't write so many GB/day.
|
|
|
According to the File Hierarchy Standard, which Ubuntu mostly follows, large parts of the filesystem, in particular the whole /usr directory, does not change and can even be mounted read-only.
So there is no need to copy the whole filesystem to RAM, that would be wasteful. Actually, you do not need any copying at all upfront, you can get copy-on-write semantics by using unionfs (some LiveCDs uses that).
Here is another way to do it:
http://www.staldal.nu/tech/2008/07/26/linux-with-mounted-read-only/
|
|
Auzy
wrote on the 16 Sep 08 at 13:13
|
|
|
The SSD's apparently apply load-wearing algorithms to help this. However, re-reading it, there could be a software component to do this (even though the articles don't say, how else could you set the reserved spaces?)
And I guess the hdd internally could track the writes to different segments of the drive, and move ones that are a bit common around to wear the drive equally (but I'm not an engineer).
But either way, the sync rates and such I don't know if they would help. If you are constantly writing to the same bits on the drive over and over again, its most likely a database, and database operations should be mostly atomic most times to prevent data corruption. So you wouldn't want to stick it into ram regardless.
|
|
Auzy
wrote on the 16 Sep 08 at 13:13
|
|
|
|
Sorry, mean wear-levelling
|
|
grizzly
wrote on the 28 Oct 08 at 22:32
|
|
|
I like to comment on mikaelstaldal:
>So there is no need to copy the whole filesystem to RAM,
>that would be wasteful.
>Actually, you do not need any copying at all upfront,
>you can get copy-on-write semantics by using unionfs (some LiveCDs uses that).
A year ago, I was experimenting with an asus w-lan router with relatively strong processor and usb-port to expand flash as desired and openwrt/kamikaze... The idea was perfect create an image and write to new parts of the flash "copy-on-write". I also have some bootable versions on various sd-cards and usb-sticks of "puppy linux" for rescue purposes.
I also pretty much like the idea of "nilfs".
My ideal ubuntu (or other distro, but ubuntu in its flavors is very beautiful - if there were not all the basic bugs always...) would maybe be hybrid, such that it would boot a core image (e.g. kernel + wdm + core tools) into RAM, start filling the unused RAM in the background anticipatingly with often-used data and progs (e.g. Firefox, Mail client, office etc.) (heuristics and/or customisation involved) (for example, start pre-caching user dir of last-logged on user to speed up initial log on (similar to a raid1-solution, where one half is a write-mostly persistent memory, the other half a ramdisk), run less-often used stuff directly in some kind of flash (e.g. GoogleEarth)
and leave the rest (e.g. recorded tv streams, music etc. on cheap large conventional disks.).
I think it is possible to construct such a system "by hand" but the risk of 3 months configuring and one single update spoiling all is high. it would be better if such design were easier to give at installation (not only on alternate but on liveCD also).
Sadly, I did not find how subversion's fsfs works, but as far as i can see (my repo is on SD-Card for now) every revision is just a new file in the "revs" directory, so my repo fills up the sd-card continously, exactly what we want to wear level (if now it would be a ring-buffer fsfs it would be perfect - once the card is full, the old revisions would be bumped, similar to the forward-merge of vbox's incremental virtual disks)
One problem remains: can I do without encryption? if somebody gets hold of such versioned things, he can get to know much more about a person than when he just gets a snapshot of several file a person was working on...
|
Post your comment
|
