struggle4progress
(1000+ posts)
Send PM |
Profile |
Ignore
|
Mon Aug-02-10 05:06 AM
Original message |
Anybody here tried getting trim control working in Lucid? |
|
I don't really want to try an SSD with ubuntu 10.04 unless I've got a shot at getting trim control, but right now it looks like I have to upgrade to a later kernel and jump through some additional hoops
|
struggle4progress
(1000+ posts)
Send PM |
Profile |
Ignore
|
Mon Aug-02-10 09:24 PM
Response to Original message |
1. Kernel upgrade is pretty easy: to get 33, for example, download |
|
Edited on Mon Aug-02-10 09:29 PM by struggle4progress
the various.all.deb files + (various.amd64.deb for 64 bit)|(various.i386.deb for 32 bit) files (into some folder) from http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.33.3-lucid/open terminal, cd to that folder, run sudo dpkg -i *.deb, and restart <edit:> if you aren't sure whether you're ubuntu is 32 or 64 bit, run uname -a in terminal
|
struggle4progress
(1000+ posts)
Send PM |
Profile |
Ignore
|
Mon Aug-02-10 10:32 PM
Response to Original message |
2. Next I should figure out erase block size and alignment |
struggle4progress
(1000+ posts)
Send PM |
Profile |
Ignore
|
Mon Aug-02-10 11:07 PM
Response to Reply #2 |
3. Link to online alignment calculator |
struggle4progress
(1000+ posts)
Send PM |
Profile |
Ignore
|
Tue Aug-03-10 09:29 PM
Response to Reply #2 |
4. Stinkin drive manufacturer hasn't responded to my inquiry about page and erase block sizes |
Syrinx
(1000+ posts)
Send PM |
Profile |
Ignore
|
Wed Aug-04-10 04:39 AM
Response to Original message |
5. I have no help to offer |
|
But I will thank you for bringing up topics I've never heard of before. DU can be a real education. :)
Honestly, I had never heard the term "trim control," and I used to think I was pretty sophisticated. :rofl:
|
struggle4progress
(1000+ posts)
Send PM |
Profile |
Ignore
|
Wed Aug-04-10 09:48 PM
Response to Reply #5 |
6. Actually, "trim control" is an aeronautical term, and the proper term for the SSDs is probably |
|
simply TRIM, but quite a number of people say trim control
Here are the issues, as I understand them:
SSDs read and write different size blocks, and the write is actually a big block zero-out-then-overwrite-ones. So writes are are slower than reads. And writes on zeroed blocks are faster than writes over non-zeroed blocks
So first of all, I want an OS that's capable of garbage collection, so it knows when big blocks have been zeroed: that way, the write time won't degrade as I use the disk. That's the reason for switching to the later linux kernel
Next, the read pages should stack neatly into the erase blocks: if they don't fit neatly, erasing a page might require erasing and rewriting TWO erase blocks, instead of one. That's why I need the page and block sizes from the manufacturer -- so I can set up the alignment correctly
There's a third issue, called wear-leveling that I haven't gotten to yet: flash memory degrades with rewrite cycles, so ideally the activity should be distributed over the SSD to avoid degradation with time. I have a cheap substitute for this: I'm going to try to use the SSD for fairly stable system files with the more active directories onto standard hard drives: that way, I hope to get a fast boot and fast application launching, though no speed-up in ordinary work-related reads and writes, but only slow degradation of the SSD
|
DU
AdBot (1000+ posts) |
Wed Jul 23rd 2025, 03:25 AM
Response to Original message |