Gå til innhold

TRIM vil gjøre Android-mobilen din raskere


Anbefalte innlegg

Videoannonse
Annonse
It's bogus. There is currently absolutely no reason to

support TRIM' date=' not on SSD's, not on anything else. The whole

feature is totally broken.

 

The fact is, any SSD worth anything should work perfectly

fine without trim, and if you need trim to get it back to

good performance, you should just ditch the SSD entirely.

 

The whole "SSD's need TRIM" support was a bedtime story for

gullible morons. The same morons who also bought the "SSD's

need big IO and natural alignment" story that came out a

couple of years before that.

 

The fact is, SSD's had seriously buggy garbage collection.

TRIM was a workaround for an SSD firmware bug, nothing

less, and most definitely nothing more. Yes, yes, it can

make a difference, but it's not at all the magical fairy

dust that people have claimed it was. The real solution

was always to just fix the performance bugs in the bad GC

that SSD's did.

 

More specifically, TRIM is also incredibly buggy, and slow

on certain drives. So doing TRIM in the OS is dangerous,

and is likely to result in totally unacceptable performance

if it's used on-line (ie when removing files). And you also

raise your risk for hitting those drive-bricking bugs, so

it's doubly dangerous.

 

In fact, even when it's not really slow (and when it's not

buggy), it still makes a normal file deletion much more

expensive, since normally you'd just throw the blocks away

without doing any IO at all. Doing even a fast TRIM is thus

infinitely more expensive.

 

Finally, the whole saga has been further complicated by

