3 TB fra Seagate?

[Theo343]

Det løser ikke problemet, det der blir som f.eks. NTFS støtter clustere på 64kB for å støtte partisjoner på 256TB. Det som må gjøres er å utvide adresserommet til LBA med tilstrekkelig mange bits, på tilsvarende måte som IPv4 byttes ut med IPv6. Om vi stadig skal endre størrelsen på sektorene så bryter vi kompatiblitet.

For eksempel 64bits LBA med sektorer på 4kB skal vel gi noe sånt som 64 zettabyte i adresserom

Vi bør gjøre dette nå som vi likevel bryter BIOS-kompatiblitet, så slipper vi å gjøre det mange ganger fremover. Før eller siden må LBA utvides uansett.

ATW:

Ok, så da missforstår jeg Efikkan her?

 

Forøvrig har jeg selv brukt GPT siden Windows 2003 hadde støtten men jeg så ikke det som problemet her. Problemet er boot.

Muligens blir boot på GPT også fikset for WindowsPC siden vi (snart) går over på EFI bioser også på Wintel dekstops.

Endret 15. mai 2010 av Theo343

[Dudeson]

Blir nok dyre i starten disse,og er det ikke høyere feilrate på disker over 1TB?mener og ha lest noe om det.

[ATWindsor]

Det løser ikke problemet, det der blir som f.eks. NTFS støtter clustere på 64kB for å støtte partisjoner på 256TB. Det som må gjøres er å utvide adresserommet til LBA med tilstrekkelig mange bits, på tilsvarende måte som IPv4 byttes ut med IPv6. Om vi stadig skal endre størrelsen på sektorene så bryter vi kompatiblitet.

For eksempel 64bits LBA med sektorer på 4kB skal vel gi noe sånt som 64 zettabyte i adresserom

Vi bør gjøre dette nå som vi likevel bryter BIOS-kompatiblitet, så slipper vi å gjøre det mange ganger fremover. Før eller siden må LBA utvides uansett.

ATW:

Ok, så da missforstår jeg Efikkan her?

 

Forøvrig har jeg selv brukt GPT siden Windows 2003 hadde støtten men jeg så ikke det som problemet her. Problemet er boot.

 

Spørs litt hvor langt man tenker framover, per i dag så er 2 TB-grensen ikke forårsaket av LBA, og det er det som skaper trøbbel her og nå. Det effikan taler for er at om man allikevel får inkompatible bios-oppdateringer (som forsåvidt kanskje ligger på trappene), så kan man like gjerne utvide kapasiteten på LBA også. 128 Petabyte er endel, men det holder kanskje ikke evig, fortsetter det mer eller mindre i dagens hastighet vil det kanskje ta 20-30 år før det blir et problem. Om man oppgraderer så vil det i praksis neppe bli et problem noensunne (ettersom hvor hardt man tar i). Om du misforstår vet jeg ikke, spørs litt hva du trodde og ikke trodde, men det vet du vel best selv, det er ihvertfall slik som skissert det ligger ann per i dag.

 

AtW

[Theo343]

Ergo så fort vi får boot mot GPT på vanlige desktops har vi ikke problemet lenger. Nå har jeg sjelden så store boot partisjoner uansett.

Endret 15. mai 2010 av Theo343

[GullLars]

Ja, det er bare å få implementert (U)EFI som standard BIOS ASAP

TBF FTW

[efikkan]

EFI er ingen akseptabel løsning. EFI-loaderen som da kreves til hvert enkelt operativsystem er i Microsofts PE-format som er lukket.

Sist jeg sjekket spesifikasjonene så startet også EFI opp i 32bit protected mode, og det betyr at de som skal kjøre 64bits operativsystemer (som de fleste fornuftige gjør i dag) må tilbake i real mode som både er en sikkerhetsrisiko og som tar tid.

[GullLars]

Jeg er ikke kjent med de spesifike delene av EFI, men det ville vært kjekt å få en mer moderne BIOS. Den bør da være open source, 64-bit, og gjøre oppgaver og starte opp i parallell.

[efikkan]

Jeg er ikke kjent med de spesifike delene av EFI, men det ville vært kjekt å få en mer moderne BIOS. Den bør da være open source, 64-bit, og gjøre oppgaver og starte opp i parallell.

