Warning: number of bytes per sector mismatches 512 (NTFS) != 4096 (HD)

[Mikael63 3 148]

I denna tråd hade jag problem med en disk, med samma meddelande - enligt rubrik - i programmet Testdisk.

I den tråden kunde jag ändra till 512 och välja Write (som återfinns på ett annat ställe i programmet) och detta medförde att disken fungerade igen.

 

Nu har jag en annan disk som ger samma meddelande men där hjälper inte åtgärden att ändra.

När jag googlar så tycks det ligga till på det viset att man bara ändrar detta "inuti" programmet Testdisk för att det programmet ska kunna hantera disken på rätt sätt.

Alltså att inget skrivs till disken.

Kan acceptera att så är fallet men varför fungerade det då, bevisligen, med min förra disk?

Testdisk kan lista innehållet på disken korrekt och jag kan kopiera undan de filer som behöver räddas, vilket är gjort.

Behöver nu "bara" rätta till disken så att operativet kan läsa innehållet, på samma sätt som Testdisk gör.

 

I första hand behöver jag hjälp med åtgärder från Linuxmiljön men det fungerar även i Windowsmiljö.

Slänger in några bilder som jag hoppas visas i rätt ordning.

Den första bilden visar felmeddelandet, den näst sista visar hur det ser ut efter att ha ändrat till 512.

 

 

Redigerad 10 september, 2018 av Mikael63

[jannejanne 329]

Jag hade med diskproblem börjat med att kontrollera hårddisken med hårddisktillverkarens testprogram.

För varför lägga tid på en hårddisk med skador ?

Blir resultatet dåligt har jag på tiden med PATA diskar råkat ut för att det var PATA kabeln som var kass och genom att byta till en annan PATA kabel få testprogrammet att visa att disken var OK.

Jag hade råkat ut för en dålig / långsam PATA-kabel.

[Mikael63 3 148]

1 timme sedan, skrev jannejanne:

För varför lägga tid på en hårddisk med skador ?

I rent utbildningssyfte.

[Flyfisherman 2 060]

Hej,

Jag förstår inte.

Det är åt rätt håll.

 

Men se detta: Superuser:  How to correct 512-byte sector MBR on a 4096-byte sector disk?

 

Men kör du med SSD bör du också se till att den är i 4K-aligngment för maximal prestanda:

AOMEI:   How to Check and Run SSD Alignment in Windows 10?

Eller

hardware.info How-to: copy HDD to SSD with correct 4k alignment

Mvh

 

[Edit]

I Windows alla versioner från Microsoft Vista (4k aligngment) samt alla modena versioner av Linux enkelt att kontrollera:

Start > kör > i rutan som kommer upp skriv msinfo32  (eller Systeminformation) > klicka  Systeminformation > I Systeminformation leta efter den eller dessa SSD du har och sök efter:

"Partitionen börjar vid"  detta sk. start offset nummer skall divideras med 4096 och blir slutsumman ett jämt tal så är disken eller partitionen 4k-aligngned.

allt annat betyder att disken inte är 4k aligned och har därmed sämre prestanda.

 

Tex. på min ena står det: 1048576 och jag dividerar detta med 4096= 256 lika med 4K alignment.

 

Man kan även testa på sin hårddisk och den bör vara detta på alla modena operativsystem, men i synnerhet på en SSD.

 

• Windows XP stöder inte av sig själv 4K alignment., därav sämre prestanda med SSD på en Windows XP maskin, även om den fungerar klanderfritt.

 

Ni kan också använda denna Linux tabell: https://docs.google.com/spreadsheets/d/1dnDlhglxxgApvtUv0-

nxn1iFYTqkjRELqCOWJtp3hbs/edit#gid=0

För Linux gäller samma sak naturligtvis.

 

 

[Mikael63 3 148]

Mycket intressant läsning (Superuser).

Det enkla, korta svaret skulle då bli att använda fdisk för att korrigera felet?

 

Jag har startat fdisk några gånger men blivit lite osäker på handhavandet.

Får testa med cfdisk senare som ska vara mer användarvänlig.

Dock får det bli på någon annan disk då både disken i denna tråd och i den andra tråden är återanvända och fungerar helt okej nu.

 

[Flyfisherman 2 060]

Har du fått till det?

[Mikael63 3 148]

14 timmar sedan, skrev Flyfisherman:

Har du fått till det?

 

Nej!

 

Jag tog en annan disk att testa med. Ansluter den via USB-adapter, monteras automatiskt. Kopierar in en igenkänningsbar fil.

Testdisk hittar inget fel, sektorstorleken anges till 512. (och i detta läger ska ju inget fel hittas då den fungerar)

Kollar med programmet cfdisk. Hittar inget att kunna ändra denna storlek. Jag behöver ju forcera fram felet för att sedan kunna reparera.

Dock är cfdisk kanska lättanvänt bara man vet hur man ska skriva i terminalen för att starta upp:

sudo cfdisk /dev/sdb

Testar då med det lite krångligare fdisk.

Klurar ut att jag kan skriva sudo fdisk -b 4096 /dev/sdb

och därefter w

Något tycks hända eftersom disken nu inte monteras,

Prövar då Testdisk i hopp om att samma fel, enligt rubrik, ska synas men icke. Testdisk tycker inte att det är något fel på disken.

Jo, den klagar på att den inte är boot-bar men flagga för boot är satt.

GParted anger att filsystemet är okänt men GParted är enligt mig det mest opålitliga programmet i denna kategori.

Diskar (programmet heter så) anger att partitionstypen är  NTFS/exFAT/HPFS (startbar) men innehållet är okänt.

 

 

 

Redigerad 29 september, 2018 av Mikael63

[Flyfisherman 2 060]

Något har tydligen gått snett i ändring från 512 bytes sector till 4096 sector storlek., vilket normalt skall gå att utföra på rätt sätt utan att förlora data och utan att den sk. Aktiva start partitionen ändras så den inte bootar.

 

• En disk från början måste partitioneras om och därefter formateras för att automatiskt få 4k alignment, det räcker alltså inte med att bara formatera om.

 

Men om vi backar tillbaks så kanske det inte är detta som är rot-orsaken, för även om den har 512 byte sector storlek skall naturligtvis disken fungera utan mankemang.

Hmm...funderar..

 

 

 

 

[Flyfisherman 2 060]

Men den måste fortfarande ha ett jämt delbart tal med antingen 512 eller 4096 från start offset och har den inte det så är något galet med partitioneringen från början alt. att disken är skadad och inte kan läsas av korrekt.

[Flyfisherman 2 060]

Och du har bara en disk inkopplad som den skall boota upp från och sedan starta operativsystemet?

För har du fler än en och den disk som operativsystemet ligger på och är installerad från början på, så måste den vara inkopplad på första SATA-porten på moderkortet, annars kommer per automatik den disk som är ansluten före i SATA-port kedjan att på denna kommer start eller boot partitionen att läggas på, även om operativsystemet i sig självt ligger på en disk ansluten på annan SATA-port. I så fall spelar det mindre roll var Start offset ligger för att det skall fungera, dock ej optimalt om inte detta är jämnt delbart med 4096 (ger annars kraftig försämring av diskens prestanda).

 

Om så är fallet måste man i BIOS Setup ändra Boot prioritet till just den disken och inte den disken som operativsystemet är installerat på, fast det har ingenting med sectorstorlek att göra.

Det är därför jag brukar rekommendera att vid ny-installation av operativsystem endast ha en disk inkopplad (för att minimera framtida krångel) då läggs allt på samma disk.

Det gäller både Linux och Windows.

Men detta går enkelt att korrigera i efterhand via gratis verktyg tex. https://www.easeus.com/partition-manager/epm-free.html

 

 

[Edit] Uppdaterat med start offset i första stycket.

Redigerad 29 september, 2018 av Flyfisherman

[Mikael63 3 148]

Det här är en disk som inte behöver kunna starta med något operativ på!

Så har också varit fallet med de två "skarpa diskarna" även fast just dessa var den enda disken, med operativsystemet på.

 

Den "första", den som suttit i en dator där åskan hälsat på, var egentligen dödförklarad redan från början.

Men eftersom programmet Testdisk utan vidare kunde lista alla mappar/filer och även kopiera undan dessa skulle det ha varit smidigt om man kunde reparera det som gått snett, det som medförde att ett operativsystem inte kunde läsa innehållet på ett "vettigt" sätt.

Denna verkade ju ha slitit till sig efter att enbart Testdisk varit inblandad.

 

Den "andra", den som denna tråd handlar om, gick det inte att starta Windows med. Den hade redan tidigare flaggat för en del fel, startat om sig osv. Testdisk kunde även med denna lista innehållet och kopiera undan filer.

Även här hade det varit smidigt om man kunde reparera det som gått snett, det som medförde att ett operativsystem inte kunde läsa innehållet på ett "vettigt" sätt. Den hade alltså inte behövt bli startbar.

 

Den "tredje" disken är en gammal disk jag nu använder enbart som utbildningsmaterial för att lära mig lite mer om detta.

 

[Flyfisherman 2 060]

Ja Testdisk är ett av dom bästa gratisverktygen enligt tester jag läst på om och säger den att allt a-ok så blir jag brydd.

Har tyvärr inga fler tips att komma med såvida inte något jag redan skrivit ovan kan appliceras på någon av dina diskar? Där kommer förvisso nog Testdisk fortfarande att säga ok på nån eller alla, så dra inte för stora växlar på detta.

Mvh

[Mikael63 3 148]

Gillar inte (litar inte på) GParted men den har ju ett bra grafiskt gränssnitt.

Där finns något som heter "Försök att rädda data..."

Väljer jag detta varnas om att det kan ta lång tid. Tar 3 sekunder.

Hittar data som består av min lilla inkopierade fil.

Disken är således inte helt fördärvad, eftersom programmen GParted och Testdisk kommer åt innehållet.

Varför ska det då vara så svårt för operativsystemet, just nu Linux, att kunna montera disken så att samma fil blir åtkomlig via en filhanterare?

 

Okej, jag tragglar på lite med Testdisk igen...

 

 

[Mikael63 3 148]

3 minuter sedan, skrev Mikael63:

Okej, jag tragglar på lite med Testdisk igen...

 

Jaha...

"Ändrade" åter typ till 07 NTFS, vilket det ju redan var sedan tidigare, sedan Write och omstart av såväl power som USB.

Monteras direkt, min fil finns där. 

GParted visar dock en liten knepig uppsättning partitioner:

 

[Mikael63 3 148]

Problem med XP i virtuell miljö.

Startar inte.

Testdisk anger

Warning: Number of sectors per track mismatches 56 (NTFS) != 63 (HD)

I detta läge lite oklart om det är 56 eller 63 som är det felande värdet.

Startar då i stället fdisk och ändrar detta (där anges 63 vara standard), först till 56 och sedan till 63.

Kollar med Testdisk mellan varje ändring men den anger samma "mismatch".

Så.. fdisk lyckades inte ändra på detta.

Åter till Testdisk där jag valde "rebuild BS" (något som skulle ta evennerlig tid i min andra tråd) och något fixades på direkten. Testdisk bråkar inte och XP startar up.

 

Tråden kan ändå inte anses vara löst då jag inte vet vad som meddelandet angav och varför.

Inte heller vad åtgärden egentligen gjorde.