historically bad specifications ("does it leave the data

in a known state") and by the fact that certain uses really

need the TRIM area to be really big and really aligned (ie

the whole non-SSD RAID use of TRIM wants it to cover whole

stripes, so you want TRIM commands to be naturally aligned

and megabytes in size).

 

End result: nobody sane enables TRIM by default, and it's

almost inevitably a total marketing point. And in reality,

you'd want it to be an off-line feature, ie something akin

to doing a defrag event, rather than something you do as

part of a normal filesystem operation.

 

Maybe the above will change eventually, but right now

TRIM is totally oversold, and totally pointless. Just don't

even bother with it. Do your SSD comparisons after you've

done lots of random writes, and expect that in real life

the time when an SSD can optimize its GC i when you do nice

large file writes. Not when you TRIM things.

 

And even _if_ TRIM becomes relevant (and I doubt it ever

really will - good GC makes it largely pointless), it just

won't be a huge deal.

 

Repeat after me: if your disk manufacturer talks about

how you need to TRIM the drive, they're cutting some corners

that you do NOT want to be cut. Buy another drive.

 

Linus[/quote']

http://www.realworldtech.com/forum/?threadid=110080&curpostid=110182

  • Liker 1
Lenke til kommentar
It's bogus. There is currently absolutely no reason to support TRIM' date=' not on SSD's, not on anything else. The whole feature is totally broken. The fact is, any SSD worth anything should work perfectly fine without trim, and if you need trim to get it back to good performance, you should just ditch the SSD entirely. The whole "SSD's need TRIM" support was a bedtime story for gullible morons. The same morons who also bought the "SSD's need big IO and natural alignment" story that came out a couple of years before that. The fact is, SSD's had seriously buggy garbage collection. TRIM was a workaround for an SSD firmware bug, nothing less, and most definitely nothing more. Yes, yes, it can make a difference, but it's not at all the magical fairy dust that people have claimed it was. The real solution was always to just fix the performance bugs in the bad GC that SSD's did. More specifically, TRIM is also incredibly buggy, and slow on certain drives. So doing TRIM in the OS is dangerous, and is likely to result in totally unacceptable performance if it's used on-line (ie when removing files). And you also raise your risk for hitting those drive-bricking bugs, so it's doubly dangerous. In fact, even when it's not really slow (and when it's not buggy), it still makes a normal file deletion much more expensive, since normally you'd just throw the blocks away without doing any IO at all. Doing even a fast TRIM is thus infinitely more expensive. Finally, the whole saga has been further complicated by historically bad specifications ("does it leave the data in a known state") and by the fact that certain uses really need the TRIM area to be really big and really aligned (ie the whole non-SSD RAID use of TRIM wants it to cover whole stripes, so you want TRIM commands to be naturally aligned and megabytes in size). End result: nobody sane enables TRIM by default, and it's almost inevitably a total marketing point. And in reality, you'd want it to be an off-line feature, ie something akin to doing a defrag event, rather than something you do as part of a normal filesystem operation. Maybe the above will change eventually, but right now TRIM is totally oversold, and totally pointless. Just don't even bother with it. Do your SSD comparisons after you've done lots of random writes, and expect that in real life the time when an SSD can optimize its GC i when you do nice large file writes. Not when you TRIM things. And even _if_ TRIM becomes relevant (and I doubt it ever really will - good GC makes it largely pointless), it just won't be a huge deal. Repeat after me: if your disk manufacturer talks about how you need to TRIM the drive, they're cutting some corners that you do NOT want to be cut. Buy another drive. Linus[/quote']http://www.realworldtech.com/forum/?threadid=110080&curpostid=110182

 

Kan vel egentlig ikke si mye om det da jeg kun har hatt en SSD, nemmelig 128gb m4.

 

For noen år siden leste jeg mye om folk som fikk veldig trege SSDdisker etter litt bruking. Min SSD som har brukt TRIM i 2 år er like rask nå som den var da selv om den har vaert fyllt opp 100% flere ganger. Har 6gb ledig nå.

 

Hvis det bare er en bra SSD kan jeg ikke utale meg om da jeg kun har hatt en SSD, men jeg angrer i hvertfall ikke at jeg aktiverte TRIM.

Lenke til kommentar

Nå har jeg jo sett ganske mange SSDer som har blitt testet for hvor god GB-collection de har, og hvor mye TRIM påvirker SSDene i visse tester, og er ikke overbevist om at det er ubrukelig.

Nå vet jeg ikke hvordan flash-minnet er på mobiler i sånn måte.

 

VIlle tatt hva Linus sa med litt sunn skepsis, i og med at han ikke akkurat er en nøytral tredjepart. Var vel han som var en av hovedpersonene til å designe Linux kernelen som Unix-familien bruker (inkludert Mac). Hvor TRIM støtten er noe variert. At han skylder alt på andre som produserer firmware/maskinvare er derfor ikke sjokkerende.

 

At det er forskjeller på SSDene hvor mye man trenger TRIM er jo sant, og jeg er ikke i en slik posisjon til at jeg kan si noe om hvor sant han har. Faktum er jo at du går glipp av en god del om du ser helt bort fra TRIM, og på mobiler og slikt så kan du jo i hvert fall ikke velge noe annet minne.

 

Mulig det også har blitt mindre problematisk uten TRIM den siste tiden.

  • Liker 1
Lenke til kommentar
Nå har jeg jo sett ganske mange SSDer som har blitt testet for hvor god GB-collection de har, og hvor mye TRIM påvirker SSDene i visse tester, og er ikke overbevist om at det er ubrukelig.

Ett av hans poenger er at under normal bruk er det ikke behov for TRIM. Det er bare under absurd bruk som noen typer benchmarking at situasjoner hvor forskjeller dukker opp. Disse situasjonene er helt logiske og ungås ved å ikke gjøre absurde diskoperasjoner.

 

Var vel han som var en av hovedpersonene til å designe Linux kernelen som Unix-familien bruker (inkludert Mac).

Tja. Han laget Linux-kernelen, først tilgjengeliggjort i 1991. Han står for sin egen Linux-kernel (det finnes tusenvis av andre kerneler basert på samme kode, men det er bare hans som er "Linux"). UNIX er i dag en spesifikasjon og sertifikasjon på operativsystemoppførsel og Linux er ikke UNIX. BSD er et helt annet operativsystem (og kernel) og OS X (Ikke "Mac", bare OS X) er basert på BSD og er UNIX (sertifisert), men er ikke Linux.

 

Hvor TRIM støtten er noe variert.

Jeg antar at TRIM var implementert etter spesifikasjonen og tilgjengelig for Linux omtrent på dag én og i Linus sin kernel både ett og to og tre år før f.eks Windows, BSD og OS X.

 

At han skylder alt på andre som produserer firmware/maskinvare er derfor ikke sjokkerende.

Det har du helt rett i. Linus liker ikke når maskinvareprodusenter fikser sine feil ved å "ungå" feilen i firmware eller drivere, og pleier å rope ut når det blir gjort.

 

At det er forskjeller på SSDene hvor mye man trenger TRIM er jo sant, og jeg er ikke i en slik posisjon til at jeg kan si noe om hvor sant han har. Faktum er jo at du går glipp av en god del om du ser helt bort fra TRIM, og på mobiler og slikt så kan du jo i hvert fall ikke velge noe annet minne.

Min forståelse er at du går glipp av en teoretisk gevinst ved usmart bruk av filsystemet og firmware som enten ikke i tide får tid til, eller blir blokkert av din bruk til å gjøre GC. Dersom du vet hvordan en SSD ikke bør brukes og ikke bruker den på de måtene skal det ikke være behov for TRIM.

Lenke til kommentar

Tenker bare på at spørsmålet som det sitatet var basert på var:

">Perhaps the most glaring is the lack of TRIM support in

>OS X - in a company where most of their notebooks are

>using SSDs."

http://www.realworld...urpostid=110182

Var vel også noe snakk om at det var svært begrenset med SSDer du kunne ha for å bruke TRIM på dem. Ja, det var i hvert fall det jeg fant når jeg googlet det kjapt.

 

Har aldri hatt problemstillingen før, så det hele er i grunn noe nytt for meg med Unix/OSX og TRIM-støtte. Men om det ikke var begrenset støtte så ser jeg heller ingen grunn for spørsmålet, og følgelig ikke en forklaring på hvorfor det manglet. :hmm:

Endret av Andrull
Lenke til kommentar

-En person påstår at Apple er ekstreme på å gjøre alle mulige softwareoptimaliseringer.

-Neste person sier «Nei, fordi Apple taper masse ytelse ved å ikke implementere TRIM».

-Linus sier «TRIM var en hack for å patche over dårlig firmware i første generasjoner SSD og er ikke nødvendig ved smart bruk av SSD med god firmware».

 

OS X fikk ikke TRIM før i 2011, sikkert siden de mente at det ikke var behov for det. Linux har hatt støtte fra begynnelsen av, men er ikke aktivert som default på noen distroer jeg kjenner til og Linus mener at det ikke er behov for det. Jeg tror ikke at det at Android nå kommer med en Linux-kernel med TRIM vil gi ytelsesøkninger som er nevneverdige med mindre du gjør noe dumt med filsystemet.

 

Beklager også at jeg skriver så sint, jeg har vært på hyttetur på fjellet uten strøm og vann og må tydeligvis re-sosialisere meg. :)

Endret av JohndoeMAKT
Lenke til kommentar

Ok, skjønner, takk. :)

 

Hehe, det går bra.

 

Men sist og ikke minst, Linus snakker jo om TRIM som noe direkte negativt i sånn måte, så tror du det vil påvirke noen negativt? Altså, jeg er for mindre problemer uansett hva man gjør med filsystemet på mobilen sin, så fremt det ikke har noen negative sider i praksis. At det tar opp litt prosesstid når du ikke bruker telefonen og da er fulladet/koblet til strøm er sånnsett ikke noe problematisk for min del.

Endret av Andrull
Lenke til kommentar

I nye Android 4.3 Jelly Bean har det ifølge Engadget kommet støtte for såkalt TRIM – en defragmenteringsløsning som vil forhindre at Android-mobilen din blir treg over tid.

Her bommer dere både på det tekniske og på journalistikken. TRIM har ingen verdens ting med defragmentering å gjøre (defragmentering er forøvrig noe som sliter raskt ut flashminne). TRIM er at operativsystemet forteller flashkontrolleren hvilken blokker som skal slettes, og så vil kontrolleren (om den er smart) bruke ressurser på å frigjøre cellene når den har ledig kapasitet. (Hvis kontrolleren gjør det på dumme tidspunkt blir ting tregere!) Jeg lurer også på hvorfor dere refererer til en kilde som ikke omhandler innholdet dere beskriver.

 

I defragmenteringsprosessen sørger TRIM for å frigjøre ubrukt lagringsplass.

Hvor tar dere dette fra? (kildene sier ikke det)

 

TRIM vil gjøre Android-mobilen din raskere
Allerede i overskriften bommer dere kraftig, TRIM gjør ingenting raskere, det handler derimot om å opprettholde ytelse (det er stor forskjell).

 

 

Ett av hans poenger er at under normal bruk er det ikke behov for TRIM. Det er bare under absurd bruk som noen typer benchmarking at situasjoner hvor forskjeller dukker opp. Disse situasjonene er helt logiske og ungås ved å ikke gjøre absurde diskoperasjoner.

Jeg husker at Torvalds uttalte seg mens Flash-SSDer til konsumenter og TRIM var relativt ferskt, og ingen av delene fungerte i nærheten av optimalt, det er kanskje dette sitatet du postet? Men det er alltid to ting vi må huske på med Torvalds, for det første er han ekstremt polarisert nesten samme hva han snakker om, og det andre er at han overdriver ekstremt (trolig med vilje) for å legge press på noe han mener ikke er helt ideelt (f.eks. hans klaging mot Nvidia som ikke var berettiget).

 

Det spørs hva som legges i normal bruk, men under visse forutsetninger vil TRIM være en stor fordel, men la meg påpeke et par faktum.

- Dårlig fungerende TRIM kan være langt verre enn ingen TRIM

- Gevinsten av TRIM er avhengig av mengden skriveoperasjoner til enheten, men kan maskeres av to ting:

1) Cache i RAM

2) Eventuell cache i enhet.