EFI er en slags mer avansert BIOS, men ærlig talt, hva slags funksjonalitet trenger vi i BIOS som vi ikke har i dag?

Å kjøre over i 64bits protected mode medfører at kernel startes for å page minnet, jeg ser ikke for meg at det er en fordel at BIOS gjør dette før kernel faktisk blir lastet. Kernel må uansett da sørge for å tømme minnet, ellers blir det en sikkerhetsrisiko.

Oppstart i parallell, forklar.

Nei BIOS bør beholdes enkel og stabil, kun det som trengs. Det jeg savner er raskere oppstart og et bedre GUI til BIOS.

[Sokkalf™]

BIOS er ikke "enkel" idag. Den inneholder en hel haug med crap som kan få DOS til å kjøre i 16-bit real mode. Det er helt unødvendig idag, da ingen reelle OS trenger funksjonaliteten som BIOS tilbyr. Det er nettopp dette EFI stripper bort, og medfører betydelig raskere oppstartstid.

[efikkan]

BIOS er ikke "enkel" idag. Den inneholder en hel haug med crap som kan få DOS til å kjøre i 16-bit real mode. Det er helt unødvendig idag, da ingen reelle OS trenger funksjonaliteten som BIOS tilbyr. Det er nettopp dette EFI stripper bort, og medfører betydelig raskere oppstartstid.

En vanlig misforståelse. Interrupts brukes i moderne operativsystemer(de må spesialdesignes for å kjøre uten), selv om en god del av de er unødvendige i dag. Men dette fører ikke tregere oppstart eller noe slikt, bare noen få kB større BIOS-image, så det er ikke et reelt problem. Det som BIOS derimot gjør som er helt unødvendig i oppstart er å identifisere og sjekke alle enhetene i maskinen, og dette er det som utgjør mesteparten av oppstartstiden før booting. Både minnetesten og testen av disker er helt meningsløs, siden den ikke klarer å avdekke feil med mindre det er noe veldig galt. Dessuten så utfører operativsystemer denne testingen og identifiseringen selv, GNU/Linux utfører en mye grundigere sjekk på effektivt vis. EFI tilfører på sin side mye unødvendig funksjonalitet som operativsystemer i dag ikke er designet for å utnytte, tanken har faktisk vært å få drivere til å operere på dette nivået, uavhenging av hvilket operativsystem som kjører. Et av problemene er at Intel har stått bak dette og har designet det fra sitt perspektiv, som ikke er operativsystemer. Operativsystemer i dag bruker bare litt av grunnfunksjonaliteten til EFI for de som kjører hovedkort med dette. Men om operativsystemer skal fungere på den måten som EFI er tiltenkt, så må hele drivermodellen legges om, denne funksjonaliteten må delvis over i EFI, det blir altså et ekstra lag med funksjonalitet som det kan være bugs, ustabilitet, og sikkerhetshull i, og operativsystemet er ikke fritt til å kontrollere dette, og på toppen av det hele er det bygd på et proprietært format. BIOS i dag tar seg av å videresende trafikken til enhetene (litt forenklet), BIOS blander seg ikke i hva som sendes eller hva mottaker er. Hvis EFI skal brukes som tiltekt må altså operativsystemer spesialdesignes for dette (noe ingen store er i dag, det er kun elementer lasting i EFI som er implementert), all maskinvare må få sine "drivere" i EFI, og det må lages et system for å oppdatere disse driverene til hovedkortet, noe trolig operativsystemet vil ta seg av.

 

Vi trenger uansett mesteparten av funksjonaliteten som BIOS har i dag, altså 1) håndtere tastatur, skjerm (via VESA VBE) og kanskje mus 2) kommunikasjon til maskinvare 3) et konfigurasjonsverktøy (som også EFI har).

Det som BIOS bør kutte ut er testing av maskinvare og muligens noen få interrupts som ikke brukes lenger.

Det som bør endres er støtten for en ny type MBR.

 

Gjør vi dette så løser vi de reelle problemene som vi har i dag og fremover en stund. EFI er primært løsningen på "driverproblemet", som kanskje vil bli aktuelt en god stund frem i tid men ikke i dag. Kanskje er EFI modent om noen år, men jeg har mer troen på at det utvikles noe mer gjennomtenkt.