Pascal-ban e feladat hogy oldható meg egyszerűen a TFileStream használatával? (én csak simán tudom)

Szuper, mostmár megtudhattuk tőled, hogy mi az a láncolt lista. De az adatok ettől még mindig nem ott vannak abban a clusterben ahol a lista elemek.

A láncolt lista a FAT-ben van, az adatok máshol.

"A láncolt lista a FAT-ben van, az adatok máshol."

Ne égesd már szénné magad!

A láncolt lista NEM LEHET a FAT-ben.

A FAT-ben bejegyzések vannak, egy-egy file-t érintő adatok, 32 byte hosszan és van még a FAT-ban egy foglaltsági táblázat, hogy optimalizálni lehessen a foglalást.

Ez utóbbi nem kötelező, ugyanis pl. bizonyos beágyazott rendszereknél, (főleg adatgyűjtés esetén) az a divat, hogy

az adattárolót leformázzuk, a bejegyzéseknek helyet hagyunk, majd a fennmaradó üres clustereken végigmegyünk, láncoljuk azokat. Ezután teszünk egy bejegyzést ami tartalmaz egy legenerált file nevet, majd az üres rész kezdő clusterének indexét. Ennek a kamu file-nak az első karakterét kinullázzuk, mintha törölve lenne.

Később ezt használjuk fel a foglaltság adminisztrációjára, mert ez csak 32 byte-ot (vagy ennél is kevesebbet) igényel, nem kell a teljes clster táblát leírni.

Amikor meg egy új file íródik, akkor ezt a "törölt" file-t vesszük használatba (írjuk felül) és amikor az új file-nak vége van, akkor a törölt kamu file első clusterét átírjuk az igazi file vége után következő cluster indexével és így meg van spórolva a foglaltsági tábla.

Na, megtudtál egy kevéssé publikus trükköt. Boldog lehetsz.

"A FAT-tel formázott rendszer fürtökre van osztva, tehát a kezelő szoftver egy bejegyzést tesz a gyökérkönyvtárba, melyben szerepelteti az első szelet helyét és a szeletek számát. Magában a szeletekben pedig a szelet végén mindig a következő szelet eleje van."

Forrás: [link]

Szerintem te égeted magad, bárki megnézheti neten, hogy hogy működik a FAT filerendszer.

És most nem bizonyos beágyazott rendszerekről van szó, ahol lehetséges hogy olyan filerendszer van amit te írsz, de az nem a FAT16/FAT32/exFAT.

Egyébként is PC-kben már az XP óta nem igazán használnak FAT-et. Windowson ott van at NTFS, *nix-on meg mások.

"Magában a szeletekben pedig a szelet végén mindig a következő szelet eleje van."

Fogd már fel, hogy ezek a szeletek nem a fileok tartalmát tartalmazzák. Ha tényleg ezzel foglalkozol 18 éve, nem tudom hogy lehetsz ilyen sötét ebben a témában.

""Ebben az esetben minden egyes szabad blokk UTOLSÓ NÉHÁNY bájtját KIEMELJÜK a klasszikus ADATTÁROLÁSI funkcióból, ugyanis EZEN A NÉHÁNY BÁJTON a KÖVETKEZŐ szabad blokk SORSZÁMÁT TÁROLJUK.""

Nem hát, nem a file-ok tartalmát. Hanem mit?

Nálad fafejűbb emberrel még nem találkoztam. Nem való neked ez a dolog. Hat példát hoztam, de te csak fafejűsködsz és kiállsz egy általad elképzelt hülyeség mellett.

Az való igaz, hogy a mai rendszereken már ritkán használnak FAT filerendszert (ha a pendrive-okat nem nézzük), de az NTFS, HPFS, EXTx, stb. rendszerek is hasonló elv szerint épülnek fel.

Még jó, hogy nem FAT, hiszen a FAT, bár zseniális, csak kis kapacitású adathordozókon érvényesül. de hát, 1977-ben még nem voltak csak floppy lemezes tárolók.

Az új rendszerek esetében a gyorsaság kulcsa a node-os hierarchiában és a nagy clusterméretben keresendő, amely ha pl. 64 kbyte, akkor éppen 128-szorosa a FAT alap cluster méretének. Ez pedig mindjárt ~ 128-szoros sebesség növekedést jelent, egy olyan technológián (SATA/SSD) ahol már a technikai kiépítés is 1000-szeres nagyságrendű sebesség-növekedéssel járt a korábbi rendszerekhez (FDD, HDD) képest.

Azt meg be se mondom, hogy a végigolvasásnál (SEEK) a 64 kb-os blokkot egy az egyben droppolja a rendszer, mivel csak annak végére kiváncsi, hogy tudja hol folytathassa az olvasást.

Ez pl. az ext2 struktúrája:

"There are pointers to the first 12 blocks which contain the file's data in the inode. There is a pointer to an indirect block (which contains pointers to the next set of blocks), a pointer to a doubly indirect block and a pointer to a trebly indirect block."

Feladom, végig olvassa a rendszer, ha megnyitsz egy filet és a végére seekelsz. Egy nagy összeesküvés elméletben élünk ahol a háttértárak jóval gyorsabbak mint aminek tettetik magukat (több terabyte / millisec), de ezt csak a seekeléskor haszálják ki. Más esetben limitálják pár 100 megabyte/sec-re.

További minden jót!

"Feladom,"

Ezt jól teszed. Még jobban tennéd, ha megtanulnád.

De ha csak nekiállsz és gondolkozol, már akkor is rájössz, hogy a te elképzelésed mennyire hibás, hiszen akkor optimális ez, ha a file végére kell seekelni, de akkor már koránt sem, ha a file-t olvasni, netán írni is kell.

Ez a te elképzelésed akkora adminisztrációs terhet róna a rendszerre, ami használhatatlanná is tenné.

Fogadd el szépen, hogy bizony az a jó megoldás, amit okosak kimunkáltak és megvalósítottak, mert ekkor az olvasófejnek nem kell fölösleges munkát végeznie, az interleave segíti az olvasás sebességét, mert ekkor mindig éppen azt a szektort olvassa a fej, amit kell neki. Azt pedig javaslom neked kiszámolásra, hogy ha csak 64 kb-os blokkonként kell pár byte információt kiolvasni ahhoz, hogy a nagy terjedelmű (mondjuk 1 TB-os) file végére érjen, mennyi idő szükségeltetik, egy átlagos SATA drive esetében. Ha nekiállsz és a végére jutsz, meg fogsz lepődni.

47%-os: Pedig te tévedsz, megnéztem egy programmal (Active Partition Recovery) egy NTFS filerendszert, és nincsenek ilyen fenntartott byteok amik a következő blokkokra/klaszterekre mutatnának. Az MFT tartalmazza, hogy hol vannak a file részletei.

Egyébként gondolj bele, mennyire gond lenne virtualizáció esetén ha úgy lenne ahogy te írod... a virtuális 512 bytos klaszter fizikailag 2 klaszterben lenne a végén lévő lecsípett bájtok miatt. Sokat ártana ez a performanciának.