Så hvis noen kun skriver små mengder til enheten over tid så vil forskjellen være neglisjerbar.

- Det er først ved skriving av store datamengder at forsinkelser på SSDer kan merkes. Noen ekstrem benchmarking er ikke nødvendig før dette inntreffer, mange spillere som stadig skriver mange GB til SSDen sin vil nok kunne merke gevinster.

 

Men artikkelen handler om telefoner, og jeg ser ikke det store behovet akkurat der.

Endret av efikkan
  • Liker 3
Lenke til kommentar

Behovet er åpenbart.

 

Litt teori først: Når enheten skal skrive til flash-minne (det være seg en SSD-disk i en PC eller flashminne i en telefon) så sendes dataene til kontrolleren som finner et ledig sted i minnet og sender en kommando for å skrive dataene. So far, so good.

Problemet oppstår når all lagringsplass er brukt. Der man på magnetiske lagringsmedier kunne skrive rett over eksisterende data må flashminne først slette det som ligger på den aktuelle plassen før nye data kan legges inn. Når man dermed må slette før man kan skrive så sier det seg selv at prosessen tar lengre tid, og enheten oppleves som tregere. En god kontroller tar seg av dette ved å (når den har lite å gjøre) slette områder i minnet som ikke lenger holder gyldige data slik at neste skriveprosess kan skje direkte, og uten noen slette-operasjoner først. Kontrollere uten gode rutiner for søppelhåndtering trenger TRIM. TRIM har en annen fordel, det opererer på OS-nivå og kan derfor ha mye bedre innsikt enn disk-kontrolleren i hva som skjer med enheten, og dermed kan planlegge bedre når søppelhåndtering bør skje for å ikke gjøre vondt verre og starte operasjoner mens brukeren er aktiv. En mobil lades jevnlig og det virker som Google har valgt gode kriterier for når TRIM burde skje.

 

