Arch Linux

Frage zu Block-Layer und Sektorgröße

ebbes

Hallo zusammen,

mich beschäftigen derzeit ein paar Fragen, die ich selbst nicht beantworten kann.
Ich habe hier eine 4 TB-Festplatte und ein externes Festplattengehäuse, das bei Festplatten größer als 2 TB eine 4k-Emulation durchführt (also werden je 8 logische Sektoren zu je 512 Byte der Festplatte (die ja eigentlich selbst 4k-Sektoren intern verwendet und die 512-Byte-Sektoren nur emuliert) zu einem 4k-Sektor zusammengefasst),
ein fdisk -l erzeugt

Sektorgröße (logisch/physikalisch): 4096 Bytes / 4096 Bytes

Nun möchte ich mir gerne die Option offenhalten, die eingebaute Festplatte bei Bedarf intern zu verwenden (zum Beispiel, falls der Controller mal kaputtgehen sollte), was allerdings ein paar Probleme bereitet. Wird die Festplatte intern eingebaut, ergibt sich logischerweise ein anderes Bild:

Sektorgröße (logisch/physikalisch): 512 Bytes / 4096 Bytes

Wird GPT-Partitionierung genutzt, so enthält Sektor 1 natürlich beim Wechsel intern->extern (oder umgekehrt) nicht mehr die GPT-Tabelle.
Wird dagegen (testweise, weil ja Größenbeschränkung) MBR genutzt, enthält Sektor 0 natürlich bei beiden Sektorgrößen die Partitionierungsinformationen - nur sind diese eben nicht unbedingt korrekt (weil sich die Blockgröße ja unterscheidet): die Partitionsgrößen sind falsch und die Partitionen lassen sich natürlich nicht mounten.
Soweit alles klar, aber jetzt wird's interessant (bzw. jetzt überschreitet es meine Kenntnisse)

Wenn ich die Festplatte unpartitioniert lasse und stattdessen mit LUKS formatiere (cryptsetup luksFormat /dev/sde (ohne Zahl)) oder auf der gesamten Festplatte ein ext4-Dateisystem erzeuge (mkfs.ext4 /dev/sde (dito)), dann kann ich die Festplatte (anscheinend) intern/extern tauschen wie ich will, ich komme immer an die Daten dran und es scheint kein Problem zu geben.
Das wundert mich aber - im LUKS-Header ist meines Wissens nach der Payload Offset in Sektoren angegeben, weshalb das mappen ja eigentlich nicht funktionieren dürfte und irgendwie muss ja auch ext4 die Festplatte adressieren.

Die Frage ist nun: warum funktioniert das Mounten trotz Blockgrößenunterschied, wenn ich die ganze Festplatte nutze? Wird da nicht mit Sektoren gearbeitet? Ist der Kernel etwa intelligent genug, da eine Übersetzung durchzuführen, falls irgendwelche Daten nicht übereinstimmen?

Ich hoffe, irgendjemand hat mehr Ahnung als ich und kann mir weiterhelfen.

Dirk

ebbes schriebIch habe hier eine 4 GB-Festplatte […]

Du solltest vielleicht mal einen Zehner in die Hand nehmen, und die Platte gegen eine viermal so große SD-Karte austauschen 🙂

ebbes schriebIch hoffe, irgendjemand hat mehr Ahnung als ich und kann mir weiterhelfen.

Mal in einem Computermuseum gefragt?

ebbes

Dirk schrieb
ebbes schriebIch habe hier eine 4 GB-Festplatte […]
Du solltest vielleicht mal einen Zehner in die Hand nehmen, und die Platte gegen eine viermal so große SD-Karte austauschen 🙂

ebbes schriebIch hoffe, irgendjemand hat mehr Ahnung als ich und kann mir weiterhelfen.
Mal in einem Computermuseum gefragt?

Ahhh verdammt. Es sollten jedes Mal TB sein... Hab's oben geändert, damit nicht jeder, der das Thema liest, mich gleich nach der Lektüre des ersten Posts auslacht, sondern erst nach dem zweiten...

Greg

