Oft erlebe ich es, dass Bekannte in ihren PCs die Festplatten umbauen und dann vor dem Problem stehen, dass Linux nicht mehr starten will. Dieser Problematik kann man mit den Volume-Labels prima aus dem Weg gehen.
gerade bei einem Umbau von Festplatten ist es allerdings wichtig darauf zu achten, dass die Volumelabels eindeutig sind. Sonst kann es schnell pasieren, dass es z.B. das Label "/home" zweimal existiert und die Partition deshalb nicht gemountet wird. Bei der root-Partition wird die Sache noch kritischer.
gerade mit den Labels kommt es zu problemen,hatte ein "altes" RedHat-System auf meinem Rechner, und wollte auf einer neuen Platte ein neues RH-System installieren, gedacht, getan. der "einfachheit"-halber wollte ich die alte platte als slave einhängen und noch benötigte daten einfach rüberkopieren. beim booten, hatte das neue RH, die root-partition von der alten platte eingemountet *kotz, also in die fstab und alle labels RAUS und schon gehts wie gewollt .
das mit den labels schön und gut, aber man sollte es einem anwender/admin überlassen ob man per default damit arbeiten will ..
nehme ich die platte vom master und hänge sie an slave ist hda nun hdb und linux bootet nicht mehr. mache ich aus einer partition zwei so ist das hda2 nun hda3 und das system ist inkonsistent. das nur als beispiel
du verstehst das falsch. die platten werden dann ja über LABEL=root / ext2 defaults,errors=remount-ro 0 1 eingebunden und das Label wird in die jeweilige Partition geschrieben und nicht nur als Fake. Der Name kommt wohl in den Superblock oder so.
Trotzdem steht in der Partition immer noch die Zuweisung des Labels auf einen Hardwarepfad siehe die tune2fs-Kommandos im Beitrag. Labels muss ich demnach erneut setzen, damit die Einträge in der fstab stimmen. Ist also nur eine Verlagerung der administrativen Eingriffe.
Von Jörg W Mittag am Mi, 10. September 2003 um 13:43 #
>> Was für eine Zuweisung auf was für einen Hardwarepfad? > tune2fs -L LABEL HARDWAREPFAD zur Partition
Ich kann immer noch keine Zuweisung erkennen. Was auch immer das überhaupt sein soll, ich kenne den Begriff eigentlich nur von imperativen Programmiersprachen.
Also nochmal:
Ich schreibe ein Label in eine Partition.
Mount durchsucht alle Partitionen nach dem Label und mountet diejenige, die das Label enthält.
Wo ist da eine Zuweisung?
>> Nein, muss man nicht, das ist schließlich gerade der Sinn von Volume Labels. > Doch, beim Umzug vom alten aufs neue System.
Wieso? Ich meine, du kannst dir natürlich selbst in den Fuß schießen, wenn du dasselbe Label mehrfach vergibst, aber das fällt dann unter die Kategorie "Selbst Schuld."
Na wohl eher nicht. Der Aufruf heisst "tune2fs LABEL HWPFAD" und das auch nur deswegen, weil das tune2fs kommando ja den Pfad braucht - und nicht weil der Pfad in der Platte geschrieben werden muss.
Die Masterplatte am ersten IDE-Kontroller ist _immer_ hda. Die erste primäre Partition darauf _immer_ hda1 die erste logische Partition darauf _immer_ hda5. ...usw.
Das Linux nicht mehr bootet, wenn du die Masterplatte mit Linux als slave einhängst, ist kein Argument, das tut sie naemlich auch nicht, wenn du labels verwendest.
Wer sein Rechnersystem ummodeliert, muss sich im Klaren sein, was er da aendert, und wo sich das auswirkt. Und wenn dadurch die fstab und der bootloader durcheinanderkommen, dann muss root das eben aendern.
Von Jörg W Mittag am Mi, 10. September 2003 um 11:48 #
> Die Masterplatte am ersten IDE-Kontroller ist _immer_ hda.
Und welches der erste IDE-HBA ist, hängt von der Ladereihenfolge der Treiber ab und diese kann sich auch schon mal zwischen verschiedenen Kernelversionen ändern. Wenn es sich Module handelt, die automatisch geladen werden, ist die Ladereihenfolge sogar mehr oder weniger zufällig.
Von SCSI will ich gar nicht erst anfangen.
> Das Linux nicht mehr bootet, wenn du die Masterplatte mit Linux als slave einhängst, ist kein Argument, das tut sie naemlich auch nicht, wenn du labels verwendest.
Dann hast du etwas falsch gemacht. Schau dir mal Knoppix an, da funktioniert das Booten problemlos, obwohl beim Booten nicht bekannt ist, ob das Root-Dateisystem jetzt auf sda, sdb oder hdy liegt.
Von Jörg W Mittag am Di, 9. September 2003 um 14:12 #
Sie hängen meist von Nebenbedingungen ab, die außerhalb der Kontrolle des Betriebssystems liegen, wie z.B. der Reihenfolge der Erkennung der Adapter im System, welches Kabel an welchem Port steckt, der Ladereihenfolge der Module u.s.w.
Wenn du z.B. erst das IEEE1394-Massenspeicher-Modul und dann USB-Storage laedst, dann ist deine IEEE1394-Platte /dev/sda und die USB-Platte /dev/sdb, ansonsten umgekehrt. Dafür gibt es aber keinen Grund, denn schließlich ist das Gerät immer noch dasselbe, also warum sollte es einen anderen Namen haben?
Es gibt natürlich andere Möglichkeiten, als die Verwendung von Volume-Labels, die ja sehr eingeschränkt sind, weil sie nur mit Dateisystemen und auch da nicht mit allen funktionieren. Devlabel z.B. funktioniert mit allen Datenträgern und Partitionen, egal ob dort ein Dateisystem drauf ist oder nicht. Und udev wird, wenn es dann mal fertig ist, alle Device-Namen aus UUIDs (natürlich nur bei Geräten, die so etwas haben, wie Festplatten, Disketten, Netzwerk-Karten u.s.w.) oder Topologie-Informationen (zweites Gerät am fünften Hub des dritten USB) erzeugen können.
Mit inkonsistent meine ich, daß es überhaupt hdx, sdx, mdx usw. gibt. Ich habe kein Problem damit, aber letztlich sind es alles Festplatten und sollten auch unter einem einheitlichen Namen angesprochen werden können.
Koennen die VLs ueberall verwendet werden, auch bei lilo und/oder grub, so dass man die "alte" Angabe des devices (/dev/hdx) gar nicht mehr benoetigt? Wenn ja, haette da jemand eine Info-Quelle zu?
PS: Mit dem kompletten Loesen von den alten dev-Bezeichnungen waere der letzte Vorteil eines Amiga-Systems, der mir einfaellt, gegenueber Linux weggefallen ;)
Von Headbanger am Di, 9. September 2003 um 20:52 #
[sentimental] Ein Amiga hat aber trotz allem noch irgendwas an sich, was ich nicht beschreiben kann, mich aber daran hindert, meinen A4000T zu verkaufen. [/sentimental]
Wenn mich irgendwer fragt, was ich mit der Kiste noch will, kann ich's absolut nicht erklären.
Das stimmt nicht! Grub kann auf ext2/3 reiserfs und noch paar andere zugreifen!
Aber mir ist es auch nicht bekannt, daß er die Labels lesen kann :(
Zu Amiga: Jo die hatten das damals schon gemacht und das wurd auch richtig genutzt. Die Kommentare hier kann ich nciht verstehen, wo es heißt "wenn zwei Partitionen den gleichen Label bekommen....". Lables sind kein Ersatz! Das ist ein Zusatzmöglichkeit! Und das hat damals bei Amiga mit Disketten, Platte, CD problemlos geklappt.
Auch bei den MS Systemen kann man die Platten benennen, aber das wird von kein Programm verwendet :(
Hoffentlich setz sich das richtig durch, damit man schon bei der Installation Labels vergeben kann und so auch doppeltvergaben sich nicht häufen. Oder beim hochfahren wahlweise mehrere Platten angeboten werden, falls sie den gleichen Label haben und auch GRUB das interpretiert. Labels sind namlich, finde ich, die eindeutigste möglichkein den System zu sagen, wie das Filesystem zu mounten ist bzw. welche Partitionen gemeint sind.
Das würde die Nachteile von MS C: D: Bezeichnungen nicht haben und auch die Nachteile von /dev/hdx bzw. sdx
Weil wenn ich nunmal als letzte Partition hda8 mein root habe und dann davor eine Partition erstellt bzw. splitte, dann ist mein root auf hda9 und das Mounten klappt nicht. Wenn auch GRUB Lables unterstüzten würde, währe sowas kein Problem mehr. Und wer es doch nicht so haben will, den bleibt immernoch die Möglichkeit für /dev Angaben
Von Markus Feldmann am Di, 12. Oktober 2004 um 23:59 #
Hallo,
wollte nur sagen dass der mount Befehl zwar mit Labels umgehen kann, aber der unmount Befehl nicht. Ich will nähmlich manchmal auf die Schnelle, meine Platte unmounten über ein externes Firewire/IDE Gehäuse um dann die Platte zu wechseln. Und dann komme ich nicht um den /dev/hdbx Namen herum. Das nervt.
Von Ronny Buchmann am Di, 9. September 2003 um 16:29 #
Ich habe die Informationen soweit es mir möglich war vervollständigt ins Linuxwiki gestellt. http://linuxwiki.org/DateisystemLabel und http://linuxwiki.org/UUID
xfs_admin uses the xfs_db(8) command to modify various parameters of a filesystem.
Devices that are mounted cannot be modified. Administrators must unmount filesystems before xfs_admin or xfs_db can convert parameters. A number of parameters of a mounted filesystem can be examined and modified using the xfs_growfs(8) command.
OPTIONS
-f Specifies that the filesystem image to be processed is stored in a regular file (see the mkfs.xfs-dfile option).
-l Print the current filesystem label.
-u Print the current filesystem UUID (Universally Unique IDentifier).
-Llabel Set the filesystem label. XFS filesystem labels can be at most 12 characters long; if label is longer than 12 characters, xfs_admin will truncate it and print a warning message. The filesystem label can be cleared using the special ``--'' value for label.
-UUUID Set the UUID of the filesystem. A sample UUID looks like this: "c1b9d5a2-f162-11cf-9ece-0020afc76f16". The uuid may also be null, which will set the filesystem UUID to the null UUID. The uuid may also be generate, which will generate a new UUID for the filesystem.
The mount(8) manual entry describes how to mount a filesystem using its label or UUID, rather than its block special device name.
DESCRIPTION [...] -Llabel Set the filesystem label. XFS filesystem labels can be at most 12 characters long; if label is longer than 12 characters, mkfs.xfs will not proceed with creating the filesystem. Refer to the mount(8) and xfs_admin(8) manual entries for additional information.
Von Werner Modenbach am Do, 11. September 2003 um 10:00 #
Das löst ein Problem, das ich dauernd auf Fileservern habe. Dort gibt es sehr viele Platten, die an SCSI-Controllern hängen. Fällt eine Platte aus, "rutschen" alle nachfolgenden Platten im Laufwerksbuchstaben eins runter - aus /dev/sdf wird /dev/sde etc. Daraus folgt, daß ich sämtliche Mountpunkte in der fstab abändern muß, damit der Server weiter wie gewohnt (allerdings mit einer fehlenden Platte) arbeitet. Noch schlimmer ist es, wenn die Platten zu RAIDs zusammengefaßt sind. Die Möglichkeit Labels zu verwenden, löst das sehr elegant. Für unsere SCSI-Platten setze ich momentan das Tool mapscsi ein, welches beim Bootvorgang aus den Laufwerksdaten, z.B. Hersteller und Seriennummer, ein synthetisches Device generiert, welches dann unabhängig von der Position am SCSI-Bus ist.
Von schlaffie am Do, 11. September 2003 um 23:58 #
ist m.E. auch der einzigste Weg...die Labelunterstützung ist nicht überall vorhanden und wirds auch nicht. Es ist ne Frage der Entwicklung, das zukünftig jedes Medium erkennbar ist, leider. In diesem Sinne drücke ich uns die Daumen, daß wir unsere, soviel beschimpften, SCSI Systeme behalten dürfen. Die LKW-Maut kommt als nächstes und damit auch alles richtig erkannt wird, hat denn jeder LKW nen Namen dranstehen. Hehe, und an jeder Autobahnabfahrt steht ein Polizist und schreibt die Namen auf!
Beim Testen der Labels mit einem Raid1 Verbund kommt es irgendwie zu Problmen (2.4.22er Kernel, xfs Progs aus Debian unstable). Ich kann zwar dem Raidverbund (/dev/md0) ein Label zuweisen, aber sobald ich Neustarte oder das Raid stoppe bekommt eine der beiden Platten das Label und ich nach dem Starten des Raid das Label nicht mehr ansprechen. Hat da auch schon jemand Erfahrung mit gemacht?
Beim Versuch meine Festplatte umzunennen während sie noch gemounted war funktionierte zwar aber beim nächsten Zugriff auf die Platte quittierte er es mit einem Reset.
Nun erscheinen beim Mounten der platte keinen Daten mehr!
Hi, hat zwar net so viel mit dem Thema zu tun aber bei einigen Foren kann mir wohl niemand helfen.
Ich versuche mit mount CD-Images zu mounten und es klappt einfach nicht.
Ich habe folgendes gemacht: - 2 Verzeichnisse angelegt: Imges und CDS - die Image in einem Verzeichnis in Images untergebracht - dann folgenden Befehl als root ausgeführt: mount -tiso9660 /Images/Orndername/Imagename.img /CDS/Ordnername -o loop
Dabei erhielt ich diese Fehlermeldung:
mount: wrong fs type, bad option, bad superblock on /dev/loop1 or too many mounted filsystems
--> ich habe es mit mehreren Imagetypen probiert also auch die geforderten ISO-Images
gerade bei einem Umbau von Festplatten ist es allerdings wichtig darauf zu achten, dass die Volumelabels eindeutig sind. Sonst kann es schnell pasieren, dass es z.B. das Label "/home" zweimal existiert und die Partition deshalb nicht gemountet wird. Bei der root-Partition wird die Sache noch kritischer.
Gruß Pug
das mit den labels schön und gut, aber man sollte es einem anwender/admin überlassen ob man per default damit arbeiten will ..
grüsse
ChrisPr
ratte
mache ich aus einer partition zwei so ist das hda2 nun hda3 und das system ist inkonsistent.
das nur als beispiel
Wenn ich eine Masterplatte als Slave dranhänge, steht im System doch immer noch: /Home = /hda1 - egal ob sie es wirklich ist oder nicht!
tux73
LABEL=root / ext2 defaults,errors=remount-ro 0 1
eingebunden und das Label wird in die jeweilige Partition geschrieben und nicht nur als Fake.
Der Name kommt wohl in den Superblock oder so.
Gruß,
Andi
Was für eine Zuweisung auf was für einen Hardwarepfad?
> Labels muss ich demnach erneut setzen, damit die Einträge in der fstab stimmen.
Nein, muss man nicht, das ist schließlich gerade der Sinn von Volume Labels.
jwm
tune2fs -L LABEL HARDWAREPFAD zur Partition
> Nein, muss man nicht, das ist schließlich gerade der Sinn von Volume Labels.
Doch, beim Umzug vom alten aufs neue System.
> tune2fs -L LABEL HARDWAREPFAD zur Partition
Ich kann immer noch keine Zuweisung erkennen. Was auch immer das überhaupt sein soll, ich kenne den Begriff eigentlich nur von imperativen Programmiersprachen.
Also nochmal:
Wo ist da eine Zuweisung?
>> Nein, muss man nicht, das ist schließlich gerade der Sinn von Volume Labels.
> Doch, beim Umzug vom alten aufs neue System.
Wieso?
Ich meine, du kannst dir natürlich selbst in den Fuß schießen, wenn du dasselbe Label mehrfach vergibst, aber das fällt dann unter die Kategorie "Selbst Schuld."
jwm
Gruß
Johanes
In|kon|sis|tenz Unbeständigkeit, mangelnde Haltbarkeit
Die Masterplatte am ersten IDE-Kontroller ist _immer_ hda.
Die erste primäre Partition darauf _immer_ hda1
die erste logische Partition darauf _immer_ hda5.
...usw.
Das Linux nicht mehr bootet, wenn du die Masterplatte mit Linux als slave einhängst, ist kein Argument, das tut sie naemlich auch nicht, wenn du labels verwendest.
Wer sein Rechnersystem ummodeliert, muss sich im Klaren sein, was er da aendert, und wo sich das auswirkt. Und wenn dadurch die fstab und der bootloader durcheinanderkommen, dann muss root das eben aendern.
Und welches der erste IDE-HBA ist, hängt von der Ladereihenfolge der Treiber ab und diese kann sich auch schon mal zwischen verschiedenen Kernelversionen ändern. Wenn es sich Module handelt, die automatisch geladen werden, ist die Ladereihenfolge sogar mehr oder weniger zufällig.
Von SCSI will ich gar nicht erst anfangen.
> Das Linux nicht mehr bootet, wenn du die Masterplatte mit Linux als slave einhängst, ist kein Argument, das tut sie naemlich auch nicht, wenn du labels verwendest.
Dann hast du etwas falsch gemacht. Schau dir mal Knoppix an, da funktioniert das Booten problemlos, obwohl beim Booten nicht bekannt ist, ob das Root-Dateisystem jetzt auf sda, sdb oder hdy liegt.
jwm
Wenn du z.B. erst das IEEE1394-Massenspeicher-Modul und dann USB-Storage laedst, dann ist deine IEEE1394-Platte /dev/sda und die USB-Platte /dev/sdb, ansonsten umgekehrt. Dafür gibt es aber keinen Grund, denn schließlich ist das Gerät immer noch dasselbe, also warum sollte es einen anderen Namen haben?
Es gibt natürlich andere Möglichkeiten, als die Verwendung von Volume-Labels, die ja sehr eingeschränkt sind, weil sie nur mit Dateisystemen und auch da nicht mit allen funktionieren. Devlabel z.B. funktioniert mit allen Datenträgern und Partitionen, egal ob dort ein Dateisystem drauf ist oder nicht. Und udev wird, wenn es dann mal fertig ist, alle Device-Namen aus UUIDs (natürlich nur bei Geräten, die so etwas haben, wie Festplatten, Disketten, Netzwerk-Karten u.s.w.) oder Topologie-Informationen (zweites Gerät am fünften Hub des dritten USB) erzeugen können.
jwm
jwm
PS: Mit dem kompletten Loesen von den alten dev-Bezeichnungen waere der letzte Vorteil eines Amiga-Systems, der mir einfaellt, gegenueber Linux weggefallen ;)
Ein Amiga hat aber trotz allem noch irgendwas an sich, was ich nicht beschreiben kann, mich aber daran hindert, meinen A4000T zu verkaufen.
[/sentimental]
Wenn mich irgendwer fragt, was ich mit der Kiste noch will, kann ich's absolut nicht erklären.
LILO und Grub können logischerweise nicht mit Volume Labels umgehen, da sie mit Dateisystemen überhaupt nichts zu schaffen haben.
jwm
Aber mir ist es auch nicht bekannt, daß er die Labels lesen kann :(
Zu Amiga:
Jo die hatten das damals schon gemacht und das wurd auch richtig genutzt. Die Kommentare hier kann ich nciht verstehen, wo es heißt "wenn zwei Partitionen den gleichen Label bekommen....".
Lables sind kein Ersatz! Das ist ein Zusatzmöglichkeit!
Und das hat damals bei Amiga mit Disketten, Platte, CD problemlos geklappt.
Auch bei den MS Systemen kann man die Platten benennen, aber das wird von kein Programm verwendet :(
Hoffentlich setz sich das richtig durch, damit man schon bei der Installation Labels vergeben kann und so auch doppeltvergaben sich nicht häufen.
Oder beim hochfahren wahlweise mehrere Platten angeboten werden, falls sie den gleichen Label haben und auch GRUB das interpretiert.
Labels sind namlich, finde ich, die eindeutigste möglichkein den System zu sagen, wie das Filesystem zu mounten ist bzw. welche Partitionen gemeint sind.
Das würde die Nachteile von MS C: D: Bezeichnungen nicht haben und auch die Nachteile von /dev/hdx bzw. sdx
Weil wenn ich nunmal als letzte Partition hda8 mein root habe und dann davor eine Partition erstellt bzw. splitte, dann ist mein root auf hda9 und das Mounten klappt nicht.
Wenn auch GRUB Lables unterstüzten würde, währe sowas kein Problem mehr.
Und wer es doch nicht so haben will, den bleibt immernoch die Möglichkeit für /dev Angaben
wollte nur sagen dass der mount Befehl zwar mit Labels umgehen kann,
aber der unmount Befehl nicht.
Ich will nähmlich manchmal auf die Schnelle, meine Platte unmounten
über ein externes Firewire/IDE Gehäuse um dann die Platte zu wechseln.
Und dann komme ich nicht um den /dev/hdbx Namen herum.
Das nervt.
mfg Markus
http://linuxwiki.org/DateisystemLabel und http://linuxwiki.org/UUID
--
http://linuxwiki.org/RonnyBuchmann
Wer keine Ahnung
* von Musik
* von Literatur
* vom Leben
hat, ist besser still.
sind diese hiphopper eigentlich überall?
aba das passt jez nich zum thema
Grüsse
zoom
NAME
xfs_admin - change parameters of an XFS filesystem
SYNOPSIS
xfs_admin [ -lu] [ -L label ] [ -U uuid ] device
xfs_admin -f [ -lu] [ -L label ] [ -U uuid ] filename
DESCRIPTION
xfs_admin uses the xfs_db(8) command to modify various parameters of a filesystem.
Devices that are mounted cannot be modified. Administrators must unmount filesystems before xfs_admin or xfs_db can convert parameters. A number of parameters of a mounted filesystem can be examined and modified using the xfs_growfs(8) command.
OPTIONS
-f
Specifies that the filesystem image to be processed is stored in a regular file (see the mkfs.xfs -d file option).
-l
Print the current filesystem label.
-u
Print the current filesystem UUID (Universally Unique IDentifier).
-L label
Set the filesystem label. XFS filesystem labels can be at most 12 characters long; if label is longer than 12 characters, xfs_admin will truncate it and print a warning message. The filesystem label can be cleared using the special ``--'' value for label.
-U UUID
Set the UUID of the filesystem. A sample UUID looks like this: "c1b9d5a2-f162-11cf-9ece-0020afc76f16". The uuid may also be null, which will set the filesystem UUID to the null UUID. The uuid may also be generate, which will generate a new UUID for the filesystem.
The mount(8) manual entry describes how to mount a filesystem using its label or UUID, rather than its block special device name.
SEE ALSO
mkfs.xfs(8), mount(8), xfs_db(8), xfs_growfs(8), xfs(5).
NAME
mkfs.xfs - construct an XFS filesystem
SYNOPSIS
mkfs.xfs [ -b subopt=value ] [ -d subopt[=value] ] [ -i subopt=value ] [ -l subopt[=value] ] [ -n subopt[=value] ] [ -p protofile ] [ -q ] [ -r subopt[=value] ] [ -C ] [ -L label ] device
DESCRIPTION
[...]
-L label
Set the filesystem label. XFS filesystem labels can be at most 12 characters long; if label is longer than 12 characters, mkfs.xfs will not proceed with creating the filesystem. Refer to the mount(8) and xfs_admin(8) manual entries for additional information.
SEE ALSO
mkfs(8), mount(8), xfs_admin(8).
dort steht's nicht mit dabei, naja ist wohl nicht aktuell
--
ronny
Noch schlimmer ist es, wenn die Platten zu RAIDs zusammengefaßt sind.
Die Möglichkeit Labels zu verwenden, löst das sehr elegant.
Für unsere SCSI-Platten setze ich momentan das Tool mapscsi ein, welches beim Bootvorgang aus den Laufwerksdaten, z.B. Hersteller und Seriennummer, ein synthetisches Device generiert, welches dann unabhängig von der Position am SCSI-Bus ist.
Nun erscheinen beim Mounten der platte keinen Daten mehr!
Sind die Daten jetzt für immer weg?
HILFE!
hat zwar net so viel mit dem Thema zu tun aber bei einigen Foren kann mir wohl niemand helfen.
Ich versuche mit mount CD-Images zu mounten und es klappt einfach nicht.
Ich habe folgendes gemacht:
- 2 Verzeichnisse angelegt: Imges und CDS
- die Image in einem Verzeichnis in Images untergebracht
- dann folgenden Befehl als root ausgeführt:
mount -tiso9660 /Images/Orndername/Imagename.img /CDS/Ordnername -o loop
Dabei erhielt ich diese Fehlermeldung:
mount: wrong fs type, bad option, bad superblock on /dev/loop1
or too many mounted filsystems
--> ich habe es mit mehreren Imagetypen probiert also auch die geforderten
ISO-Images
Vielen Dank im Voraus
mfg
Torsten