Bocs, a hét végén más elfoglaltságom volt, de folytatnám a "TIT"-et, mert úgy látom még mindig rengeteg a félreértés...
1: a defrag során nem tünik/nem tűnhet el semmilyen értékes adat, azaz egyetlen sértetlen és egész fájl sem. Ettől még a defrag eljárás során, az első lépésben, amikor a chkdsk fut és végzi a "szemétgyüjtést" felszabadíthat egy csomó helyet, ahol a rosszul sikeredett (félig létrejött, ám lezáratlan, vagy nem teljesen törölt) fájlok maradékai laknak. Miután ezektől is megszabadult a diszk, valóban "gyorsulhat" a boot, de nem azért, mert rendezettek a fájlok, hanem azért, mert nem kell neki felesleges, hiányos adatokat turkálni, ellenőrizni...
2:
Valaki felvetette, hogy a rendszerszinten nézzük a kártyát, akkor lehetnek plusz órajelciklusok a rendezetlen állapotban, mert többet kell olvasni. Nos ez tévedés.
Igaz, a Wiki nem teljesen releváns, mert sok marhaság is megjelenik benne, de itt egy idézet:
"
Defragmentation tools are used on hard disks to optimize the file system access speed. On an SD card, this is unnecessary, as any block can be accessed as fast as any other. Doing this will wear the card out slightly, as a limited number of writes can be made before failure."
A forrása:
http://en.wikipedia.org/wiki/Secure_Digital_card
Nézzük a részleteket...
A RAM jellegű memóriák (bármilyenek) általában "táblázatos" formában léteznek. Nem bitenként, hanem bizonyos méretű "szavanként" rendeződnek. A tipikus, PC-ben használatos RAM.ok a processzorhoz igazodva 8-16-32-64-128 bites szerveződésűek. Spéci nagysebességű videokártyákban már van 512 bites szervezés is. Úgy kell felfogni, mint egy excel táblát, aminek az oszlopszáma annyi, amennyi a biteké, a sorok száma meg annyi, ahányra szükség van a teljes kapacitás eléréséhez.
Pl egy 1 MB, 16 bites RAM az 16 oszlop, 512 sor. Egy bit eléréshez először megcímezzük a megfelelő sort (RAS ciklus). Amikor ez megvan, a teljes sor tartalma átmásolódik egyetlen órajel alatt az "olvasási pufferbe", ami pont akkora, mint egy sor a RAM-ban, és az oszlop címzési ciklusban (CAS) kiválasztjuk a minket érdeklő bitet. A PC-kben párhuzamosan olvas be a proci vagy a DMA egy komplett sort, így gyakorlatilag minden bitet rátol a neki megfelelő adatbusz sinre... Ez a leegyszerűsített vázlat...
Nézzünk egy SD kártyát. A 8 GB-s SD kártya csak FAT32 módban tud dolgozni (ez egyéb flash jellegű RAM-ok másra is képesek, mert más a szervezésük, ott 512 byte-os a blokk, vagy még kisebb, de cserébe a kapaciás is kisebb. Általában.), nem véletlenül. Ahhoz, hogy ekkora tárkapacitása legyen és megfelelő tempóban dolgozzon, a belső szervezése 4 kb-os, azaz 16375 bites sorokból áll. Amikor az oprendszer fájlrendszer kezelője elkér egy clustert a kártyától, az egy ekkora blokkot tud kiadni magából. Teszi ezt "soros" módon, mert általában 1 db adatsin van. Ha USB olvasóval használjuk, nem is kell több, amikor benne van a telefonban, akkor 4-et használ párhuzamosan, azaz 4 bitenként jön ki az adat a kártyából.
A FAT32 legkisebb, egyben kezelt blokkja a cluster, jelen esetben 4 kB. Ez annyit jelent, hogy ha egy fájl 1 byte-os, akkor is 4 kB-nyi helyet foglal. A maradék 4kb-1byte méretű terület tartalma lényegtelen, de az is be kell olvasnia a rendszernek, mert ilyen a szervezése. Ha Novell szerver lenne, akkor képes volna a clusterekben fennmaradt üres helyet is kihasználni, némi teljesítménycsökkenés árán, de a telefonokban nem ilyen rendszer dolgozik. Meg az NV nem is FAT jellegű, így hagyjuk. A cluster, a 4 kB minden körülmények között egy fizikai blokkba kerül akkor is, amikor fragmentált egy diszk. A fájlok fragmentálódása annyit jelent, hogy ezek a 4 kB-os blokkok nem sorban, egymás után helyezkednek el, hanem egymástól távol, szétszórva, azaz a következő blokk beolvasásához újra kell pozicionálni az olvasófejet, ami időbe telik...
Mivel bármely sor kicímzése a rendszerben pontosan ugyanannyi időbe telik, mindegy, hogy a legelső vagy a "legbelső", bármely clustert pontosan ugyanannyi idő alatt képes kitolni magából a kártya. Tehát, ha a fájl fizikailag a 26-27-28-dik clustert foglalja, a beolvasása pont annyi időbe telik, mintha a 26-1234-8766 clusterebken lenne...
3: a random szétszórás lehet, hogy még nincs a boltokban (én úgy tudtam, hogy igen, de lehet, hogy rosszul), annyira nem bonyolult, ráadásul az téves, hogy egy ilyen módon kezelt kártya tartalma a defrag számára mindig "egyben" látszik. Mivel a defrag nem "látja " a tényleges tartalmat, csak azt, amit a kártya belső vezérlője mutat kifele, fogalma sincs arról, hogy a tényleges elhelyezkedés nem egyezik azzal, ami ő lát.
A fájlrendszer kezelő kizárólag a FAT-ból (ez egy tábázat) és a directory clusterekben található leírásokból gondolja azt, hogy tudja, milyen állapotban vannak a fájljai. Már a modern IDE vagy SCSI diszkeken sem teljes a fizikai megfelelés, pláne ha néhány tartalékszektort is igénybe vett már a lemez.
Ahhoz, hogy a random jelleget elfedje a kártya, összesen egy táblázatra van szükség. A táblázatnak egyetlen oszlopa és annyi sora van, ahány clustert tartalmaz a kártya. A táblázat minden egyes cellájában ez az infó áll, hogy az adott sorszámú cluster pillanatnyilag épp melyik "fizikai" sorban lakik. Aki kívülről nézi a rendszert, és lekéri a 4. clustert, az meg fogja kapni akkor is, ha az ténylegesen a 26544. "sorban" van valójában.
Ahhoz, hogy ennek tényleges haszna legyen, kell még egy táblázat, aminek két oszlopa van és annyi sora, ahány Clustert tartalmaz a kártya. Az első mező értékét minden egyes írásnál növeljük eggyel (induláskor 0), a másodikba meg egy flaget teszünk, ami azt jelzi, hogy az adott "sor" tartalma épp érvényes, vagy a blokk "üres". Ha a számláló elér egy beállított értéket (mondjuk 10), akkor keresünk egy olyan sort, aminek a tartalma épp "üres", és a számláló kisebb, mint 10. Az aktuális írást ebbe a clusterbe végezzük el, az eredeti cluster "üres jelzőjét" beállítjuk, hisz az ott tárolt adatra nincs szükség, épp most írtuk ki egy másik blokkba. Az előző táblázat tartalmát is módosítani kell, hogy az indexünk a megfelelő "sorra" mutasson. Ne a régire, hanem az újra. Ezek a funkciók akár "drótozva" is lehetnek, még csak processzor sem kell hozzájuk, megfelelően összerakott kapusorozattal megoldhatóak, bár egy pic jellegű cuccal valóban kényelmesebb megoldani...
Amíg a "diszk" nincs tele, mindig lesz olyan "üres" blokk, amit fel lehet használni. Ha tele van, ez már nehéz, de ha a gyártó belerak a kártyába 1%-nyi olyan "blokkot" amit a kártya kívülről nem enged elérni, ezeket szabadon felhasználhatja ilyenkor. Gyanítom van is ilyesmi bennük, már csak azért is, mert a biteket tároló alkatrészek is kidőlhetnek a sorból és ha valamelyik blokkban egy ilyen van, valahogy ki kell zárni azt a munkából és helyettesíteni egy használhatóval.
Mindettől függetlenül még mindig kíváncsi vagyok egy mérés eredményére a fentebb vázoltak szerint...
--
SaGa
