Verder Terug Inhoud

11. De Linux IDE 8 GiB limiet

De Linux IDE driver krijgt de geometrie en capaciteit van een disk (een veel andere zaken) door een ATA IDENTIFY verzoek te gebruiken. Tot voor kort zou de driver het niet geloven als de geretourneerde waarde van lba_capacity meer zou zijn dan 10% groter dan de capaciteit berekend door C*H*S. Echter, door een industrie overeenkomst retourneren grote IDE disks (met meer dan 16514064 sectoren) C=16383, H=16, S=63, voor een totaal van 16514064 sectoren (7.8 GB) onafhandelijk van hun eigenlijke grootte, maar geven hun eigenlijke grootte in lba_capacity.

Recente Linux kernels (2.0.34, 2.1.90) zijn hiermee bekend en doen het juist. Als je een oudere Linux kernel hebt en niet wilt upgraden, en deze kernel ziet slechts 8 GiB van een veel grotere disk, probeer dan de routine lba_capacity_is_ok in /usr/src/linux/drivers/block/ide.c te wijzingen in iets als

static int lba_capacity_is_ok (struct hd_driveid *id) {
        id->cyls = id->lba_capacity / (id->heads * id->sectors);
        return 1;
}
Zie 2.1.90 voor een omzichtiger patch.

11.1 BIOS complicaties

Zoals net aangegeven, retourneren grote disks de geometrie C=16383, H=16, S=63 onafhankelijk van de werkelijke grootte, terwijl de werkelijke grootte wordt geretourneerd in de waarde van LBAcapacity. Een aantal BIOSsen herkennen dit niet, en vertalen deze 16383/16/63 in iets met minder cylinders en meer heads, bijvoorbeeld 1024/255/63 of 1027/255/63. Dus, de kernel moet niet alleen de enkele geometrie 16383/16/63 herkennen, maar ook alle BIOS-verminkte versies ervan. Sinds 2.2.2 wordt dit correct gedaan (door het overnemen van het BIOS idee van H en S, en te berekenen C = capacity/(H*S)). Gewoonlijk wordt dit probleem opgelost door de disk in te stellen op Normal in de BIOS setup (of nog beter, op None, het in het geheel niet vermelden in de BIOS). Gebruik kernelbootparameters, als dat niet mogelijk is omdat je ervan moet booten of het ook met DOS/Windows gebruikt en upgraden naar 2.2.2 of later geen optie is.

Als een BIOS 16320/16/63 rapporteert, dan is dit meestal gedaan om na de vertaling 1024/255/63 te verkrijgen.

Hier is een extra probleem. Als de disk met behulp van een diskvertaling werd gepartioneerd, dan is het mogelijk dat de kernel tijdens de systeemstart in de partitietabel gebruikt ziet, en rapporteert hda: [PTBL] [1027/255/63]. Dit is niet goed, omdat de disk nu slechts 8.4 GB is. Dit werd in 2.3.21 hersteld. Nogmaals, kernelbootparameters zullen hierbij van hulp zijn.

11.2 Jumpers die het aantal heads selecteren

