Schlagwörter-Archiv: lvm

Testing TRIM with LUKS on LVM

Veröffentlicht am von — 1 Kommentar ↓

One can find many guides on the net on how to test TRIM using dd and hdparm, which all describe the same procedure:

  • create a random-filled file, sync it to disk
  • determine the LBAs the file resides in using hdparm --fibmap [file]
  • pick one sector, raw-read it with hdparm --read-sector [sector] [device]
  • delete the random file, sync again
  • verify TRIM was issued by reading the same block again, should return only zeroes

The problem with all these guides is that they don’t say anything about the influence partitioning and other layers like LVM can have on the right LBA to use with hdparm --read-sector.
You must add any offsets resulting from either other partitions or payload-offsets from LVM, LUKS and thelike to the address you got from hdparm --fibmap!

I’ll explain the concrete steps using my setup:

[alex@thor ~]$ fdisk -l /dev/sdd
 
Disk /dev/sdd: 128.0 GB, 128035676160 bytes
255 heads, 63 sectors/track, 15566 cylinders, total 250069680 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xddfc7af4
 
   Device Boot      Start         End      Blocks   Id  System
/dev/sdd1   *        2048     1050623      524288   83  Linux
/dev/sdd2         1050624   250069679   124509528   8e  Linux LVM

The PV our target LV resides on starts at sector 1050624, which is our first offset.

[alex@thor ~]$ dmsetup table
root-plain: 0 56619008 crypt aes-xts-plain [keyslot] 0 254:0 4096 1 allow_discards
m4vg0-root: 0 55050240 linear 8:50 2048
(...)

Here we can see that LVM has a payload offset of 2084 bytes and LUKS (dm-crypt) one of 4096 bytes (fits well for an SSD).

[alex@thor usr]$ hdparm --fibmap testfile
 
testfile:
 filesystem blocksize 4096, begins at LBA 0; assuming 512 byte sectors.
 byte_offset  begin_LBA    end_LBA    sectors
           0     272600     272607          8

So finally we calculate the “real” address of our chosen sector (the first one) by 272600 + 1050624 + 2048 + 4096 = 1329368.

Happy TRIM-testing, and keep in mind the implications for crypto-recurity!

(Massen)Speicher-Hierarchie

Veröffentlicht am von — Keine Kommentare ↓

Der Füllstand meines Archiv-Volumes nähert sich der 100%-Marke und ich mache mir Gedanken über eine weitere Platte, ein Hardware-RAID oder agressivere Aufräumarbeiten an den Daten :)

Beim Versuch, “mal schnell” einen Überblick über die vorhandenen Partitionen und deren Auslastung zu bekommen, verhedderte ich mich in meinem recht… speziellen Storage-Setup, was mich dazu veranlasst hat, mal ein Diagramm zu erstellen:

(Massen)Speicher-Hierarchie

Vielleicht bringt es ja jemandem Inspiration bei der Konzeption des eigenen Setups.

Der vielschichtige Teil auf der Primärplatte kommt dadurch zustande, dass ich einen verschlüsselten root haben wollte (wegen der Passwörter, etc.), Partitionen für /usr, /opt, etc. aber unverschlüsselt bleiben sollten.

Auf den beiden Storage-Platten habe ich den etwas ungewöhnlichen Ansatz gewählt, den LUKS-Layer unter die LVM-PVs zu legen, um bei einer Erweiterung um eine neue Platte nur das LV und ihr Dateisystem vergrößern zu müssen, nicht auch noch den LUKS-Layer.

LVM Änderungen in Arch

Veröffentlicht am von — Keine Kommentare ↓

Wer wie ich gerade nach einem Update die Maschine hochfährt und die Welt nicht mehr versteht, weil beim Booten (fast) keine Partition gefunden wird, hat vielleicht ein LVM-Setup und sollte seine Pfade überprüfen:

Bisher wurden Volume-Groups nämlich als Verzeichnis unter /dev angeboten, der Pfad des Volumes Vol1 auf Group1 als /dev/Group1/Vol1. Nun jedoch ist der Ordner für die VG weg und die Volumes landen in /dev/mapper, im Beispiel als /dev/mapper/Group1-Vol1.

Fröhliches fstabben ;)

Partitions-Desaster

Veröffentlicht am von — Keine Kommentare ↓

