[FS]Heb ik nu een geniaal plan?

[Verwijderd]

Dit is serieus, ik denk dat ik met een geniaal plan op de proppen kom. Het zal me niet verbazen als zoiets al bestaat, maar ik draag mijn idee ter evaluatie aan.

De harddisk zelf houdt een tabel bij van haar sectoren. Daar bovenop komt het bestandssysteem met haar afwijkingen zoals gevoeligheid voor fijne fragmentatie.

Nu dacht ik aan het volgende. Wat als we een bestandssysteem maken dat werkt op cylinders van de harddisk in plaats van op sectoren. Het idee is dan de 3 eerste cylinders als index gebied (om de hele index te lezen hoeft de harddisk slechts 3 track2track seek/read acties doen wat op een moderne schijf 400ms (s4/r396ms) kost. Deze 24 MiB is te cachen zodat de accessing minder wordt (lazy writing).
Daarnaast zijn een bepaalde groep cylinders gebonden aan het journaled transactielogboek.

Alles ligt dus op een boundairy van 8 MiB. Je zou dus een enorme 'slack' kunnen verwachten als we cylinders grofweg als clusters behandelen. Echter denk ik aan een implementatie van sector based areas zodat je meerdere bestanden op sector boundairy kunt opslaan per cylinder terwijl Windows of een ander OS alleen hoeft te weten in wélke cylinder de gevraagde data staat. Hierop kun je goed defragmenteren (I-FAAST^tm principe).
Het maakt dan helemaal niets uit als een groepje bestandjes in een cylinder ernstig gefragmenteerd raakt. Als de harddisk de hele cylinder inleest kan de computer de data on the fly defragmenteren en daar merk je absoluut niets van als het gaat om rauwe geheugensnelheden van 6,4 GiB/s (DC DDR400). Je hoeft dan alleen nog te defragmenteren/uitlijnen op cylinder basis en dat gaat dus met 100% efficientie van de hele harddisk. Zo zou je een groepje cylinders kunnen samenvoegen met bestanden die elke XP installatie altijd laadt met daaropvolgt de custom data. Zo krijg je ongelovelijk snelle datatoegang omdat er geen kwestie meer is van wachten op een bepaalde sector. Zodra de kop boven de goede cylinder komt kan hij direct de hele ronde lezen en kan hij starten bij de eerst volgende sector van die cylinder en dan de volgende 16383 sectoren lezen en weer verdergaan. Fragmentatie speeld hier op cylinderniveau geen rol. Moest je eens weten hoe ernstig je interne geheugen gefragmenteerd is altijd!

->De eerste cylinder bevat meerdere ingangen van het MBR zodat de disk niet meer afhankelijk is van één enkele sector. Daarnaast van het een FAT16 tabelletje kwijt voor de cylinders en de pointers naar cylindergebieden.
->De laatste cylinder bevat een back-up van de eerste cylinder zonder FAT ingangen
->De middelste cylinder bevat een back-up van de eerste cylinder zaols in de laatste cylinder
->De tweede cylinder is een mirror van de eerste cylinder en kan niet door derde API's bewerkt worden (virussen). ALs cylinder een faalt recovert hij vanaf de tweede cylinder. FAT corruptie is dan uitgesloten omdat het journaled is. De cylinder bestaat of niet en kan recoveren op sectorniveau.
->Je kunt zonder writecache dus hooguit een cylinder recoveren per transactieingang. NTFS kan hier de mist mee ingaan.

Wat jullie?

[cornelixnootje1]

Ik begrijp er geen hout van.

Maar voor een geniaal plan vind ik dat er weinig enthousiast gereageerd wordt.

[GH45T]

Misschien ben ik wel de enige die niet snapt waarom jullie een topic van een half jaar oud trappen.

Ontopic:
Klinkt leuk, maar zoals ik het lees moet de harddisk met flink meer logica worden uitgevoerd aangezien elke harde schijf en zelfs elke individuele cilinder een andere grootte heeft.

[ Voor 49% gewijzigd door GH45T op 04-12-2006 18:53 ]

[FlyEragon]

Verwijderd schreef op zaterdag 20 mei 2006 @ 19:16:
Als de harddisk de hele cylinder inleest kan de computer de data on the fly defragmenteren en daar merk je absoluut niets van als het gaat om rauwe geheugensnelheden van 6,4 GiB/s (DC DDR400).

Dit snap ik ff niet, de data moet nog wel weggeschreven worden en dat gaat toch niet met memory speeds ?

[McKaamos]

Erkandude schreef op maandag 04 december 2006 @ 18:54:
[...]


Dit snap ik ff niet, de data moet nog wel weggeschreven worden en dat gaat toch niet met memory speeds ?

nee maar het kan wel allemaal in 1 cirkel op de schijf, zodat je dus niet constant heen en weer hoeft te vliegen met de kop.
Dat bespaart tijd op de accesstimes waardoor je dus hogere throughput moet kunnen halen.
Het hele idee is er op gebaseerd dat er zo min mogelijk kop activiteit is bij het laden van dingen, om zo tijd te sparen die je dan weer voor het inlezen van data gebruikt kan worden.
De ingelezen data gaat linea recta naar het RAM, alwaar de nuttige data er uit gepakt wordt. Memory heeft nl nagenoeg geen accesstime en ook geen track2track tijd (tov een harddisk).
Daardoor kan je de losse blokjes die nodig zijn meteen uit het RAM lezen zonder de kop losse plekjes op de HDD te laten lezen. Scheelt tijd.

Ik denk dat dit een heel goed plan is iig. Nu de uitwerking nog...
Ik gok dat je dit niet zomaar op een PC kan implementeren, maar dat je een controller nodig gaat hebben met eigen RAM.

[ Voor 29% gewijzigd door McKaamos op 04-12-2006 19:04 ]

[FlyEragon]

Ok, ik zou de boel dan patenteren voordat iemand ermee aan de slag gaat

[BalusC]

* BalusC heeft zojuist een paar loze replies verwijderd. Hou het serieus aub, het is hier geen HK

[wboevink]

Volgens CHS zijn er maar 1024 cylinders, daarvoor is LBA weer uitgevonden (anders is je schijf maximaal 528 MB). Ik vraag me af of je een schijf wel op zijn daadwerkelijke cylinder niveau kan benaderen. En wie zal dat regelen? De bios of het os?

Daarnaast doet de schijf cache van 8mb of 16mb ook al heel wat, niet te vergeten de caching van op sommige controllers (van 64mb tot 512mb of meer).

Zie het nut ook niet in van een cylinder inlezen dat is toch niks anders dan een heleboel sectoren gelijk inlezen?

[cornelixnootje1]

Ik had verwacht genomineerd te worden voor meest nutteloze kick allertijden, maar blijkbaar wordt er nog best serieus op ingegaan.

[TheZeroorez]

cornelixnootje1 schreef op maandag 04 december 2006 @ 20:49:
Ik had verwacht genomineerd te worden voor meest nutteloze kick allertijden, maar blijkbaar wordt er nog best serieus op ingegaan.

De nominaties zijn al gesloten

Maargoed.. Als dit al een geniaal plan was (heb het niet gelezen), is het dat nu niet meer. Waarom niet? Omdat je geen patent hebt, en het hier post..

[BalusC]

cornelixnootje1 schreef op maandag 04 december 2006 @ 20:49:
Ik had verwacht genomineerd te worden voor meest nutteloze kick allertijden, maar blijkbaar wordt er nog best serieus op ingegaan.

Met zulk een mentialiteit heb je hier niks te zoeken

Ontopic aub

[Verwijderd]

Verwijderd schreef op zaterdag 20 mei 2006 @ 19:16:
Alles ligt dus op een boundairy van 8 MiB. Je zou dus een enorme 'slack' kunnen verwachten als we cylinders grofweg als clusters behandelen. Echter denk ik aan een implementatie van sector based areas zodat je meerdere bestanden op sector boundairy kunt opslaan per cylinder terwijl Windows of een ander OS alleen hoeft te weten in wélke cylinder de gevraagde data staat. Hierop kun je goed defragmenteren (I-FAAST^tm principe).

Euhm... Ik vrees dat ik je moet teleurstellen want het hele grote lijnen werkt het nu al zoals jij aangeeft. Een disc-controller leest echt niet alleen de sector die gevraagd wordt, maar doet aan read-ahead en andere trukken en prutsen

Jou 'idee' lijkt trouwens ontzettend veel op het systeem dat vroeger van toepassing was op het aflezen van data van diskettes. Die drives zijn van nature track based ipv sector based en daar moest je gewoon de hele track inlezen om hem te encoden en er een sector uit te halen...

[Verwijderd]

M'n topic, wat doe je


Het plan is inmiddels overlegd aan collega's en die kijken wat ze ermee kunnen doen. Ik ga niet uitleggen hoe je de sector boundairy kunt aanspreken.
Mogelijk heb ik inderdaad een filesysteem optimalisatie ontdekt.

Een collega wil dit voor mij testen, hij is programmeur en hij zal eens gaan testen met het idee.
NCQ en die zooi zul je niet meer nodig hebben.

Inmiddels is hij al een eind.

[ Voor 4% gewijzigd door Verwijderd op 06-12-2006 04:47 ]

[Stouten]

Ik heb het vage vermoeden dat dit dergelijk gecompliceert is, dat de grote fabrikanten het links laten liggen... ook lijkt het mij vrij sterk dat geen van de fabrikanten hier ooit op gekomen zou zijn! Maar je weet maar nooit, mocht het niet zo zijn en het werkt goed, sta ik in de rij

[Verwijderd]

Eenzelfde idee heb ik ook gehad als volgt (kan ook zijn dat het gewoon al bestaat, geen idee):
Pakweg een hd met 4 schijven (platters), elke schijf heeft 2 zijden. Dus er zijn 8 oppervlakken in totaal waarop gegevens staan. Voor elk oppervlak is er een lees en schrijfkop. Kan men de hd niet zodanig uitvoeren dat elke kop onafhankelijk kan bewegen, en aldus onafhankelijk kan lezen en schrijve?. Hierdoor krijg je als het ware een soort van 8 stuks sub-hd waarbij er 8 datastromen (en aldus 8 bestanden) tegelijk kunnen worden getransfered.
Zie het als een soort van multitasking bij de hd (je kan de hd dan ook vergelijken met een 8 core cpu) waarbij 8 los van elkaar staande lees/schrijf operaties tegelijk kunnen worden uitgevoerd.

[Verwijderd]

Verwijderd schreef op woensdag 06 december 2006 @ 10:58:
Eenzelfde idee heb ik ook gehad als volgt (kan ook zijn dat het gewoon al bestaat, geen idee):
Pakweg een hd met 4 schijven (platters), elke schijf heeft 2 zijden. Dus er zijn 8 oppervlakken in totaal waarop gegevens staan. Voor elk oppervlak is er een lees en schrijfkop. Kan men de hd niet zodanig uitvoeren dat elke kop onafhankelijk kan bewegen, en aldus onafhankelijk kan lezen en schrijven. Hierdoor krijg je als het ware een soort van 8 stuks sub-hd waarbij er 8 datastromen (en aldus 8 bestanden) tegelijk kunnen worden getransfered.
Zie het als een soort van multitasking bij de hd (je kan de hd dan ook vergelijken met een 8 core cpu) waarbij 8 los van elkaar staande lees/schrijf operaties tegelijk kunnen worden uitgevoerd.

Had ik al eerder geofferd, maar het is inderdaad waar dat men niet zit te wachten op een nieuw filesysteem. Mijn idee zit juist niet gecompliceerd in elkaar. Met een driver van rond de 100 KB is het zaakje aan te sturen.

Ook denk ik geen patent te krijgen omdat de harddisk bijna dood is. Over 5 a 6 jaar werken wij via SRAM solid state disks en die kennen een fysieke structuur van heads en tracks.

Nochtans ben ik bezig het een de grote klok te hangen. Zoiets is heel moeilijk en ik moet mijn script nog maar eens aanpassen.

[Verwijderd]

Verwijderd schreef op woensdag 06 december 2006 @ 15:42:
Ook denk ik geen patent te krijgen omdat de harddisk bijna dood is. Over 5 a 6 jaar werken wij via SRAM solid state disks en die kennen een fysieke structuur van heads en tracks.

Maar dat wordt al jaren gezegd. Elektronische geheugens gaan er op vooruit, maar ondertussen staat de ontwikkeling van de hd's ook nog niet stil. Zulkse ontwikkelingen zouden enorme boosts kunnen betekenen voor hd's waardoor ze volgens mij zeker nog jaren de concurrentie met elektronisch geheugen aankunnen.