So ganz verstehe ich das nicht.
Falls du das meinst, dass die Partitionen fälschlicherweise zu 512 Sektorgröße angelegt wird. Kannst du fdisk mit der option -b, --sector-size 4096 aufrufen.
Bei gdisk für GPT geht das glaube ich im expert Modus allignment heißt das.
Dann sollte es meiner Meinung nach egal sein ob das Ding intern oder extern benutzt wird.

ebbes

Greg schriebSo ganz verstehe ich das nicht.
Falls du das meinst, dass die Partitionen fälschlicherweise zu 512 Sektorgröße angelegt wird. Kannst du fdisk mit der option -b, --sector-size 4096 aufrufen.
Bei gdisk für GPT geht das glaube ich im expert Modus allignment heißt das.
Dann sollte es meiner Meinung nach egal sein ob das Ding intern oder extern benutzt wird.

Nunja, sie wird ja nicht direkt fälschlicherweise mit der falschen Sektorgröße angezeigt, sondern verhält sich wie eine Festplatte mit der angezeigten Sektorgröße.
Aber der Parameter für fdisk hat mich dann doch auf eine Fährte gebracht, habe vor allem https://superuser.com/a/720718 gefunden, was ich verallgemeinert habe, um auf meinen Fall (genau umgekehrt) anwendbar zu sein:

#!/bin/bash

# attach GPT partitions of a device that was formatted with an incorrect block size
# (e.g. 4k sector emulation in external HDD enclosure)
#
# based on https://superuser.com/a/720718

attach_device() {
	device="$1"
	if [ ! -e "$device" ]; then
		echo "$device does not exist"
		exit 1
	fi

	blocksize="$2"
	if [ -z $blocksize ]; then
		blocksize="512"
	fi
	echo "Assuming block size of $blocksize bytes"

	MYTMPDIR=$(mktemp -d)
	trap "rm -rf $MYTMPDIR" EXIT

	# check for valid GPT header
	header=$(dd if="$device" bs=1 count=8 skip="$blocksize" 2> /dev/null)
	if [ "$header" != "EFI PART" ]; then
		echo "No GPT header found. Try specifying a different block size."
		exit 1
	fi

	# copy LBA0 (MBR) with size 512 bytes
	dd if="$device" bs=1 count=512 of="$MYTMPDIR/gpt" 2> /dev/null
	# append 16384 bytes (GPT size) starting from LBA1 to MBR
	dd if="$device" bs=1 count=16384 seek=512 skip="$blocksize" of="$MYTMPDIR/gpt" 2> /dev/null

	# extract offset and size of each partition
	gdisk -l \
		"$MYTMPDIR/gpt" 2> /dev/null | \
		awk "/^ *[0-9]/ {printf \"%.0f %.0f %.0f\n\", \$1, \$2 * $blocksize, (\$3 - \$2 + 1) * $blocksize}" > $MYTMPDIR/offset-size


	# create a loop device with given offset and size
	count=1
	while read line;
	do
		number=$(printf "$line" | cut -d ' ' -f 1)
		offset=$(printf "$line" | cut -d ' ' -f 2)
		size=$(printf "$line" | cut -d ' ' -f 3)
		loopdev=$(losetup -f)
		losetup --verbose --offset "$offset" --sizelimit "$size" "$loopdev" "$device"
		echo "Attached partition $((count++)) to $loopdev"
	done < $MYTMPDIR/offset-size

	if [ $count = 1 ]; then
		echo "No partitions found"
		exit 1
	fi
}

detach_device() {
	device="$1"

	count=0
	for loopdevice in $(losetup -j "$device" | cut -d : -f 1)
	do
		losetup --verbose --detach "$loopdevice"
		count=$((count + 1))
		echo "Detached $loopdevice"
	done

	if [ $count = 0 ]; then
		echo "No partitions found to detach"
	fi
}

usage() {
	cat <<EOF
Usage:
	$0 -h
		print this help
	$0 device [blocksize]
		attach the gpt partitions of device,
		assume blocksize bytes per block (defaults to 512)
	$0 -d device
		detach the gpt partitions of device
EOF
	exit
}


detach=0;

while getopts hd action
do
	case "$action" in
		d) detach=1;;
		h) usage;;
	esac
done
shift $(($OPTIND-1))