Og vedr. defrag:

Det er litt annerledes fra defragmentering, som går ut på å flytte data til andre steder på et magnetisk lagringsmedie, slik at data kan skrives sekvensielt i store sammenhengede områder, og leses på samme måte. Problemet med magnetiske lagrinsmedier er at å flytte hodene til andre fysiske steder på disken tar lang tid, så om en fil ikke ligger "i rekkefølge" på platene, men "all over the place", så krever det masse flytting av hodene = treg responstid. Om ordet "defragmentering" er dekkende for både optimalisering for magnetiske medier og rydding i flashminne får bli en jobb for norsk språkråd å avgjøre.

 

 

Uansett, fenomenet har jeg selv opplevd på en tidlige SSD-enheter, og også på nyere mobiler/tablets, som Nexus 7. Jeg har en som brukes i stua som fjernkontroll (iRule) og dama fikk en identisk tablet for å bruke i sofaen og til å ta bestillinger på jobb. Den nye er merkbart raskere enn den gamle. Så at behovet for "søppelrydding" er tilstede på Android-enheter er åpenbart, uansett hva Linus Torvalds måtte mene... Om os-X ;)

Når jeg er tilbake fra ferie skal jeg oppdatere den trege tableten til 4.3, vente noen dager og se om den har blitt på nivå med den "nye" tableten.

 

