Wheezy Neuinstallation auf neue ssd GPT Detailfragen

[whisper]

Ich habe vor, meinem Notebook eine 120 Gig SSD zu gönnen.
Ausgesucht habe ich die SanDisk SDSSDP-128G-G25, die hat einen sehr geringen Stromverbrauch.
Ich werde die Partionen mit der gparted-live-0.13.1-2 vornehmen.
Ich wähle GPT als Partitonstable aus.
Nun zur Frage
Ich wollte eigentlich wieder eine Volumegroup anlegen. GParted geht das nicht, zumindestens nicht mit der Live Version.
Wenn ich nun also in GParted GPT ausgewählt habe und eine Partition von 256 MB für /Boot ext2 anlege und formatiere, dann kann ich bei der Debian Wheezy Installation ja im unpartitionierten Bereich das LVM anlegen mit den Rest.

Habe da noch was wegen des Alignment der Blöcke zu beachten, oder hat sich GParted darum schon gekümmert und ich beuache mir keine Sorgen zu machen?
Formatiert wird /root und /home später mit ext4

[delaytime0]

Ich habe meine Partition mit gdisk von einer Arch-Linux-CD erstellt.
Es wundert mich jedoch, dass gparted/partedmagic kein pvcreate, vgcreate, lvcreate können soll.

PS: Habe die gleiche SSD wegen des sehr guten Stromverbrauchs verbaut ^^

[whisper]

Ich habe meine Partition mit gdisk von einer Arch-Linux-CD erstellt.
Es wundert mich jedoch, dass gparted/partedmagic kein pvcreate, vgcreate, lvcreate können soll.

PS: Habe die gleiche SSD wegen des sehr guten Stromverbrauchs verbaut ^^

Wird ausdrücklich ausge-ixt in der Übersicht der unterstützen Dateisysteme.
Die Kommandos sind allerdings verfügbar.
Habe gerade in der virtual Box mal ausprobiert, geht und wird augenblicklich nach neuanlesen auch angezeigt.
Fehlen mir noch noch die Empfehlungen für Chunksize bei lvcreate. Ist default ok? Erkennt lvcreate das es eine ssd ist?

[delaytime0]

Aus unbestätigten Gerüchten habe ich mir sagen lassen, dass es gut ist, wenn man das Alignment auf 1024k setzt.
Leider ist es nicht wirklich überschaubar wie die einzelnen Controller auf den Chips umherrödeln.
Wichtig ist, dass die physicalextendsize ein vielfachesdes alignments entspricht.
in meinen Fall habe ich das so gelöst:

pvcreate --dataalignment 1024k /dev/sdxY
vgcreate --physicalextentsize $(( n * 1024 ))k vg0 /dev/sdxY

n = 4 für 4MB-Blöcke

zur Ergänzung:
in der fstab müssen im Nachgang dann noch discard, noatime oder relatime für ext-Partitionen ergänzt werden.
Discard beim SWAP ist nicht nötig. Das macht es schon brav von alleine.
data=ordered für ext4

zusätzlich habe ich noch write-through, noop als scheduler, tmpfs im RAM (tmpfs /tmp tmpfs nodev,nosuid,noexec,mode=1777 0 0)-> sollte ab 4GB RAM kein Problem sein, Swappiness ist auf 0.

[r900]

Ich habe meine Partition mit gdisk von einer Arch-Linux-CD erstellt.

gdisk ist auch auf der gparted-CD dabei.

Wenn du schon gpt benutzt, dann leg auch gleich eine BIOS boot partition an (code EF02).

[whisper]

Ich habe meine Partition mit gdisk von einer Arch-Linux-CD erstellt.

gdisk ist auch auf der gparted-CD dabei.

Wenn du schon gpt benutzt, dann leg auch gleich eine BIOS boot partition an (code EF02).

