újabb világmegváltó ötleteim

mivel ezeket eladni úgysem lehetne, kifejleszteni meg még kicsi vagyok :D ezért ideírom: (opensource ötletek, nyugodtan tovább lehet ám gondolni)
azon tűnődtem, milyen egyhangú a hdd-k piaca. jó volna feldobni, mielőtt még elterjednének az ssd-k - az még egy fél évtized szvsz.

1. a) 5,25"-os hdd. nagyobb tányér, több adat.

1. b) többfejes hdd. miért ne lehetne egy diszkben több fej? kvázi lemezen belüli hardveres raid0: a két fej egyszerre két helyre pozicionálhat, csökken az elérési idő, kifejezetten jó véletlenszerű elérésnél. akár ellenőrizni is tudnák egymást a fejek adott esetben.

1. c) sokkal nagyobb cache. a mai memóriaárak mellett nevetséges a 32mb illetve 16mb-os cache méret. gigát bele!

1. d) hibaellenőrzés: legyen beépítve a lemezbe egy flash memória és ezen tárolja a lemez a rajta lévő adatok valamiféle ellenörzőösszegét vagy hash-ét. amíg ráírja/leolvassa a lemezről, addig hardveresen elvégzi az ellenörzőösszeg-számítást és ráírja/leolvassa a flash-ről, majd utánaküldi az eredményt az adatoknak. így nem romlana a késedelem, sőt mivel ma is folyik hasonló, csak a lemezen magán tárolja, így azt nem kellene külön leolvasni, hanem mehetne e flashre - így még gyorsabb is lehetne a lemez.

további ötletek, most az optikai tárakhoz:

2. a) legyenek a lemezek tokkal egybeépítve és a meghajtó vegye ki belőle, vagy nyisson ki rajta egy ablakot és tegye oda az olvasófejet, ahova kell. lásd: floppy. nem karcolódna össze és a tok védené a fénytől a lemezt. cserébe persze fizikailag több helyet foglalna, de legalább megbízható lenne, nem úgy mint most.

2. b) több olvasófej. lásd: 1. b) - bár ez nem olyan jó ötlet, hiszen nem szokás egyszerre sok dolgot olvasni optikai lemezekről. ugyanígy lehetne cachet adni az olvasóknak is, de ez is szintén felesleges, szvsz.

2. c) lightscribe. ja, hogy azt már kitalálták ^^

na mára ennyi az ötletmorzsákból :)

Hozzászólások

Az első generációsok lassúak is voltak, meg le is égtek, mert ugyanaz a meghajtó lengette fejegységet, mint a normál vinyókban, csak épp picit nehezebb és nagyobb volt a kar.
A kéttárcsás megoldásnál tipikusan az egyik tárcsa csomag állt be, sanda gyanúm szerint a levegőztetés, vagy az egyenetlen melegedés miatt. Annyi előnye volt, hogy az elektronika két különálló egységként kezelte a lemezkötegeket, ezért az egyik behalása esetén feleződött a meghajtó. A másik előnye, hogy ha szét voltak az adatok szórva a két kötegen, akkor iszonyatgyors tudott lenni.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

legyenek a lemezek tokkal egybeépítve és a meghajtó vegye ki belőle, vagy nyisson ki rajta egy ablakot és tegye oda az olvasófejet, ahova kell. lásd: floppy

És ugyanúgy körbevágná Gizike egy ollóval... :)
--
Fight / For The Freedom / Fighting With Steel

1a) mi a célpiac? laptop nyilván nem, a desktopokba meg szvsz elég amit ma bele lehet nyomni. Szerverben elképzelhető, de ahol lényegesen nagyobb kapacitás kell, ott talán nem az egyes hdd mérete a döntő.

1b) kétfejes megoldás: afaik a jelenlegi megoldásokban egyszerre egy fejjel foglalkoznak — ehhez meg kéne írni az ütemezőket, jól.

1c) igen, csak aztán kikapcsoláskor percekig írja, és akkor még áramszünet se volt:)

2a) DVD-RAMot árulnak így

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

1. a) Maximalizáljuk az elveszthető adatmennyiséget! :D

:)

1a) A Quantum gyártott anno 5,25"-os HDD-t. Nem lett sikeres.

--
Elméletileg nincs különbség elmélet és gyakorlat között. Gyakorlatilag van.

ha jól tudom 2b is létezett (bár, nem terjedt el). Mikor már az 52* cd meghajtóknál a hagyományos módon nem lehetett a sebességet növelni, jött ki egy-két gyártó két-három fejes cd meghajtóval, 70-100* sebességűnek írva. de ez rég volt, tán igaz sem volt...

1a, Korai Bigfoot lemezeknel mar alkalmaztak. Nem jo, mert drasztikusan no az eleresi ido.
1b, No a fogyasztas, plusz duplazni kell az elektronikat a mechanikat, es szinkronizalni az olvasott adatokat. Ez nem illik a mostani veddmegdobbdel szemeleletbe.
1c, Cache akkor elonyos ha sok kicsi file-al kell sok muveletet vegrehajtani. Nagy fileoknal tipikusan az egesz rendszer sebessege a mervado.
1d, Jo otlet, csak epp a fileok abrazolasa fajlrendszerfuggo.

2a, Ilyenek voltak a korai caddys CDk, az elso generacios blue-ray prototipusok, es a MiniDisk is. A nepszerutlensegenek az oka, hogy a egy DVD tokot egy muveletben lehet froccsonteni, ezt meg szerelni kell. Ami draga.
2b, Korai Kenwood "nagysebessegu" (8x-os) CD olvasoknak alkalmaztak a 4 fejes megoldast. Draga, mert a legdragabb alkatreszt a lazer pick-upot kell megtobbszorozni.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "