Hi Ich konnte es nicht lassen und habe SuSE 9.2 installiert. Es gibt verschiedene logical Volumes mit reiserfs für /usr /var /home /opt. Aus irgendeinem Grund dauert das "replaying journal" der verschiedenen Volumes beim Hochfahren jetzt ziemlich lange (ca. 30-60 Sekunden pro Volume). Es dauert auf jeden Fall auffallend länger als bei der vorigen SuSE Die Geschwindigkeit, die hdparm -rt liefert (auf ein logical Volume losgelassen), liegt bei über 20 MB/s. Das kann es eigentlich nicht sein. hdparm /dev/hda liefert /dev/hda: multcount = 16 (on) IO_support = 0 (default 16-bit) unmaskirq = 0 (off) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 256 (on) geometry = 65535/16/63, sectors = 120060444672, start = 0 Woran kann das nun noch liegen? mfg Axel
Hallo, Am Fri, 11 Feb 2005, Axel Heinrici schrieb:
hdparm /dev/hda liefert
/dev/hda: multcount = 16 (on) IO_support = 0 (default 16-bit) unmaskirq = 0 (off) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 256 (on) geometry = 65535/16/63, sectors = 120060444672, start = 0
Woran kann das nun noch liegen?
Die Geometrie stimmt nicht. Es sei denn, du hast eine 57249 GB Festplatte. Was sagt 'hdparm -iI /dev/hda'? Was spuckt 'cat /proc/ide/hda/geometry' aus? Wie ist die Geometrie im BIOS eingestellt? Mit welcher Geometrie hast du partitioniert? */16/63 oder anders? Ansonsten: man hdparm. hdparm -c1 -d1 -k1 /dev/hda -dnh --
Inhalte der Schulung: MS Office, Schreiben auf der Tastatur, ACCESS/Datenbanken, Internet ^^^^^^^^^^^^^^^^^^^^^^^^^^ mit Edding? [Cord Beermann in dasr]
On Friday 11 February 2005 17:07, David Haller wrote:
Hallo,
Am Fri, 11 Feb 2005, Axel Heinrici schrieb:
hdparm /dev/hda liefert
/dev/hda: multcount = 16 (on) IO_support = 0 (default 16-bit) unmaskirq = 0 (off) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 256 (on) geometry = 65535/16/63, sectors = 120060444672, start = 0
Woran kann das nun noch liegen?
Die Geometrie stimmt nicht. Es sei denn, du hast eine 57249 GB Festplatte. So eine große Platte habe ich leider nicht. Das sieht mir aber auch eher wie einen Macke in der Ausgabe von hdparm aus. Denn die Zahl enspricht exakt der Größe der Platte in Byte, die fdisk anzeigt.
Was sagt 'hdparm -iI /dev/hda'? Model=SAMSUNG SV1204H, FwRev=RK100-12, SerialNo=0527J1ETA15135 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs } RawCHS=16383/16/63, TrkSize=34902, SectSize=554, ECCbytes=4 BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=234493056 IORDY=yes, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120} PIO modes: pio0 pio1 pio2 pio3 pio4 DMA modes: mdma0 mdma1 mdma2 UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 AdvancedPM=no WriteCache=enabled Drive conforms to: ATA/ATAPI-6 T13 1410D revision 1:
Was spuckt 'cat /proc/ide/hda/geometry' aus? # cat /proc/ide/hda/geometry
* signifies the current active mode ATA device, with non-removable media Model Number: SAMSUNG SV1204H Serial Number: 0527J1ETA15135 Firmware Revision: RK100-12 Standards: Used: ATA/ATAPI-6 T13 1410D revision 1 Supported: 6 5 4 3 Configuration: Logical max current cylinders 16383 16383 heads 16 16 sectors/track 63 63 -- CHS current addressable sectors: 16514064 LBA user addressable sectors: 234493056 device size with M = 1024*1024: 114498 MBytes device size with M = 1000*1000: 120060 MBytes (120 GB) Capabilities: LBA, IORDY(cannot be disabled) bytes avail on r/w long: 4 Queue depth: 1 Standby timer values: spec'd by Standard, no device specific minimum R/W multiple sector transfer: Max = 16 Current = 16 Recommended acoustic management value: 128, current value: 254 DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 Cycle time: min=120ns recommended=120ns PIO: pio0 pio1 pio2 pio3 pio4 Cycle time: no flow control=120ns IORDY flow control=120ns Commands/features: Enabled Supported: * READ BUFFER cmd * WRITE BUFFER cmd * Host Protected Area feature set * Look-ahead * Write cache * Power Management feature set Security Mode feature set SMART feature set * Mandatory FLUSH CACHE command * Automatic Acoustic Management feature set SET MAX security extension * DOWNLOAD MICROCODE cmd * SMART self-test * SMART error logging Security: Master password revision code = 65534 supported not enabled not locked not frozen not expired: security count supported: enhanced erase 136min for SECURITY ERASE UNIT. 136min for ENHANCED SECURITY ERASE UNIT. HW reset results: CBLID- above Vih Device num = 0 determined by the jumper physical 16383/16/63 logical 65535/16/63
Wie ist die Geometrie im BIOS eingestellt?
Das weiß ich ehrlich gesagt nicht. Jedenfalls steht die Verlangsamung beim check (oder journal-replay) in eindeutigem Zusammenhang mit dem Update von 9.1 auf 9.2. An den Bios Einstellungen habe ich dabei aber nix geändert. Daher habe ich so etwas als Ursache erstmal ausgeschlossen. Außerdem läuft das System ja einwandwandfrei. Und die Performance im normalen Betrieb scheint auch ok zu sein. Nur beim booten trödelt das System erstmal minutenlang mit den Dateisystemen rum.
Mit welcher Geometrie hast du partitioniert? */16/63 oder anders?
Du kannst Sachen fragen..... Ich habe mich da ehrlich gesagt auf YaST verlassen. War ja auch bisher kein Problem. Sagt das etwas über diese Frage aus? # fdisk -lu /dev/hda Platte /dev/hda: 120.0 GByte, 120060444672 Byte 255 Köpfe, 63 Sektoren/Spuren, 14596 Zylinder, zusammen 234493056 Sektoren Einheiten = Sektoren von 1 × 512 = 512 Bytes Gerät boot. Anfang Ende Blöcke Id System /dev/hda1 * 63 15358139 7679038+ c W95 FAT32 (LBA) /dev/hda2 15358140 234468674 109555267+ f W95 Erw. (LBA) /dev/hda5 15358203 36339029 10490413+ c W95 FAT32 (LBA) /dev/hda6 36339093 88775189 26218048+ c W95 FAT32 (LBA) /dev/hda7 88775253 90879704 1052226 82 Linux swap / Solaris /dev/hda8 90879768 95088734 2104483+ 83 Linux /dev/hda9 95088798 234468674 69689938+ 8e Linux LVM
Ansonsten: man hdparm. hdparm -c1 -d1 -k1 /dev/hda
Das hilft mir doch aber beim booten recht wenig, oder nicht? Ich hätte jetzt rein von den Symptomen her eher auf sowas getippt wie "während des bootens noch kein DMA aktiv", oder so. mfg Axel
Hallo, Am Mon, 14 Feb 2005, Axel Heinrici schrieb:
On Friday 11 February 2005 17:07, David Haller wrote:
Hallo,
Am Fri, 11 Feb 2005, Axel Heinrici schrieb:
hdparm /dev/hda liefert
/dev/hda: multcount = 16 (on) IO_support = 0 (default 16-bit) unmaskirq = 0 (off) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 256 (on) geometry = 65535/16/63, sectors = 120060444672, start = 0
Woran kann das nun noch liegen?
Die Geometrie stimmt nicht. Es sei denn, du hast eine 57249 GB Festplatte. So eine große Platte habe ich leider nicht. Das sieht mir aber auch eher wie einen Macke in der Ausgabe von hdparm aus. Denn die Zahl enspricht exakt der Größe der Platte in Byte, die fdisk anzeigt.
Darf eigentlich nicht sein.
Was sagt 'hdparm -iI /dev/hda'? [..] [..] Was spuckt 'cat /proc/ide/hda/geometry' aus? # cat /proc/ide/hda/geometry physical 16383/16/63 logical 65535/16/63
Wie ist die Geometrie im BIOS eingestellt?
Das weiß ich ehrlich gesagt nicht.
Dann schau nach ;)
Jedenfalls steht die Verlangsamung beim check (oder journal-replay) in eindeutigem Zusammenhang mit dem Update von 9.1 auf 9.2. An den Bios Einstellungen habe ich dabei aber nix geändert.
Ok.
Mit welcher Geometrie hast du partitioniert? */16/63 oder anders?
Du kannst Sachen fragen..... Ich habe mich da ehrlich gesagt auf YaST verlassen. War ja auch bisher kein Problem. Sagt das etwas über diese Frage aus?
# fdisk -lu /dev/hda
Platte /dev/hda: 120.0 GByte, 120060444672 Byte 255 Köpfe, 63 Sektoren/Spuren, 14596 Zylinder, zusammen 234493056 Sektoren Einheiten = Sektoren von 1 × 512 = 512 Bytes
Ja. Die Platte scheint eben nicht mit */16/63 sondern mit */255/63 partitioniert zu sein. Und wenn du die jetzt mit */16/63 ansprichst kann das genau dein Problem verursachen (ich hatte das auch mal als ich ne */255/63 er Platte an nen Promise gehaengt habe, der nur */16/63 macht... Zur Sicherheit solltest du noch in /proc/ide/hda/settings schauen (z.B. bios_{cyl,head,sect} und v.a. in die Partitionstabelle des MBR schauen: dd if=/dev/hda bs=1 skip=446 count=66 | od -t x1 Da muesste sowas bei rauskommen: 0000000 00 01 01 00 83 fe 3f 0c 3f 00 00 00 8e 2f 03 00 0000020 00 00 01 0d 82 fe 3f 4e cd 2f 03 00 c2 2d 10 00 0000040 00 00 01 4f 0f fe ff ff 8f 5d 13 00 32 2d 8e 12 0000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000100 55 aa und aus ^^dieser Spalte kann man die Kopfzahl ablesen. Zumindest wenn die CHS-Werte eingetragen sind. Was bei Festplatten < 127 GB immer der Fall sein sollte (LBA 28bit, nicht LBA 48bit). Ich weiss jetzt aber leider nicht mehr, ob der 48bit Modus schon in ATA-6 spezifiziert wurde. -dnh -- It would have been better for source code control to post our source code to comp.sources.unix and retrieve the versions using groups.google.com than to put it into that bletcherous piece of crap. -- Paul Tomblin on Visual Source Safe
On Monday 14 February 2005 13:20, David Haller wrote:
Hallo,
Am Mon, 14 Feb 2005, Axel Heinrici schrieb:
On Friday 11 February 2005 17:07, David Haller wrote:
Was sagt 'hdparm -iI /dev/hda'?
[..] [..]
Was spuckt 'cat /proc/ide/hda/geometry' aus?
# cat /proc/ide/hda/geometry physical 16383/16/63 logical 65535/16/63
Wie ist die Geometrie im BIOS eingestellt?
Das weiß ich ehrlich gesagt nicht.
Dann schau nach ;)
Okay. im Bios steht cyl 57473 head 16 sector 255
Jedenfalls steht die Verlangsamung beim check (oder journal-replay) in eindeutigem Zusammenhang mit dem Update von 9.1 auf 9.2. An den Bios Einstellungen habe ich dabei aber nix geändert.
Ok.
Mit welcher Geometrie hast du partitioniert? */16/63 oder anders?
Du kannst Sachen fragen..... Ich habe mich da ehrlich gesagt auf YaST verlassen. War ja auch bisher kein Problem. Sagt das etwas über diese Frage aus?
# fdisk -lu /dev/hda
Platte /dev/hda: 120.0 GByte, 120060444672 Byte 255 Köpfe, 63 Sektoren/Spuren, 14596 Zylinder, zusammen 234493056 Sektoren Einheiten = Sektoren von 1 × 512 = 512 Bytes
Ja. Die Platte scheint eben nicht mit */16/63 sondern mit */255/63 partitioniert zu sein. Und wenn du die jetzt mit */16/63 ansprichst kann das genau dein Problem verursachen (ich hatte das auch mal als ich ne */255/63 er Platte an nen Promise gehaengt habe, der nur */16/63 macht...
Zur Sicherheit solltest du noch in /proc/ide/hda/settings schauen (z.B. bios_{cyl,head,sect} und v.a. in die Partitionstabelle des MBR schauen:
# dd if=/dev/hda bs=1 skip=446 count=66 | od -t x1 66+0 Datensätze ein 66+0 Datensätze aus 0000000 80 01 01 00 0c fe ff bb 3f 00 00 00 7d 58 ea 00 0000020 00 00 c1 bc 0f fe ff ff bc 58 ea 00 87 5c 0f 0d 0000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ^^ das "fe" in der obersten Zeile ist dann der head-Wert von hda, richtig? # cat /proc/ide/hda/settings |grep bios bios_cyl 65535 0 65535 rw bios_head 16 0 255 rw bios_sect 63 0 63 rw Versteh ich jetzt irgendwie nicht so ganz. Im BIOS-setup stehen die oben angegebenen Werte, die tatsächlich nicht mit den "/proc -Werten" übereinstimmen. Auch sonst scheint es mir als wiedersprächen die head-Werte in der Partionierungstabelle Sowohl den Werten im BIOS-setup als auch denen in /proc. Die Platte hing allerdings noch nie an einem anderen controller als dem jetztigen. Die Werte im BIOS setup stammen auch noch von eine Auto-detection von vor ca. 2Jahren als der Rechner zusammengeschreubt wurde (Die standen da auch schon drin als die letzte SuSE installiert wurde). Nichts desto weniger hat das Eintragen des services boot.lvm in die Required-Zeile (Hinweis von Rüdiger) von boot.hotplug das Problem beseitigt. Die Zusammenhänge von (Pseudo-)Geometriedaten, Adressierungsart und BIOS- bzw. /proc-Werten wird mir zwar immer unklarer, aber der filesystemcheck beim booten ist wieder wieder normal schnell... ca. um Faktor 10 schneller als beim vorletzten booten. mfg Axel
Hallo, Am Tue, 15 Feb 2005, Axel Heinrici schrieb:
On Monday 14 February 2005 13:20, David Haller wrote:
Am Mon, 14 Feb 2005, Axel Heinrici schrieb:
On Friday 11 February 2005 17:07, David Haller wrote: [..]
Wie ist die Geometrie im BIOS eingestellt?
Das weiß ich ehrlich gesagt nicht.
Dann schau nach ;)
Okay. im Bios steht cyl 57473 head 16 sector 255
Hm. 255 Sektoren/Kopf gehen eigentlich nicht. Das wuerde aber immerhin passen, das sind 120058798080 Byte. Aber mit nur 6 bit fuer die Sektoren passt das eben nicht. [..]
Mit welcher Geometrie hast du partitioniert? */16/63 oder anders? [..] Zur Sicherheit solltest du noch in /proc/ide/hda/settings schauen (z.B. bios_{cyl,head,sect} und v.a. in die Partitionstabelle des MBR schauen:
# dd if=/dev/hda bs=1 skip=446 count=66 | od -t x1 66+0 Datensätze ein 66+0 Datensätze aus 0000000 80 01 01 00 0c fe ff bb 3f 00 00 00 7d 58 ea 00 0000020 00 00 c1 bc 0f fe ff ff bc 58 ea 00 87 5c 0f 0d 0000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
^^ das "fe" in der obersten Zeile ist dann der head-Wert von hda, richtig?
Jep. Die Platte ist also mit */255/63 partitioniert. Das */*/63 kannst du indirekt in der Folgespalte ablesen. Das naechste Byte sind die unteren 8 bit der Zylindernummer und die dann folgenden 4 ablesen sind der Startsektor (LBA start). Das ff sind die oberen 2bit vom Cyl. (11) und 6bit Sektoren => 63 Sektoren. Und der Anfang der Partition ist (die 4 Spalten in little endian): 0x0000003f => 63. Die restlichen 4 Byte des Eintrags (eine Zeile) ist die Laenge der Partition: 0x00ea587d Sektoren.
# cat /proc/ide/hda/settings |grep bios bios_cyl 65535 0 65535 bios_head 16 0 255 bios_sect 63 0 63
Versteh ich jetzt irgendwie nicht so ganz. Im BIOS-setup stehen die oben angegebenen Werte, die tatsächlich nicht mit den "/proc -Werten" übereinstimmen.
s.o. Vgl. das '63' in der Spalte 'max' bei bios_sect!
Auch sonst scheint es mir als wiedersprächen die head-Werte in der Partionierungstabelle Sowohl den Werten im BIOS-setup als auch denen in /proc. Die Platte hing allerdings noch nie an einem anderen controller als dem jetztigen. Die Werte im BIOS setup stammen auch noch von eine Auto-detection von vor ca. 2Jahren als der Rechner zusammengeschreubt wurde (Die standen da auch schon drin als die letzte SuSE installiert wurde).
Ich mag autodetection nicht, wenn sie nicht LBA */255/63 ergibt :)
Die Zusammenhänge von (Pseudo-)Geometriedaten, Adressierungsart und BIOS- bzw. /proc-Werten wird mir zwar immer unklarer, aber der filesystemcheck beim booten ist wieder wieder normal schnell... ca. um Faktor 10 schneller als beim vorletzten booten.
Es _kann_ trotzdem noch Aerger geben. Abhilfe waere: Stell im Bios die
richtige Groesse ein indem du 'LBA' vorgibst. Dann muessten
14596/255/63 Cylinder/Heads/Sectors rauskommen (siehe 'fdisk -l'
Ausgabe).
Anschliessend kannst du ggfs. auch dem Kernel die richtige Geometrie
sagen: 'hda=14596,255,63' als Kernelparameter.
Du hast uebrigens bisher nur keinen Datenverlust, weil die Partitionen
ueber LBA angesprochen werden dann die Geometrie in Grenzen egal
ist. Aber lass auf jeden Fall die Finger vom DOS/Win9x/WinME
fdisk.
Wg. den Zusammenhaengen habe ich grad keine Lust, sorry.
-dnh
--
"Being disintegrated makes me ve-ry an-gry!"
Hi On Tuesday 15 February 2005 12:05, David Haller wrote:
Hallo,
Am Tue, 15 Feb 2005, Axel Heinrici schrieb:
On Monday 14 February 2005 13:20, David Haller wrote:
Dann schau nach ;)
Okay. im Bios steht cyl 57473 head 16 sector 255
Hm. 255 Sektoren/Kopf gehen eigentlich nicht. Das wuerde aber immerhin passen, das sind 120058798080 Byte. Aber mit nur 6 bit fuer die Sektoren passt das eben nicht.
Ich habe gerade nochmal gebootet und geschaut. In Auto-Einstellung, die der CHS-Eionstellung entspricht, behauptet das Bios "Sector 255". Die Werte lassen sich bei erkannter Festplatte auch nicht verstellen sondern nur die Adressierungsart. Bei Einstellung LBA stellt steht dann da cyl 14596 head 255 Sector 63.
Auch sonst scheint es mir als wiedersprächen die head-Werte in der Partionierungstabelle Sowohl den Werten im BIOS-setup als auch denen in /proc. Die Platte hing allerdings noch nie an einem anderen controller als dem jetztigen. Die Werte im BIOS setup stammen auch noch von eine Auto-detection von vor ca. 2Jahren als der Rechner zusammengeschreubt wurde (Die standen da auch schon drin als die letzte SuSE installiert wurde).
Ich mag autodetection nicht, wenn sie nicht LBA */255/63 ergibt :)
Die Zusammenhänge von (Pseudo-)Geometriedaten, Adressierungsart und BIOS- bzw. /proc-Werten wird mir zwar immer unklarer, aber der filesystemcheck beim booten ist wieder wieder normal schnell... ca. um Faktor 10 schneller als beim vorletzten booten.
Es _kann_ trotzdem noch Aerger geben. Abhilfe waere: Stell im Bios die richtige Groesse ein indem du 'LBA' vorgibst. Dann muessten 14596/255/63 Cylinder/Heads/Sectors rauskommen (siehe 'fdisk -l' Ausgabe).
Hab ich gemacht.
Anschliessend kannst du ggfs. auch dem Kernel die richtige Geometrie sagen: 'hda=14596,255,63' als Kernelparameter.
Kurzen Versuch gemacht. Ohne den Kernelparameter steht in /proc/ide/hda/geometry immernoch physical 16383/16/63 logical 65535/16/63 Auch in /proc/ide/hda/settings bei den bios_cyl/head/sect Werten steht dann 65535/16/63 obwohl im Bios-Setup LBA und 14596/255/63 eingetragen ist. Mit dem Kernelparameter sieht dann alles irgendwie konsitenter aus.
Du hast uebrigens bisher nur keinen Datenverlust, weil die Partitionen ueber LBA angesprochen werden dann die Geometrie in Grenzen egal ist. Aber lass auf jeden Fall die Finger vom DOS/Win9x/WinME fdisk.
Den fasse ich sowieso seit Jahren nicht mehr an.
Wg. den Zusammenhaengen habe ich grad keine Lust, sorry.
Schon okay. Danke erstmal. Aber ein Frage vielleicht doch noch :-) Eilt ja auch nicht mit der Antwort. Was bewirken eingentlich die BIOS-Einstellungen, wenn ich diese Werte anschließend nirgendwo in /proc/ide/hda wiederfinde? Ignoriert der Kernel die einfach grundsätzlich? mfg Axel
Hallo, Am Wed, 16 Feb 2005, Axel Heinrici schrieb:
On Tuesday 15 February 2005 12:05, David Haller wrote:
Am Tue, 15 Feb 2005, Axel Heinrici schrieb:
On Monday 14 February 2005 13:20, David Haller wrote:
Dann schau nach ;)
Okay. im Bios steht cyl 57473 head 16 sector 255
Hm. 255 Sektoren/Kopf gehen eigentlich nicht. Das wuerde aber immerhin passen, das sind 120058798080 Byte. Aber mit nur 6 bit fuer die Sektoren passt das eben nicht.
Ich habe gerade nochmal gebootet und geschaut. In Auto-Einstellung, die der CHS-Eionstellung entspricht, behauptet das Bios "Sector 255". Die Werte lassen sich bei erkannter Festplatte auch nicht verstellen sondern nur die Adressierungsart.
Hrmpf.
Bei Einstellung LBA stellt steht dann da cyl 14596 head 255 Sector 63.
Gut. [..]
Die Zusammenhänge von (Pseudo-)Geometriedaten, Adressierungsart und BIOS- bzw. /proc-Werten wird mir zwar immer unklarer, aber der filesystemcheck beim booten ist wieder wieder normal schnell... ca. um Faktor 10 schneller als beim vorletzten booten.
Es _kann_ trotzdem noch Aerger geben. Abhilfe waere: Stell im Bios die richtige Groesse ein indem du 'LBA' vorgibst. Dann muessten 14596/255/63 Cylinder/Heads/Sectors rauskommen (siehe 'fdisk -l' Ausgabe).
Hab ich gemacht.
*g*
Anschliessend kannst du ggfs. auch dem Kernel die richtige Geometrie sagen: 'hda=14596,255,63' als Kernelparameter.
Kurzen Versuch gemacht. Ohne den Kernelparameter steht in /proc/ide/hda/geometry immernoch physical 16383/16/63 logical 65535/16/63 Auch in /proc/ide/hda/settings bei den bios_cyl/head/sect Werten steht dann 65535/16/63 obwohl im Bios-Setup LBA und 14596/255/63 eingetragen ist. Mit dem Kernelparameter sieht dann alles irgendwie konsitenter aus.
*g*
Du hast uebrigens bisher nur keinen Datenverlust, weil die Partitionen ueber LBA angesprochen werden dann die Geometrie in Grenzen egal ist. Aber lass auf jeden Fall die Finger vom DOS/Win9x/WinME fdisk.
Den fasse ich sowieso seit Jahren nicht mehr an.
Gut so.
Wg. den Zusammenhaengen habe ich grad keine Lust, sorry.
Schon okay. Danke erstmal. Aber ein Frage vielleicht doch noch :-) Eilt ja auch nicht mit der Antwort.
Was bewirken eingentlich die BIOS-Einstellungen, wenn ich diese Werte anschließend nirgendwo in /proc/ide/hda wiederfinde? Ignoriert der Kernel die einfach grundsätzlich?
Nein. Das haengt aber AFAIK auch vom BIOS und der HDD ab. Bei mir z.B. klappts, obwohl ich keine Geometrie uebergebe. # grep '^[^#]*hdc=' /etc/lilo.conf # cat /proc/ide/hdc/model SAMSUNG SV1604N # cat /proc/ide/hdc/geometry physical 19457/255/63 logical 19457/255/63 # cat /proc/ide/hdc/settings | grep bios_ bios_cyl 19457 0 65535 bios_head 255 0 255 bios_sect 63 0 63 # hdparm -i /dev/hdc | grep Geom Kernel Drive Geometry LogicalCHS=19457/255/63 PhysicalCHS=19457/255/63 Im Bios ist LBA vorgegeben. Auto verzoegert eh nur das booten ;) Die RawCHS und CurCHS Werte bei hdparm -i / -I sind bei 'RawCHS' ein dummy-Wert (16383/16/63). CurCHS ist bei -i 4047/16/255 und bei -I 64761/1/255, also jew. auch die "dummy" ~8 GB wie RawCHS. Die verwendeten 19457/255/63 ergeben aber die korrekten 160 Mrd. B / 149 GB. -dnh -- Nunja! Das sind so die Sachen, die durch meine Biorne blitzen. Irgendwie Blitzbirnig, nicht wahr. [Woko° in dag°]
Am Mittwoch, 16. Februar 2005 17:12 schrieb David Haller:
(...). Nein. Das haengt aber AFAIK auch vom BIOS und der HDD ab. Bei mir z.B. klappts, obwohl ich keine Geometrie uebergebe.
# grep '^[^#]*hdc=' /etc/lilo.conf # cat /proc/ide/hdc/model SAMSUNG SV1604N
# cat /proc/ide/hda/model SAMSUNG SP1604N
# cat /proc/ide/hdc/geometry physical 19457/255/63 logical 19457/255/63
# cat /proc/ide/hda/geometry physical 16383/16/63 logical 19457/255/63 Muß ich mir jetzt Sorgen machen? Den Geometrie-Kram habe ich nämlich noch nie so ganz verstanden.
# cat /proc/ide/hdc/settings | grep bios_ bios_cyl 19457 0 65535 bios_head 255 0 255 bios_sect 63 0 63
# cat /proc/ide/hda/settings | grep bios_ bios_cyl 19457 0 65535 rw bios_head 255 0 255 rw bios_sect 63 0 63 rw
# hdparm -i /dev/hdc | grep Geom Kernel Drive Geometry LogicalCHS=19457/255/63 PhysicalCHS=19457/255/63 (...).
Da habe ich wohl eine andere hdparm-Version, solche Zeilen gibt es hier nicht aus: linux:/home/jan # hdparm -i /dev/hda | grep CHS RawCHS=16383/16/63, TrkSize=34902, SectSize=554, ECCbytes=4 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455 Mit -I sowas. Configuration: Logical max current cylinders 16383 65535 heads 16 1 sectors/track 63 63 -- CHS current addressable sectors: 4128705 LBA user addressable sectors: 268435455 LBA48 user addressable sectors: 312581808 device size with M = 1024*1024: 152627 MBytes device size with M = 1000*1000: 160041 MBytes (160 GB) TIA, Jan -- Lead, follow, or get out of the way.
Am Freitag, 11. Februar 2005 11:52 schrieb Axel Heinrici: > Hi > > Ich konnte es nicht lassen und habe SuSE 9.2 installiert. Es gibt > verschiedene logical Volumes mit reiserfs für /usr /var /home /opt. > Aus irgendeinem Grund dauert das "replaying journal" der > verschiedenen Volumes beim Hochfahren jetzt ziemlich lange (ca. 30-60 > Sekunden pro Volume). Es dauert auf jeden Fall auffallend länger als > bei der vorigen SuSE > Die Geschwindigkeit, die hdparm -rt liefert (auf ein logical Volume > losgelassen), liegt bei über 20 MB/s. Das kann es eigentlich nicht > sein. > > hdparm /dev/hda liefert > > /dev/hda: > multcount = 16 (on) > IO_support = 0 (default 16-bit) > unmaskirq = 0 (off) > using_dma = 1 (on) > keepsettings = 0 (off) > readonly = 0 (off) > readahead = 256 (on) > geometry = 65535/16/63, sectors = 120060444672, start = 0 > > Woran kann das nun noch liegen? > > mfg > Axel Hier gab es mal 'ne Anleitung im Nov 2004 von Dimitri Dimitrakos, bei der es um ein Problem mit dem hotplug ging, dabei braucht es ewig, bis reiserfs die Platten gescant hat. Workaround (Zitat): Als root - Dienst boot.hotplug deaktivieren # insserv -r boot.hotplug - Datei /r´etc/init.d/boot.hotplug editieren und boot.lvm in der Zeile Requiered start einfügen #Requiered-Start: boot.reiserfsck boot,lvm - Danach dienst reaktivieren #insserv boot.hotplug Bei mir hat es geholfen (Kaffeeverbauch deutlich gesenkt;.)) hth Rüdiger
Am Montag, 14. Februar 2005 11:44 schrieb Rüdiger Osses:
Am Freitag, 11. Februar 2005 11:52 schrieb Axel Heinrici:
Hi
Ich konnte es nicht lassen und habe SuSE 9.2 installiert. Es gibt verschiedene logical Volumes mit reiserfs für /usr /var /home /opt. Aus irgendeinem Grund dauert das "replaying journal" der verschiedenen Volumes beim Hochfahren jetzt ziemlich lange (ca. 30-60 Sekunden pro Volume). Es dauert auf jeden Fall auffallend länger als bei der vorigen SuSE Die Geschwindigkeit, die hdparm -rt liefert (auf ein logical Volume losgelassen), liegt bei über 20 MB/s. Das kann es eigentlich nicht sein.
hdparm /dev/hda liefert
/dev/hda: multcount = 16 (on) IO_support = 0 (default 16-bit) unmaskirq = 0 (off) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 256 (on) geometry = 65535/16/63, sectors = 120060444672, start = 0
Woran kann das nun noch liegen?
mfg Axel
Hier gab es mal 'ne Anleitung im Nov 2004 von Dimitri Dimitrakos, bei der es um ein Problem mit dem hotplug ging, dabei braucht es ewig, bis reiserfs die Platten gescant hat. Workaround (Zitat): Als root - Dienst boot.hotplug deaktivieren # insserv -r boot.hotplug
- Datei /r´etc/init.d/boot.hotplug editieren und boot.lvm in der Zeile Requiered start einfügen
#Requiered-Start: boot.reiserfsck boot,lvm
- Danach dienst reaktivieren #insserv boot.hotplug
Bei mir hat es geholfen (Kaffeeverbauch deutlich gesenkt;.)) hth Rüdiger Sorry, muss natürlich #Required-Start: boot.reiserfsck boot.lvm heissen Rüdiger, der 'ne neue Tastatur braucht
Hi On Monday 14 February 2005 11:48, Rüdiger Osses wrote:
Am Montag, 14. Februar 2005 11:44 schrieb Rüdiger Osses:
- Dienst boot.hotplug deaktivieren # insserv -r boot.hotplug
- Datei /r´etc/init.d/boot.hotplug editieren und boot.lvm in der Zeile Requiered start einfügen
#Requiered-Start: boot.reiserfsck boot,lvm
- Danach dienst reaktivieren #insserv boot.hotplug
Bei mir hat es geholfen (Kaffeeverbauch deutlich gesenkt;.)) hth Rüdiger
Sorry, muss natürlich #Required-Start: boot.reiserfsck boot.lvm heissen Rüdiger, der 'ne neue Tastatur braucht
Den service boot.reiserfsck gibt es bei mir gar nicht. Es gibt nur einen boot.rootfsck, der schon bei als required bei hotplug eingetragen war. Dann habe ich den service boot.lvm eingetragen und boot.hotplug mit der jetzt neuen Reihenfolge rausgenommen und wieder eingesetzt. Siehe da... Dateisystemcheck wieder in <5s pro Volume. mfg Axel
participants (4)
-
Axel Heinrici -
David Haller -
Jan Ritzerfeld -
Rüdiger Osses