if [ $# -lt 1 ];
then
	usage
fi

if [ "$detach" = "0" ]; then
	attach_device $1 $2
else
	detach_device $1
fi

Damit konnte ich die Partitionen an ein Loopdevice anhängen und das dann mounten.

Allerdings war meine Frage ja eigentlich, warum das Mounten funktioniert, obwohl die Sektorgröße ja eigentlich nicht passt (weshalb jede IO-Operation ja eigentlich den falschen Sektor zurückliefern sollte). Dazu habe ich jetzt aber offenbar die Antwort im Sourcecode gefunden:

/include/linux/types.h
121 /**
122  * The type used for indexing onto a disc or disc partition.
123  *
124  * Linux always considers sectors to be 512 bytes long independently
125  * of the devices real block size.
126  *
127  * blkcnt_t is the type of the inode's block count.
128  */
129 #ifdef CONFIG_LBDAF
130 typedef u64 sector_t;

Der Kernel arbeitet also immer mit 512-Byte-Sektoren und übersetzt die dann entsprechend der Größe, die die Festplatte angibt. Jetzt verstehe ich endlich, warum z.B. LUKS-Container oder Partitionen direkt auf dem Blockdevice (ohne Partitionierung) funktionieren - der entsprechende Header wird in LBA0 erwartet, und der unterscheidet sich nie, egal, wie groß die Sektoren sind. MBR wird zwar gefunden, aber die Sektoren passen nicht, weshalb die Partitionsheader nicht gefunden werden. Und eine GPT wird gar nicht erst gefunden, weil die in LBA1 erwartet wird.

frostschutz

Ich versteh bis heute nicht, warum GPT von Sektorgröße abhängig ist. So unnötig. [Und könnte in/von Linux besser implementiert werden.]

im LUKS-Header ist meines Wissens nach der Payload Offset in Sektoren angegeben

Was sich aber nicht nach der physikalischen Sektorgröße richten muss. Die sollte ja so oder so, einfach egal sein. Sonst würden ja auch Dateisysteme usw.usf. nicht mehr funktionieren.

Anders siehts bei TrueCrypt aus, das hat sich auch selbst von Sektorgrößen abhängig gemacht. So hat cryptsetup zwar eine Truecrypt Unterstützung aber nur für die 512-Byte-Sektor Variante.

Mach Partitionen, aber merk dir von wo bis wo. Wenn du nur eine große Partition von 1MiB bis Ende machst, dann kannst du die Partitionstabelle bei Bedarf einfach neu anlegen und gut.

ebbes

frostschutz schriebIch versteh bis heute nicht, warum GPT von Sektorgröße abhängig ist. So unnötig. [Und könnte in/von Linux besser implementiert werden.]

im LUKS-Header ist meines Wissens nach der Payload Offset in Sektoren angegeben
Was sich aber nicht nach der physikalischen Sektorgröße richten muss. Die sollte ja so oder so, einfach egal sein. Sonst würden ja auch Dateisysteme usw.usf. nicht mehr funktionieren.

Stimmt, GPT abhängig von Sektorgrößen zu machen, ist relativ dämlich. Zumindest den Offset hätte man einfach auf 512 Byte (statt einen Sektor) festlegen können.
Und du hast Recht, im LUKS-Header scheint der Offset in logischen Sektoren zu je 512 Byte angegeben zu sein. Danke für den Hinweis.

frostschutz

ebbes schriebStimmt, GPT abhängig von Sektorgrößen zu machen, ist relativ dämlich. Zumindest den Offset hätte man einfach auf 512 Byte (statt einen Sektor) festlegen können.

Was Linux (meiner Meinung nach, die ja niemanden interessiert) tun sollte, ist auf gängigen Offsets nach dem GPT-Header zu suchen, und diesen dann mit diesem Offset als Sektorgröße zu interpretieren statt tatsächlich die Sektorgröße von der Platte selbst zu verwenden.

Dann würde Linux die Platten/Partitionen richtig erkennen, egal ob sie gerade in einem Gehäuse mit 4K-Emulation laufen oder nicht, bzw. egal ob gerade mit dd von einem 512-Byte auf ein 4k-Medium rübergeklatscht wurde oder nicht.