Op veel disks komen jumpers voor waarmee het mogelijk is dat je een keuze maakt uit een 15-head of een 16-head geometrie. De standaardinstellingen zullen je een 16-head disk geven. Soms adresseren beide geometries hetzelfde aantal sectoren, soms is de 15-head versie kleiner. Er kan een goede reden zijn voor deze setup: Petri Kaukasoina schrijft: `Een 10.1 Gig IBM Deskstar 16 GP (model IBM-DTTA-351010) was standaard via jumper ingesteld op 16 heads maar deze oude PC (met AMI BIOS) bootte niet en ik moest de jumper instellen voor 15 heads. hdparm -i zegt RawCHS=16383/15/63 en LBAsects=19807200. Ik gebruik 20960/15/63 om de volledige capaciteit te verkrijgen.' Voor de jumper instellingen, zie http://www.storage.ibm.com/techsup/hddtech/hddtech.htm.

11.3 Jumpers die de totale capaciteit afkappen

Veel disks hebben jumpers die je toestaan om de disk kleiner te doen lijken dan hij is. Een dom ding om te doen en waarschijnlijk wil geen enkele Linux-gebruiker dit ooit gebruiken, maar een aantal BIOS'sen lopen vast op grote disks. De gebruikelijke oplossing is om de disk volledig uit de BIOS-setup achterwege te laten. Maar dit is alleen uitvoerbaar als de disk niet je bootdisk is.

De eerste serieuze limiet was de 4096 cylinder limiet (dat wil zeggen, met 16 heads en 63 sectoren/spoor, 2.11 GB). Een Fujitsu MPB3032ATU 3.24 GB disk heeft bijvoorbeeld een standaardgeometrie van 6704/15/63, maar kan worden gejumperd dat het een 4092/16/63 lijkt, en het rapporteert vervolgens een LBA-capaciteit van 4124736 sectoren, zodat het besturingssysteem niet kan raden dat het in werkelijkheid groter is. In een dergelijke situatie (met een BIOS dat crasht als het hoort hoe groot de disk in werkelijkheid is, waardoor de jumper is vereist) heeft men bootparameters nodig om Linux de grootte van de disk te vertellen.

Dat is jammer. De meeste disks kunnen nu zo worden gejumperd dat ze als een 2 GB disk verschijnen en dan een vastgestelde geometrie als 4092/16/63 of 4096/16/63 rapporteren, maar nog steeds de volledige LBA-capaciteit rapporteren. Dergelijke disks werken goed, en ze gebruiken onder Linux ongeacht de jumperinstellingen de volledige capaciteit.

Een recentere beperking is de 33.8 GB limiet. Linux heeft nog steeds een patch nodig om met IDE-disks groter dan dit om te kunnen gaan. Een aantal disks groter dan deze limiet kunnen zodanig worden gejumperd dat het een 33.8 GB disk lijkt. De IBM Deskstar 37.5 GB (DPTA-353750) met 73261440 sectoren (corresponderend met 72680/16/63, of 4560/255/63) kan bijvoorbeeld zo worden gejumperd dat het een 33.8 GB disk lijkt, en het rapporteert dan net als iedere grote disk een geometrie van 65531/16/63, maar een LBA-capaciteit van 66055248 (overeenkomstig met 65531/16/63 of 4111/255/633). Helaas schijnt de jumper te effectief te zijn - het heeft niet alleen invloed op wat de drive aan het systeem rapporteert, maar het heeft ook invloed op de feitelijke I/O: Petr Soucek rapporteert dat bepaalde bootparameters voor deze disk niet helpen - met de aanwezige jumper geeft iedere benadering tot sector 66055248 of meer een I/O-fout. Dus op een moederbord met Award 4.51PG BIOS, kan men deze disk niet als bootdisk en gebruiken en ook de volledige capaciteit niet benutten. Zie ook de BIOS 33.* GB limiet.

Een andere grote disk is de 40 GB Maxtor. Mensen rapporteren dat met een oude BIOS en een dergelijke disk, de BIOS tijdens de systeemstart zal blijven hangen, zelfs wanneer de disk uit de CMOS-instellingen is verwijderd, en in een aantal gevallen zelfs wanneer de J46 jumper die de capaciteit beperkt tot 32 GB aanwezig is. In dergelijke gevallen is de beste oplossing aan een BIOS-upgrade te komen. Maxtor voorziet ook in een utility (htmlurl url="http://www.maxtor.com/technology/tecnotes/20012.html" name="JUMPON.EXE"> waarmee de grootte van de disk volledig wordt verborgen en in combinatie met MaXBlast software kan worden gebruikt. Ik heb geen informatie over of (en hoe) een disk behandeld met JUMPON.EXE tot zijn volledige capaciteit onder Linux kan worden gebruikt.


Verder Terug Inhoud