OHA!
siehste, gut das ich fragte.
Ich werde mal alles aufschreiben. damit ichs später mal wieder nachlesen kann. Wer weiß vielleicht gewinnt man ja mal im Lotto und rüstet alle Rechner so aus

[delaytime0]

Guter Punkt. EFI ist ja auch son Punkt den man berücksichtigen sollte.
Hatte ich ganz außer Acht gelassen.

[r900]

Naja, EFI in diesem Fall nicht, deshalb BIOS boot partition. So wie ich das verstehe braucht grub diese Partition weil er sich nicht wie sonst üblich zwischen MBR und erster Partition einnisten kann.

Das alignment bei SSDs scheint auch eine Wissenschaft für sich zu sein.. Wieso findet man dazu eigentlich keine Informationen beim Hersteller? Da würde ich sowas erwarten wie "für beste Performance achten Sie beim Partitionieren bitte darauf dass..."

[whisper]

Das alignment bei SSDs scheint auch eine Wissenschaft für sich zu sein.. Wieso findet man dazu eigentlich keine Informationen beim Hersteller? Da würde ich sowas erwarten wie "für beste Performance achten Sie beim Partitionieren bitte darauf dass..."

Ja, eigentlich sollte im technischen Teil einer Benutzerang so etwas klipp- und klar stehen.
Aber das würde Ottonormal W$ User überfordern und verunsichern.

Allerdings habe ich die Angaben für pvcreate und vgcreate in meiner virtualbox verglichen, ich behaupte, die Größenangabe ist default.
Ich denke, morgen kommt die Platte, dann werde ich sehen.

[maledora4]

Ja, EFI bedarf es eigentlich nicht und die technischen Einzelheiten der Platte siehst Du dann wie hier an meiner vom Oktober vorigen Jahres mit dem Befehl

Code: Alles auswählen

hdparm -I /dev/sda

/dev/sda:

ATA device, with non-removable media
	Model Number:       MXSSD1MNANO-60G                         
	Serial Number:      110105411           
	Firmware Revision:  VATE1702
	Transport:          Parallel, ATA8-APT
Standards:
	Used: unknown (minor revision code 0x0039) 
	Supported: 8 7 6 5 
	Likely used: 8
Configuration:
	Logical		max	current
	cylinders	16383	16383
	heads		16	16
	sectors/track	63	63
	--
	CHS current addressable sectors:   16514064
	LBA    user addressable sectors:  117440512
	LBA48  user addressable sectors:  117440512
	Logical/Physical Sector size:           512 bytes
	device size with M = 1024*1024:       57344 MBytes
	device size with M = 1000*1000:       60129 MBytes (60 GB)
	cache/buffer size  = unknown
	Nominal Media Rotation Rate: Solid State Device
Capabilities:
	LBA, IORDY(cannot be disabled)
	Standby timer values: spec'd by Standard, no device specific minimum
	R/W multiple sector transfer: Max = 16	Current = 16
	DMA: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 udma6 
	     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:
	   *	SMART feature set
	    	Security Mode feature set
	   *	Power Management feature set
	    	Write cache
	    	Look-ahead
	   *	Host Protected Area feature set
	   *	WRITE_BUFFER command
	   *	READ_BUFFER command
	   *	NOP cmd
	   *	DOWNLOAD_MICROCODE
	    	SET_MAX security extension
	   *	48-bit Address feature set
	   *	Mandatory FLUSH_CACHE
	   *	FLUSH_CACHE_EXT
Security: 
	Master password revision code = 65534
		supported
	not	enabled
	not	locked
		frozen
	not	expired: security count
		supported: enhanced erase
	2min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.
HW reset results:
	CBLID- above Vih
	Device num = 0 determined by the jumper
Checksum: correct

Sie hat keinen Trim, aber CarbageCollection und steht auf frozen, statt not frotzen, um das Löschen mit SecureErase zu ermöglichen.
Wußte ich auch allesvorher nicht.