143    7    1  

SMÅ minnekort

 3,595     0
Jeg har en håndholdt digital lydopptaker (Zoom H4n) med ganske brukbar lydkvalitet. Problemet er at den tar "en evighet" på å komme i gang når jeg slår den på. Jeg mistenker at den leser grundig gjennom hele det 32 GB store minnekortet under oppstart. Det tar lang tid selv når kortet er tilnærmet tomt, så det kan nesten virke som om den sjekker også ubrukte områder, at de er fri for feil.

Jeg er slett ikke sikker på at det store minnekortet er skyld i den trege oppstarten; det er bare en mistanke. Men jeg skulle gjerne teste med et lite kort (helst ikke over 1 GByte) for å se om det hjelper.

Problemet er: Hvor får jeg tak i så små minnekort i dag? (1 GByte tilvarer jo bare 4000 ganger av mine første floppyer Smile)

1 GByte holder jo ganske lenge for lydopptak, så hvis oppstart blir raskere kunne jeg godt tenke meg å anskaffe en bunke 1 GByte-kort til praktisk bruk. Hvis noen vet om et gammelt overskuddslager: Gi meg et hint!

   #2
 5,111     Sørnorge     0
Minnekort bør jevnlig formateres av enheten som skal bruke det. Noen får problemer ved at de gjør opptak, sletter, gjør flere opptak, osv. Det gjør ledig plass på kortet er veldig oppstykket. Dermed må nye filer må deles i små deler og fordeles rundt om. Når dette gjentar seg mange ganger får enheter problemer med å holde oversikt over alle delene. Man sier da at disken er fragmentert. Men KAN gjøre defragmentering, men en mye tryggere måte er å ta kopi av alt man vil ha på minnekortet, formatere det i enheten som skal benytte kortet (sletter alt innhold), og starte blankt.
  (trådstarter)
   #3
 3,595     0
Et flash-basert medium er ganske uavhengig av den fysiske nærheten til ulike blokker på mediet. FAT-baserte filsystemer,vanlige på minnekort, har direkte pekere til hver allokerings-enhet (som er av en fast størrelse, som regel gitt av minnekortets størrelse). Da er antall enheter gitt, og det spiller ingen rolle for aksesstiden hvor de ligger i flash-minnet. Så lenge det er en peker direkte til hver enhet - og det er det! - spiller det, for denne fila, ingen rolle hvor mange andre allokerings-enheter som finnes på mediet. Om det skal allokeres en ny blokk kan lengden av friblokk-lenka ha en (minimal) betydning, men det er kun for den operasjonen.

Skal du kopiere til minnekortet filer som er større enn 4GByte (som ofte er tilfelle for BlueRay-filmer - standarden for DVD-disker tilsa at en videofil måtte oppdeles i fragmenter på maks 1 GByte hver; det gjelder ikke BD) må du formattere minnepinnen med NTFS filsystem istedetfor FAT. (Det finnes også linux-alternativer men de er begrenset til linux-maskiner.) Under NTFS kan en x GByte file legges ut som ett eneste stykke på disken, nærmest uansett hvor stort det er, med ett eneste innslag i katalogen ("Master File Directory") - ikke pekere til en masse småbiter.

Har du gjort masse sletting og nyskriving på en nesten full NTFS disk/minnepinne kan det hende at når f.eks. en 28 GByte fil (størrelse valgt fra den pågående kopi-operasjonen som enda ikke er fullført...) skal kopieres ut må det fordeles på to eller flere "extents" - det blir ikke funnet noe enkelt, ledig 28 GByte-område. Så kanskje fila fordeles på to ulike disk-områder. Eller tre, eller fire. Det er likevel ganske ubetydelig å fordele 28 GByte på fire extents, sammenlignet med å fordele dem på 7 millioner 4 KiByte FAT-blokker ... (og det ville heller ikke vært mulig).

Dengang defragmentering var vesentlig, med FAT filsystemer på roterende magnet-disker, var det viktig å få lagt disk-blokkene etter hverandre ... men ikke direkte etter hverandre: Før den neste blokka i fila ble levert fra disken måtte disk-kontrolleren ha fått tid til å fordøye den forrige. Så "logiske" blokker ble lagt annenhver (eller tredjehver, om kontrolleren var treg) langs sporet - betegnet som "interleaving-faktor". På den første disk-rotasjonene ble de odde-nummererte blokkene lest, på den neste rotasjonen ble de jamn-nummererte blokkene lest, og på den måten fikk man med seg alle blokkene på bare to rotasjoner.