Frisch zurück aus dem Urlaub und direkt wieder am Basteln ^^  Seit geraumer Zeit war ich am Überlegen, meinem Arch-System einen richtigen Fallback-Kernel zu verpassen, d.h. nicht nur eine eigene initrd sondern einen kompletten Kernel inkl. Modulen.
Dabei stieß ich auf kernel26-lts. Leider scheitert die ganze Sache allerdings nun an meiner Partitionierung:

partitioning

Partitionierung (schematisch)

Beim Aufsetzen des Systems hatte ich keinen zweiten Kernel, besser gesagt keinen zweiten Modulbaum, vorgesehen und die root-Partition dementsprechend klein gehalten. /lib (und damit die Module) liegen nun leider auf diesem gerade mal ~200MB großen Fleck digitalen Landes auf meiner Platte, und selbige müsste mindestens 25MB größer werden, um die zusätzlichen Module aufnehmen zu können.
Abgesehen davon, dass die Partition dann so gut wie voll wäre (und ein volles / ist sicher keine gute Sache…), bleibt als einzige vernünftige Quelle für den zusätzlichen Platz mein LVM-Setup. 7 Logical Volumes, eins davon LUKS-verschlüsselt, müssten also verkleinert und verschoben werden, bevor dann die (natürlich auch verschlüsselte) root-Partition wachsen könnte. Natürlich alles jeweils auf Dateisystem- und Partitions-/Volumeebene :) – a lot of fun.

Ob dieser Aufwand die zusätzliche Sicherheit eines Fallback-Kernels wert ist… (to be continued)

Update: Verblendet von dem ganzen LVM-Kram habe ich die wesentlich einfachere Lösung übersehen: den benötigten Platz vom NTFS-Volume zu klauen! Also NTFS verkleinern und nach rechts verschieben, die ganze LVM-Partition per dd sichern, neu anlegen und wiederherstellen, und schließlich root vergrößern. Alles lief reibungslos und ich habe endlich meinen Fallback-Kernel (kernel26-lts) :)

Fedora 11 und Vista SP2 parallel

Veröffentlicht am von — 1 Kommentar ↓

Kurzfassung: Windows Vista verträgt sich sowohl bei der Basisinstallation als auch bei der Installation des SP2 offenbar nicht mit LVM-Setups.

Die ganze Geschichte: Kürzlich kam ich in Verlegenheit, einem mit einer Fedora 11 verheirateten Vista Business das Service Pack 2 zu verpassen. Der Auftrag schien trivial, alles schon x mal gemacht. Überraschender weise ließ sich das SP2 jedoch absolut nicht zur Kooperation überreden und scheiterte immer nach dem Reboot im Abschnitt 3 mit dem “unbekannten Fehler” 80096004.
Nach etlichen gelesenen Knowledgebase-Artikeln und erfolglosen Fummlereien wie dem Umbenennen von system32\catroot2 versuchte ich eine Neuinstallation von Vista, welche aber ebenfalls scheiterte: alle Platten wurden gefunden, die Zielpartition konnte formatiert werden, aber beim Bestätigen wurde “kein Systemvolume gefunden, das den Anforderungen entspricht”. Ein letzter Versuch mit komplett eliminierter Partitionstabelle und somit leerer Platte brachte dann die scheinbare Ursache ans Tageslicht:
Es lag nicht an SATA/RAID, nicht an irgendwelchen fehlenden Treibern oder einem defekten Installationsmedium, sondern an der Fedora-Installation, mit dessen LVM-Setup sich Windoof anscheinend nicht verträgt. Ein Versuch mit einer nicht-LVM-Installation funktionierte jedenfalls einwandfrei.
Das SP2 ließ sich dann übrigens auch installieren :)

Genervt von der Tatsache, dass man in der Windowswelt schon nach Zusatz-Software suchen muss, um ein einfaches .iso auf eine Scheibe zu backen, um ein neues Installationsmedium zu erhalten, war es dann noch ein weiteres “Highlight”, dass die gefundene und viel gepriesene Software zu doof war, das Brennen eines DVD+R Rohlings mit einem ausschließlichen DVD-R Brenner zu verweigern und stattdessen Defekte im Recorder meldete.

Ein weiteres Kapitel mit der Überschrift: “Warum ich mir nicht vorstellen kann, wieder zu Windows zu wechseln”…