Og enda viktigere, i motsetning til Linus så har Google ekstremt mye erfaring med Android og en overveldende stor variasjon i enheter, hardware og software, så om de mener fstrim er et nyttig tilskudd til operativsystemet så tror jeg dem på det.

  • Liker 1
Lenke til kommentar

Heisann!

 

Ryddet litt i artikkelen for å få den mer presis. "Defragmentering"-sammenlikningen handler om at GC/TRIM er det nærmeste en SSD/Flash-lagring kommer spinnedisker i form av vedlikeholdsbehov. Ikke at det er nøyaktig det samme som foregår. Begge deler handler om å rydde, men det som er ryddig for en spinnedisk er skadelig for/kan slite ut en SSD. Det burde nå være tydelig i artikkelen hva slags rydding det er snakk om.

 

Akkurat hvor stor effekt TRIM har på SSD-effektivitet er nok et spørsmål bedre rettet mot våre kolleger i Hardware.no, som følger SSD-/kontrollermarkedet langt tettere enn vi gjør.

 

Jeg registrerer imidlertid at artikkelen fra Torvalds er to år gammel, mens Anandtech, et av de mest anerkjente nettstedene for testing og informasjon om maskinvare, fortsatt omtaler det som et viktig tilskudd til Android-plattformen. Det er også en kjensgjerning at svært mange klager over nedadgående ytelse over tid på (enkelte) Android-enheter.

Endret av fjarle
  • Liker 3
Lenke til kommentar
Men sist og ikke minst, Linus snakker jo om TRIM som noe direkte negativt i sånn måte, så tror du det vil påvirke noen negativt?

Det negative er som Linus skriver at standarden ikke er spesifikk nok som gjør at ved problemer/stopp kan dataene ende opp i en ukjent tilstand, men ved kjøring én gang i døgnet er nok sjansen for at det skal skje ekstremt lav. Jeg ser ingen problem med å kjøre en slik en gang i blant på lik linje med chkdsk og andre verktøy rett og slett bare for å verifisere og holde systemet i kjent og god tilstand. Men jeg har liten tro på at det medfører merkbar ytelsesforskjell med mindre du har ganske spesiell diskbruk. (Stadig skriving og sletting av en signifikant prosent av disken når stor prosentdel av disken er i bruk) For et par år siden var det vel omtrent 50-60% diskbruk en grei anbefaling med god margin å holde deg under med SSD. Bruker du mindre enn det vil disken ha optimal ytelse og levetid.

Lenke til kommentar

@JohndoeMAKT Det er vel kanskje det med %-vis utnyttelse av disken som gjør at dette kan ha noe for seg på enheter med så lite tilgjengelig plass som mobile enheter har. Nexus 7 med bare 8GB minne var vel kjent får å gå i sirup når den begynte å fylles opp, og det var heller ikke lenge etter at den var lansert.

Lenke til kommentar

Min mobil har vel kjørt med noen få MB ledig i kanskje et års tid nå... XD

Rett og slett pga at det er alt for lite med 16 GB, tross hyppig sletting. (kamera og spotify offline list tar vel opp det meste)

 

På PC så er jeg derimot langt flinkere, rett og slett fordi jeg bryr meg mer, men også fordi filsystemet på en PC er uendelig mye bedre og raskere å slette ting. Trim på mobil kan nok da ha litt for seg ja. :)

Lenke til kommentar

Min mobil har vel kjørt med noen få MB ledig i kanskje et års tid nå... XDRett og slett pga at det er alt for lite med 16 GB, tross hyppig sletting. (kamera og spotify offline list tar vel opp det meste)På PC så er jeg derimot langt flinkere, rett og slett fordi jeg bryr meg mer, men også fordi filsystemet på en PC er uendelig mye bedre og raskere å slette ting. Trim på mobil kan nok da ha litt for seg ja. :)

 

Jeg hadde likt å hatt en android suite for pc, hvor du kan koble opp devicen din og slette og styre derfra. Finnes det noe i den duren?

 

Kan jo selvfølgelig åpne den som en lagringsenhet og slette det jeg vil slette, men tenker da mer på et slags program som finner rester av slettede filer, fjerner fra minnet og optimaliserer programvaren uten at jeg plutselig sletter essensielle filer for systemet.

Lenke til kommentar
×
×
  • Opprett ny...