Det er mange år siden kontrollerne ble raske nok til å klare å lese samtlige blokker på én eneste rotasjon. Dessuten: Det er mange år siden kontrollerne ble ustyrt med diverse megabytes bufferlager der de henter opp påfølgende blokker som enda ikke er etterspurt, men som de gjetter på at vil bli etterspurt.

Effekten av alt dette er at dersom du vil gi en praktisk demonstrasjon av gevinsten av defragmentering, må du jobbe ganske ekstremt hardt for å ende opp med en disk som er så defragmentert at du med nøytrale, automatiske måleinstrumenter kan vise: Se her, denne bruker-operasjonen tar lang tid. Nå vil vi defragmentere disken... Se nå: Nå tar det bare lang tid!

Det skal mye til for å gjøre en slik demonstrasjon overbevisende. I dag er defragmentering kun viktig for de (svrært få) spesielt intersserte i hvordan ting ligger på disken. Det betyr null og niks ytelsesmessig.

Et konkret eksempel: Min lydopptaker med et 32 GByte minnekort bootet på ett minutt og tjue sekunder. Minnekortet hadde drøyt tusen file. Jeg reformatterte kortet - ikke hurtigformattering, men så grundig som Window tilbyr. Så lot jeg lydopptakeren få høynivå-formattere kortet (få opprette de kataloger den vil ha, og såtnt), før jeg sjekket oppstarttiden fra strømpåslag. Tiden var redusert fra ett minutt og tjue sekunder til ett minutt og atten sekunder. Dette er målt med "manuell" stoppeklokke, så det kan være en viss målefeil, men alt tyder på at formattering, antall filer etc. har en neglisjerbar betydning.
TSt
   #4
 15,073     0
En kan ha enheter som krever "små" minne kort. Jeg har enda et par små liggende i kontor skuffen etter at jeg kjøpte 10 små for noen år siden til 10-15 år gammelt utstyr. Klarte å finne noen som solgte nye på ebay e.l.
  (trådstarter)
   #5
 3,595     0
"I prinsipp" var FAT designet for å handtere ganske store disker, om man ser på dataformatet på disken. Men programvaren sa gjerne at "Ooops... allokerings-enheteter på 64 Kbytes - det er jeg ikke forberedt på!"

FAT programkoden har vært gjennom flere versjoner en selve FAT-formatet, som format bektrakten. Den første barriæren var disker større enn 32 Mbyte - Unix-tradisjonen sier at diskblokker "skal" være på 512 byte. Siden FAT16 kun tillater 64 Ki blokker, ble det ikke mer en 32 MByte ut av det. Større disker måtte deles opp i flere 32 Mbyte partisjoner.

Det var ingenting i FAT16 per se som begrenset blokkstørrelsen til 512 byte. Så snart programvaren ble oppdatert til å akseptere større blokke, kunne disk/patrisjons-størrelsen øke De gikk stegvis; nyere DOS-versjoner kunne handere større disker. Opp til en viss størrelse.

En del enhete handterte 16384 blokker, slik det var i FAT, men bare av de minste størrelsene. Det var rimelig den gang - hvem ville ha bruk for en disk på flere gigabytes?? Det ville vel ikke kostet utviklere mye å være forberedt på større blokker ... men ingen har (anno 1995) etterspurt det, så hvorfor skulle vi designe med det?

Min første sjef i arbeidslivet hadde et sandard hjertesukk: "Such is life, and it is getting sucher and sucher!" Jeg gjør meg ofte tilsvarende tanker, ikke minst i forhold til hvordan vi sikrer oss i dag mot det ene og det andre.
  (trådstarter)
   #6
 3,595     1
Konklusjon: Mistanken var riktig. Med et 32 GByte kort bruker opptakeren 80 sekunder på oppstart. Med et 256 MByte kort går det på 11,5 sekunder.

32G-kortet er Class 4, 15 Mbyte/s. 256M-kortet er ikke merket med Class, men jeg mistenker at det er så utgammelt at det er fra før Class-merkingen var definert. Det er ihvertfall ikke raskere enn det nye kortet; det er garantert langsommere.

Han jeg fikk låne 256M-kortet av vil få tilbud om å få tilbake et 32G-kort istedetfor å få sitt gamle tilbake. Da får vi begge glede av det. (Ihvertfall hvis det gamle kameraet hans kan handtere 32G-kort.)