Large Disk HOWTO Andries Brouwer, aeb@cwi.nl; svensk översättning: Joel Ros­ dahl, joel@rosdahl.net v1.1, 18 May 1998; svensk översättning 20 augusti 1998 Allt om hårddisk-geometrier och 1024-cylindersgränsen för hårddiskar. 1. Problemet Antag att du har en hårddisk med fler än 1024 cylindrar. Antag också att du har ett operativsystem som använder sig av BIOS. Då har du problem, eftersom det vanliga INT13-BIOS-gränssnittet för hårddisk-I/O använder ett 10-bitarsfält för att ange aktuell cylinder, så att cylinder 1024 och däröver är oåtkomliga. Som tur är använder Linux sig inte av BIOS, så det är inget problem. Ja, förutom två saker, då: (1) Linux är inte startat när du startar datorn och kan därför inte rädda dig från BIOS-problem. Det har vissa konsekvenser för LILO och liknande multibootprogram. (2) Det är nödvändigt för alla operativsystem som använder en och samma hårddisk att komma överens om var partitionerna ligger. Med andra ord, om du använder både Linux och, säg, DOS på samma hårddisk måste båda tolka partitionstabellen på samma sätt. Detta har vissa konsekvenser för Linux-kärnan och för fdisk. Nedan finns en ganska detaljerad beskrivning av alla relevanta detaljer. Notera att jag använde källkoden för Linux version 2.0.8 som referens. Andra versioner kan skilja sig åt lite grann. 2. Boot-fasen startas läser BIOSet sektor 0 (känt som MBR - Master Boot Record) från den första hårddisken (eller från diskett) och hoppar till koden som finns där -- normalt någon bootstrap-laddare. Dessa små bootstrap- program som hittas där har typiskt inga egna drivrutiner för hårddiskar och använder BIOS-tjänster. Detta innebär att en Linux- kärna bara kan laddas om den i sin helhet ligger inom de 1024 första cylindrarna. Detta problem är enkelt att lösa: se till att kärnan (och möjligen andra filer som används under uppstart, som till exempel map-filer till LILO), ligger på en partition som i sin helhet ligger inom de 1024 första cylindrarna på en hårddisk som BIOS kan komma åt -- förmodligen innebär detta den första eller andra hårddisken. En annan sak är att bootblocksladdaren och BIOS måste vara överens om vilken geometri hårddisken har. Det kan hjälpa att ge parametern "linear" till LILO. Mer information om det längre ner. 3. Hårddiskgeometri och partitioner Om du har flera operativsystem på dina hårddiskar använder var och en av dem en eller flera partitioner. Om operativsystemen inte är överens om hur partitionerna ligger kan konsekvenserna bli katastrofala. MBR innehåller en partitionstabell som beskriver var (de primära) partitionerna finns. Det finns 4 poster i tabellen för 4 primära partitioner, och varje post ser ut som struct partition { char active; /* 0x80: bootbar, 0: ej bootbar */ char begin[3]; /* CHS för första sektorn */ char type; char end[3]; /* CHS för sista sektorn */ int start; /* sektornummer (32-bitarstal, med början på 0) */ int length; /* antal sektorer (32-bitarstal) */ }; (där CHS står för cylinder/huvud/sektor). Sålunda är informationen redundant: stället partitionen ligger på är givet både av de 24-bitars begin- och end-fälten och av de 32-bitars start- och length-fälten. Linux använder bara start- och length-fälten och kan därför hantera partitioner som inte är större än 2^32 sektorer, det vill säga högst 2 TB stora partitioner. Det är hundra gånger större än hårddiskarna som är tillgängliga idag, så det kanske räcker för de nästkommande 80 åren, eller så. Olyckligtvis använder INT13-BIOS-anropet CHS kodad som tre byte, med 10 bitar för antal cylindrar, 8 bitar för antal huvuden och 6 bitar för antal sektorer. Möjliga värden för antal cylindrar är 0-1023, möjliga värden för antal huvuden är 0-255 och möjliga värden för antal sektorer är 1-63 (ja, sektorer på ett spår räknas med början på 1, inte 0). Med dessa 24 bitar kan man adressera 8455716864 byte (7,875 GB), tvåhundra gånger större än hårddiskarna som fanns tillgängliga 1983. Ännu mer olyckligt är att standardmässiga IDE-gränssnitt tillåter 256 sektorer/spår, 65536 cylindrar och 16 huvuden. Detta i sig själv tillåter åtkomst till 2^37 = 137438953472 byte (128 GB), men kombinerat med BIOS-begränsningarna (högst 63 sektorer och 1024 cylindrar) ger detta att bara 528482304 byte (504 MB) kan adresseras. Detta är räcker inte för dagens hårddiskar, och folk får ta till alla sorters trick, både hårdvaru- och mjukvarumässiga. 4. Översättning och hårddiskhanterare Ingen är intresserad av vad den "riktiga" geometrin för en hårddisk är. Faktiskt är antalet sektorer per spår ofta variabelt -- det finns fler sektorer per spår nära den yttre kanten på hårddisken -- så det finns inget "riktigt" antal sektorer per spår. För användaren är det bäst att betrakta en hårddisk som en linjär samling sektorer numrerade 0, 1, ..., och låta hårddiskkontrollern ta reda på var en given sektor finns på hårddisken. Denna linjära numrering kallas för LBA. Den linjära adressen som hör till (c,h,s) för en hårddisk med geometrin (C,H,S) är c*H*S + h*S + (s-1). Alla SCSI-kontrollrar, och några IDE-kontrollrar, pratar LBA. Om BIOSet konverterar 24-bitarsadressen (c,h,s) till LBA och skickar den till en kontroller som förstår LBA kommer 7,875 GB att vara adresserbart. Inte nog för alla sorters hårddiskar, men i alla fall en förbättring. Notera att CHS, så som det används av BIOS, här inte längre har någon koppling till "verkligheten". Någonting liknande fungerar när kontrollern inte pratar LBA, men när BIOS känner till översättning. (Det indikeras ofta som "Large" i BIOS-inställningarna.) Då kommer BIOS att presentera en geometri (C',H',S') för operativsystemet och använda (C,H,S) när den kommunicerar med diskkontrollern. Normalt är S = S', C' = C/N och H' = H*N, där N är den minsta exponenten till två som säkerställer att C' <= 1024 (så att så lite av kapaciteten som möjligt slösas bort i avrundning av C' = C/N). Åter igen, detta ger en adressrymd på 7,875 GB. Om ett BIOS inte känner till "Large" eller "LBA" finns det mjukvarulösningar. Hårddiskhanterare som OnTrack eller EZ-Drive byter ut BIOS' rutiner för hårddiskhantering mot sina egna. Detta åstadkoms ofta genom att låta hårddiskhanterarens kod ligga i MBR och påföljande sektorer (OnTrack kallar denna kod DDO: Dynamic Drive Overlay), så att den laddas innan operativsystemet. Det är därför man kan ha problem med att boota från diskett när en hårddiskhanterare har installerats. Effekten är mer eller mindre likadan som med ett översättande BIOS -- men hårddiskhanterare kan ställa till med mycket problem, speciellt när man kör flera olika operativsystem på samma hårddisk. Linux stöder hårddiskhanteraren OnTrack sedan version 1.3.14 och EZ- Drive sedan version 1.3.29. Lite mer detaljer ges nedan. 5. Hårddisköversättning av kärnan för IDE-hårddiskar detekterar närvaron av någon hårddiskhanterare på en IDE-hårddisk kommer den att försöka mappa om hårddisken på samma sätt som denna hårddiskhanterare skulle ha gjort, så att Linux ser samma hårddiskpartitionering som till exempel DOS med OnTrack eller EZ- Drive. Emellertid görs INGEN ommappning när en geometri specificeras på kommandoraden -- så ett kommandoradsargument som "hd=cylindrar,huvuden,sektorer" skulle mycket väl kunna förstöra kompatibiliteten med en hårddiskhanterare. Ommappningen görs genom att testa 4, 8, 16, 32, 64, 128, 255 huvuden (och hålla H*C konstant) tills antingen C <= 1024 or H = 255. Detaljerna är som följer -- titlarna för subkapitlen är strängarna som dyker upp i korresponderande boot-meddelanden. Här och överallt annars i denna text ges partitionstyperna med hexadecimaler. 5.1. EZD EZ-Drive kan kännas igen genom att den första primära partitionen är av typ 55. Geometrin mappas om enligt beskrivning ovan, och partitionstabellen från sektor 0 slängs bort -- istället läses partitionstabellen från sektor 1. Hårddiskblockens nummer ändras inte, men skrivningar till sektor 0 dirigeras om till sektor 1. Detta beteende kan ändras genom att kompilera om kärnan med #define FAKE_FDISK_FOR_EZDRIVE 0 i ide.c. 5.2. DM6:DDO Hårddiskhanteraren OnTrack (på den första hårddisken) känns igen genom att den första primära partitionen är av typ 54. Geometrin mappas om enligt beskrivning ovan, och hela disken skiftas 63 sektorer (så att den ursprungliga sektorn 63 blir sektor 0). Efteråt läses en ny MBR (med partitionstabell) in från sektor 0. Självklart är denna skiftning till för att göra plats för DDOn -- det är därför det inte görs någon skiftning på resten av hårddiskarna. 5.3. DM6:AUX Hårddiskhanteraren OnTrack (på resten av hårddiskarna) känns igen genom att den första primära partitionen är av typ 51 eller 53. Geometrin mappas om enligt beskrivning ovan. 5.4. DM6:MBR En äldre version av hårddiskhanteraren OnTrack känns inte igen genom partitionstyp, utan genom en signatur. (Testa huruvida offseten som finns i byte 2 och 3 på MBRen inte är större än 430 och talet som finns på denna offset är lika med 0x55AA och följs av en udda byte.) Återigen, geometrin mappas om enligt ovan. 5.5. PTBL Till sist finns ett test som försöker beräkna en översättning med hjälp av start- och end-fälten för de primära partitionerna: Om någon partition har start- och slutcylinder mindre än 256, och start- och slutsektor nummer 1 och 63, respektive, och sluthuvuden 31, 63 eller 127, så (eftersom det är brukligt att avsluta partitioner på en cylindergräns och eftersom IDE-gränssnittet använder högst 16 huvuden) antas det att en BIOS-översättning är aktiv och att geometrin är ommappad till att använda 32, 64 eller 128 huvuden, respektive. (Det finns kanske en brist här; genhd.c borde kanske inte ha testat de två mest signifikanta bitarna av cylindertalet?) Emellertid görs ingen ommappning när den nuvarande idén om hur geometrin ska vara inbegriper 63 sektorer per spår och åtminstone lika många huvuden (eftersom det då förmodligen innebär att en ommappning redan är gjord). 6. Konsekvenser Vad betyder allt det här? För Linuxanvändare bara en sak: att de måste se till att LILO och fdisk använder rätt geometri där "rätt" för fdisk är definierat som geometrin som används av de andra operativsystemen på samma hårddisk, och "rätt" för LILO definieras som geometrin som möjliggör lyckad interaktion med BIOSet vid uppstart. (Normalt sett sammanfaller dessa.) Hur känner fdisk till geometrin? Den frågar kärnan genom att använda ioctl:n HDIO_GETGEO. Men användaren kan själv, interaktivt eller på kommandoraden, bestämma vilken geometri som ska användas. Hur känner LILO till geometrin? Den frågar kärnan genom att använda ioctl:n HDIO_GETGEO. Men användaren kan själv, med hjälp av parametern "disk=", bestämma vilken geometri som ska användas. Man kan också ge parametern "linear" till LILO, som då kommer att lagra LBA-adresser istället för CHS-adresser i sin map-fil och räkna ut vilken geometri som ska användas vid uppstart (genom att använda INT 13 funktion 8 för att fråga om hårddiskgeometrin). Hur vet kärnan vad den ska svara? Jo, användaren kan explicit ha specificerat en geometri med en parameter som hd=cyls,heads,secs. Annars frågar kärnan hårdvaran. 6.1. IDE-detaljer Låt mig utveckla mig. IDE-drivrutinen har fyra källor för information om geometrin. Den första (G_user) är den som användaren kan ha specificerat på kommandoraden. Den andra (G_bios) är BIOS' parametertabell (för fixa hårddiskar; bara för den första och den andra hårddisken) som läses innan bytet till 32-bitarsmod. Den tredje (G_phys) och fjärde (G_log) returneras av IDE-kontrollern som ett svar på kommandot IDENTIFY -- de är de "fysiska" och "nuvarande logiska" geometrierna. Å andra sidan behöver drivrutinen två värden för geometrin: för det första G_fdisk, som returneras av en HDIO_GETGEO-ioctl, och för det andra G_used, som faktiskt används för I/O. Både G_fdisk och G_used initialiseras till G_user om den är given, till G_bios om informationen finns tillgänglig enligt CMOS, och annars till G_phys. Om G_log verkar vara rimlig sätts G_used till det. Annars, om G_used inte verkar rimlig och G_phys ser rimlig ut, sätts G_used till G_phys. Här betyder "rimlig" att antalet huvuden ligger i intervallet 1-16. Med andra ord: kommandoraden har högre prioritet än BIOSet och bestämmer vad fdisk ser, men om det specificerar en översatt geometri (med fler än 16 huvuden) kommer det som returneras från IDENTIFY- kommandot att användas för kärn-I/O. 6.2. SCSI-detaljer Situationen för SCSI är något annorlunda, eftersom SCSI-kommandona redan använder logiska blocknummer, så en "geometri" är helt irrelevant för I/O i praktiken. Formatet för partitionstabellen är emellertid fortfarande samma, så fdisk måste uppfinna en geometri och använder HDIO_GETGEO här också -- faktiskt skiljer inte fdisk på IDE- och SCSI-hårddiskar. Som man kan förstå från den detaljerade beskrivningen nedan, uppfinner de olika drivrutinerna en något annorlunda geometri. Helt klart en sagolik röra. Om du inte använder DOS eller så, undvik alla inställningar rörande utökad översättning och använd bara 64 huvuden, 32 sektorer per spår (vilket ger trevliga 1 MB per cylinder), om möjligt, så att inga problem uppstår när du flyttar hårddisken från en kontroller till en annan. Vissa drivrutiner för SCSI-hårddiskar (aha152x, pas16, ppa, qlogicfas, qlogicisp) är så måna om att bibehålla DOS-kompatibilitet att de inte tillåter ett system som bara kör Linux att använda mer än 8 GB. Detta är en bugg. Vad är den riktiga geometrin? Det lättaste svaret är att det inte finns någon sådan. Och om det fanns skulle du inte vilja vet något om den och säkerligen ALDRIG NÅGONSIN tala om den för fdisk eller LILO eller kärnan. Det är endast relevant för SCSI-kontrollern och hårddisken. Låt mig upprepa: bara dumma personer talar om den riktiga geometrin för en SCSI-hårddisk för fdisk/LILO/kärnan. Men om du är nyfiken och insisterar kan du fråga hårddisken själv. Det finns det viktiga kommandot READ CAPACITY som ger den totala storleken på hårddisken och det finns kommandot MODE SENSE som i "Rigid Disk Drive Geometry Page" (sida 04) ger antalet cylindrar och huvuden (detta är information som inte går att ändra), och "Format Page" (sida 03) ger antal byte per sektor och antal sektorer per spår. Det sistnämnda antalet är typiskt beroende av notchen och antalet sektorer per spår varierar -- de yttre spåren har fler sektorer än de inre. Linuxprogrammet scsiinfo kan ge den här informationen. Det finns många detaljer och komplikationer och det står klart att ingen (inte ens operativsystemet) vill använda denna information. Dessutom: så länge man enbart bryr sig om fdisk och LILO får man typiskt svar som C/H/S=4476/27/171 -- värden som inte kan användas av fdisk eftersom partitionstabellen endast reserverar 10 respektive 8 respektive 6 bitar för C/H/S. Så var får kärnanropet HDIO_GETGEO sin information från? Jo, antingen från SCSI-kontrollern eller genom att göra en kvalificerad gissning. Några drivrutiner verkar tro att vi vill känna till "verkligheten", men självklart vill vi bara veta vad FDISK i DOS eller OS/2 (eller Adaptecs AFDISK, etc) kommer att använda. Notera att Linux' fdisk behöver talen H och S (för huvuden och sektorer) för att kunna konvertera LBA-sektornummer till C/H/S- adresser, men talet C (cylindrar) spelar ingen roll i den här konverteringen. Några drivrutiner använder (C,H,S) = (1023,255,63) för att signalera att hårddiskkapaciteten är minst 1023*255*63 sektorer. Detta är olyckligt, eftersom det inte avslöjar den riktiga storleken, vilket kommer att begränsa användarna av de flesta fdisk- versionerna till att använda 8 GB av sina hårddiskar -- en riktig begränsning i dessa dagar. I beskrivningen nedan står M för den totala hårddiskkapaciteten och C, H, S för antalet cylindrar, huvuden och sektorer per spår. Det räcker att ge H, S om vi betraktar C som definierad av M / (H*S). Standardmässigt är H=64, S=32. aha1740, dtc, g_NCR5380, t128, wd7000: H=64, S=32. aha152x, pas16, ppa, qlogicfas, qlogicisp: H=64, S=32 om inte C > 1024, då H=255, S=63, C = min(1023, M/(H*S)). (Alltså trunkeras C och H*S*C är inte en approximation för hårddiskkapaciteten M. Detta gör de flesta fdisk-versioner förvirrade.) Koden i ppa.c använder M+1 istället för M och säger på grund av en bugg i sd.c att M är ett för lite. advansys: H=64, S=32 om inte C > 1024 och "> 1 GB" är inställt i BIOS, då H=255, S=63. aha1542: Fråga kontrollern vilket av två möjliga sätt att översätta på som ska användas och använd antingen H=255, S=63 eller H=64, S=32. I det första fallet blir det ett boot-meddelande: "aha1542.c: Using extended bios translation". aic7xxx: H=64, S=32 om inte C > 1024 och antingen boot-parametern "extended" gavs eller att biten "extended" var satt i SEEPROM eller BIOS, då H=255, S=63. buslogic: H=64, S=32 om inte C >= 1024, och om utökad översättning är inställt på kontrollern, så är H=128, S=32 om M < 2^22, annars H=255, S=63. Efter att detta val har gjorts läses partitionstabellen och om värdet endH=H-1 syns för någon av de tre möjligheterna (H,S) = (64,32), (128,32), (255,63), blir det ett boot-meddelande: "Adopting Geometry from Partition Table". fdomain: Ta reda på geometriinformationen från parametertabellen för hårddiskar i BIOS eller läs partitionstabellen och använd H=endH+1, S=endS för den första partitionen, ifall den inte var tom, annars: använd H=64, S=32 för M < 2^21 (1 GB), H=128, S=63 för M < 63*2^17 (3,9 GB) och H=255, S=63. in2000: Använd den första av (H,S) = (64,32), (64,63), (128,63), (255,63) som gör att C <= 1024. I det sista fallet, trunkera C vid 1023. seagate: Läs C,H,S från hårddisken. (Iiiick!) Om C eller S är för stor, sätt S=17, H=2 och dubbla H tills C <= 1024. Detta innebär att H kommer att sättas till 0 om M > 128*1024*17 (1,1 GB). Detta är en bugg. ultrastor och u14_34f: En av tre mappningar ((H,S) = (16,63), (64,32), (64,63)) används beroende på kontrollerns mappningsmod. Om drivrutinen inte specificerar geometrin använder vi en kvalificerad gissning genom att använda partitionstabellen eller genom att använda den totala hårddiskkapaciteten. Kolla på partitionstabellen. Eftersom, per konvention, partitioner slutar på en cylindergräns kan vi, givet end = (endC,endH,endS) för vilken partition som helst, helt enkelt sätta H = endH+1 och S = endS. (Kom ihåg att sektorerna räknas från 1.) Mer precist görs följande: Om det finns en icke-tom partition, välj den partition med störst beginC. Titta på end+1 för den partitionen, beräknat genom att både addera start och length och genom att anta att partitionen slutar på en cylindergräns. Om båda värdena stämmer överens eller om endC = 1023 och start+length är en heltalsmultipel av (endH+1)*endS, anta att partitionen faktiskt var placerad på en cylindergräns och sätt H = endH+1 och S = endS. Om detta inte fungerar, antingen på grund av att det inte finns några partitioner eller på grund av att de har konstiga storlekar, kolla bara på hårddiskkapaciteten M. Algoritm: sätt H = M/(62*1024) (avrundat uppåt), S = M/(1024*H) (avrundat uppåt), C = M/(H*S) (avrundat neråt). Detta ger en (C,H,S) med C högst 1024 och S högst 62. 7. Linux 8 GB-begränsning för IDE Linux IDE-drivrutin hämtar geometrin och hårddiskkapaciteten (och många andra saker) genom att använda ett ATA IDENTIFY-anrop. Tills nyligen trodde inte drivrutinen på det returnerade värdet från lba_capacity om det var mer än 10 % större än kapaciteten beräknad genom C*H*S. Nyare Quantum Bigfoot 12 GB-hårddiskar returnerar emellertid C=16383, H=16, S=63, vilket ger totalt 16514064 sektorer (7,8 GB) men rapporterar lba_capacity som 23547888 sektorer (det vill säga 11,2 GB, C=23361). Nyare Linuxkärnor (2.0.34pre14, 2.1.90) känner till detta och beter sig rätt. Om du har en äldre Linuxkärna och inte vill uppgradera, och kärnan bara ser 8 GB av en mycket större hårddisk, kan du testa att ändra rutinen lba_capacity_is_ok i /usr/src/linux/drivers/block/ide.c till någonting likt static int lba_capacity_is_ok (struct hd_driveid *id) { id->cyls = id->lba_capacity / (id->heads * id->sectors); return 1; } För en mer försiktig patch, se 2.1.90.