Timos Blog

Beim Anlegen von ZFS-Speicherpools stellt sich die Frage, ob man ZPOOL die gesamte(n) Disk(s) verwalten lässt (durch Angabe von z.B. c0t0d1 unter Solaris oder /dev/sdb unter Linux) oder den Pool aus einzelnen Partitionen aufbaut (ggf. mit ZFS als einziger Partition auf der Platte).
In letzterem Fall stellt sich außerdem die Frage, welchen Typ von Partitionstabelle man verwenden soll (MBR/DOS-Partitionstabelle, GUID Partition Table (GPT)/EFI Disklabel oder Solaris VTOC).

Insbesondere die zweite Frage ist dann von Bedeutung, wenn man den ZFS-Pool unter verschiedenen Betriebssystemen (z.B. Solaris, Linux und Mac OS X) verwenden möchte.

Diesen beiden Fragen möchte ich im Folgenden versuchen, auf den Grund zu gehen.

• Generell wird empfohlen, die Disks jeweils komplett für ZFS zu verwenden (d.h. man übergibt ZFS entweder das „RAW-Device” oder weist dem ZFS eine Partition zu, die sich über die gesamte Festplatte erstreckt).
• Lässt man zpool das gesamte Gerät verwalten, legt ZFS dort ein GPT-Disklabel an (siehe auch meinen Kommentar)
  (Allerdings entspricht dieses wohl nicht ganz dem, was z.B. Linux erwartet; siehe hier bzw. hier)

• Bei großen Festplatten scheiden DOS-Partitionstabellen und Solaris VTOCs aus:
  • DOS-Partitionstabellen erlauben Partitionen von max. 2 TB Größe
  • Solaris VTOCs unterstützen Festplatten von max. 1 TB Größe

Zu dem Thema habe ich im Folgenden noch etwas „Belegmaterial” zusammengestellt:

Mehr…

Linux, Mac OS X, Solaris disk, EFI, GPT, Linux, Mac OS X, OpenSolaris, Solaris, ZFS

Der NTFS-3G-Treiber ermöglicht es, NTFS-Laufwerke unter Mac OS X zu lesen und zu beschreiben.
Der Treiber ist open-source und kostet daher — im Gegensatz zu vergleichbarer Software unter Mac OS X — nichts.

Computer, Mac OS X Dateisystem, FUSE, HDD, Mac, NTFS, Treiber, Windows

Da ich mich nach wie vor nur schlecht für ein bestimmtes Betriebssystem entscheiden kann, habe ich beschlossen, mich wenigstens auf ein Dateisystem festzulegen ;-).

Meine Wahl ist nun also auf ZFS gefallen, da ich dieses neben (Open)Solaris sowohl unter Linux (mit ZFS-FUSE) als auch unter Mac OS X lesen kann (vielleicht wird mein nächster “PC” ja ein Mac)

ZFS-FUSE in Ubuntu 8.10

Der Eintrag zu ZFS im Ubuntu-Wiki beschreibt die Installation von ZFS-Fuse unter Ubuntu Linux. Diese beschränkt sich hauptsächlich auf das Eintragen der Paketquellen in /etc/apt/sources.list sowie ein apt-get update sowie apt-get install zfs-fuse. Bestehende ZFS-Dateisysteme werden daraufhin automatisch gemountet.

Anlegen des ZFS unter OpenSolaris

Leider habe ich für die Erstellung des ZFS-Pools nur zwei Platten frei. Eine dritte Platte wird erst frei, wenn ich meine Daten von dieser auf den ZFS-Pool verschoben habe.

Von einer OpenSolaris 2008.11 Live-CD erstelle ich den RAID-Z-Pool, der eigentlich aus mindestens drei Disks bestehen müsste, aus zwei Platten und einem genauso großen Sparse-File auf der Festplatte:

jack@opensolaris:~$ pfexec mkfile -nv 1000202305536 /tmp/tera
tera 1000202305536 bytes

jack@opensolaris:~$ pfexec zpool create -f timo raidz c6d0 c6d1 /tmp/tera

jack@opensolaris:~$ pfexec zfs create /timo/daten
jack@opensolaris:~$ pfexec zfs create /timo/musik

jack@opensolaris:~$ zpool status
 pool: timo
 state: ONLINE
 scrub: none requested
config:

	NAME                  STATE     READ WRITE CKSUM
	timo                  ONLINE       0     0     0
	  raidz1              ONLINE       0     0     0
	    c6d0              ONLINE       0     0     0
	    c6d1              ONLINE       0     0     0
	    /tmp/tera         ONLINE       0     0     0

errors: No known data errors

Nach dem Anlegen des Dateisystems nehme ich diese Datei /tmp/tera wieder aus dem Pool heraus (entweder per zpool offline bzw. in diesem Fall per Neustart).

Umkopieren der Daten unter GNU/Linux

Von einer Ubuntu-Installations-Live-CD aus kann ich nun (nach oben beschriebener Installation von ZFS-FUSE) die Dateien vom XFS-Dateisystem auf das neue ZFS umziehen. Der ZFS-Pool hat solange allerdings den Status „DEGRADED”. Später kann ich dann das fehlende /tmp/tera durch die bisherige Datenfestplatte ersetzen:

ubuntu@ubuntu:~$ sudo zpool status
  pool: timo
 state: DEGRADED
status: One or more devices could not be opened.  Sufficient replicas exist for
	the pool to continue functioning in a degraded state.
action: Attach the missing device and online it using 'zpool online'.
   see: http://www.sun.com/msg/ZFS-8000-2Q
 scrub: none requested
config:

	NAME                     STATE     READ WRITE CKSUM
	timo                     DEGRADED     0     0     0
	  raidz1                 DEGRADED     0     0     0
	    sdb1                 ONLINE       0     0     0
	    sdc1                 ONLINE       0     0     0
	    7106139258821418871  UNAVAIL      0     0     0  was /tmp/tera

errors: No known data errors
ubuntu@ubuntu:~$ 

Links

• Eintrag zu ZFS im Ubuntu-Wiki
• ZFS on FUSE/Linux (Blog)
• ZFS on FUSE/Linux (Wiki)
• Filip Brcic’s Ubuntu packages for zfs-fuse.

Computer, Linux, Mac OS X, Solaris FUSE, Linux, Mac, OpenSolaris, Solaris, Ubuntu, ZFS

Bisher residieren meine Daten auf Festplatten mit dem XFS-Dateisystem (SGI XFS | XFS.org Wiki). Dies hat sich bei mir mit etlichen hundert Gigabyte Daten (Fotos, Musik, …) im Einsatz unter Linux sehr gut bewährt.

Notfalls klappt auch ein Zugriff von (beliebigen) anderen Systemen aus (getestet mit Windows und Mac OS X 10.5 „Leopard”), indem ich eine virtuelle Linux-Maschine mit Vollzugriff auf diese Platten einrichte und deren Inhalt per Samba über das Netzwerk anbiete. Leistungsmäßig kann das natürlich nur eine Behelfslösung sein (z.B. eben bei meinen seltenen Ausflügen in die Windows-Welt oder aber, um irgendwann auf ein anderes Dateisystem umzustellen).

So langsam denke ich über eine Modernisierung meiner Rechnerausstattung nach. Dazu gehört auch die Frage nach dem passenden Betriebs- und Dateisystem. Vielleicht lohnt sich — obwohl ich mit meinem Ubuntu Linux sehr zufrieden bin — ein Blick über den Tellerrand.

Da ich (außer einer DVB-S-Karte) kaum irgendwelche spezielle Hardware habe und Windows, wenn überhaupt, hauptsächlich in der VirtualBox benutze, hängt die Frage nach dem Betriebssystem für mich sehr eng mit den unterstützten Dateisystemen zusammen:

• Solaris/OpenSolaris hat natürlich von Haus aus volle Unterstützung für ZFS. Für XFS bleibt nur die o.g. „Behelfslösung”.
• FreeBSD kann ab Release 7 das XFS lesen und hat experimentelle Unterstützung für ZFS.
• Mac OS X 10.5 „Leopard” kann ZFS lesen, Schreibunterstützung ist für Mac OS X 10.6 „Snow Leopard” geplant bzw. kann von MacOSForge „nachgerüstet” werden.

Außerdem gibt es eine Handvoll Programme, die unter dem jeweiligen Betriebssystem laufen sollten:

• OpenOffice.org (Linux, Solaris, Mac OS X)
• TrueCrypt (Linux, Mac OS X)
• VirtualBox (Linux, Solaris, Mac OS X)
• MATLAB (Linux, Mac OS X; Solaris nur auf UltraSPARC)
• NetBeans (Linux, Mac OS X, Solaris, Java)
• LaTeX
• Adobe Reader (Linux, Mac OS X; Solaris nur auf SPARC)
• Adobe Flash Plugin (Linux, Mac, Solaris)

Bei einigen anderen Programmen, die ich regelmäßig benutze, mache ich mir kaum Sorgen, da diese auf etlichen Plattformen verfügbar sind (The GIMP, Pidgin, Mozilla Firefox, …).

Sieht wohl bisher so aus, als ob der Mac das Rennen macht (und dann Linux-Multi-Boot oder Linux in der VirtualBox?). Na ja, mal sehen…

Links

• FUSE - Filesystem in Userspace
• ZFS on FUSE/Linux
• ZFS on Mac OS X

Linux, Mac OS X Computer, Dateisystem, FUSE, Linux, Mac, Mac OS X, OpenSolaris, PC, Solaris, XFS, ZFS

In meinem letzten Beitrag habe ich geschrieben, dass es etwas schöner wäre, wenn man auf den SSH-Tunnel verzichten und QEMU als root ausführen könnte, damit sich dieses an einen Port < 1024 binden kann (eben besagten Port 139 oder 445 für SMB/CIFS).

Meine erste Idee war nun, die Kommandozeilenversion von QEMU, die Q - [kju:] für Mac OS mitbringt, zu verwenden:

sudo /Applications/Q.app/Contents/MacOS/i386-softmmu.app/Contents/MacOS/i386-softmmu -hda linux-image.qcow2

Leider führt dieser Aufruf zu einem Abbruch des Programms mit der Meldung „OpenGL: No pixel format — exiting”.

Da das Fink-Projekt keine Pakete für QEMU anbietet, wollte ich nun mein Glück mit den MacPorts versuchen. Ein sudo port install qemu brach jedoch mit folgender Fehlermeldung ab:

--->  Fetching qemu
--->  Verifying checksum(s) for qemu
--->  Extracting qemu
--->  Applying patches to qemu
--->  Configuring qemu
[...]
Command output: WARNING: "gcc" looks like gcc 4.x
Looking for gcc 3.x
gcc 3.x not found!
QEMU is known to have problems when compiled with gcc 4.x
It is recommended that you use gcc 3.x to build QEMU
To use this compiler anyway, configure with --disable-gcc-check

Error: Status 1 encountered during processing.

Da sudo port install gcc33 auch nicht erfolgreich war, versuchte ich jetzt mein Glück mit einer Anpassung des Portfiles, um dieses um die angegebene Option „--disable-gcc-check” zu ergänzen. Leider führte dies aber auch nicht zu einem Erfolg und QEMU ließ sich mit dieser Option ebenfalls nicht einmal kompilieren.

Also kam ich auf die Idee, es noch einmal mit den QEMU-Quellen und -Patches von Q - [kju:] aus deren SVN-Repository zu versuchen.

Damit habe ich es nun geschafft aus deren Revision 123 ein lauffähiges QEMU 0.9.1 für Mac OS X zu bauen. Dazu verwende ich ein eigenes Build-Skript, welches die Quellen und Patches aus dem SVN auscheckt, den QEMU patcht, konfiguriert und kompiliert sowie installiert und als Binärdistribution (s.u.) in ein Archiv verpackt.

Den QEMU kann ich nun folgendermaßen als priviligierten Daemon im Hintergrund ausführen:

sudo /opt/timo/qemu/bin/qemu -m 256 -hda /Users/timo/qemu/linux-image.qcow2 -hdb /dev/disk1 -hdd /dev/disk2 -nographic -daemonize -redir tcp:2222::22 -redir tcp:139::139 -redir tcp:445::445 -redir udp:445::445

Später kann ich dann die SMB-Freigaben wie gehabt unter Mac OS X einbinden:

mkdir /Volumes/Daten /Volumes/Musik
mount -o noowners -t smbfs "//WORKGROUP;timo@localhost/daten" /Volumes/Daten
mount -o noowners -t smbfs "//WORKGROUP;timo@localhost/musik" /Volumes/Musik

Download

QEMU 0.9.1 für Mac OS X 10.5.4 „Leopard” auf Intel-CPUs (841 KiB)

Mac OS X, Software, Topstory Mac, Mac OS X, QEMU

Wenn ich nun schon Mac OS X, Linux und Windows auf einem System habe, würde ich jetzt natürlich auch ganz gern von von Mac OS auf meine bestehenden Daten zugreifen.

Meine Daten sind über zwei SATA-Festplatten mit XFS-Dateisystem verteilt, eine für Musik und eine für sonstige Daten.

Unter Windows habe ich für diesen Zweck gute Erfahrungen mit coLinux und VirtualBox gemacht. Letzteres gibt es auch für Mac OS, aber unterstützt dort leider nicht den Zugriff auf phys. Festplatten (vielleicht kommt dies ja in einer späteren Version — unter Linux und Windows wird es ja unterstützt).

Meine (zugegebenermaßen nicht sonderlich elegante) Lösung für Mac OS setzt also auf das etwas weniger performante QEMU, bzw. dessen Mac-Variante Q.app. Darin habe ich die Servervariante von Ubuntu Linux 8.04 LTS „Hardy Heron” installiert.

QEMU bekommt nun Zugriff auf z.B. /dev/disk2 als zusätzliches Festplattenlaufwerk (mit der QEMU-Option -hdb /dev/disk2 erscheint diese Platte im Linux-Gast als /dev/sdb). Dieses kann nun im Linux-Gast gemountet und per Samba freigegeben werden.

Q.app gestattet die komfortable Einrichtung von Portweiterleitungen über die grafische Oberfläche. Wenn QEMU nicht als root ausgeführt wird, kann es sich allerdings nicht an Port 139 binden. Stattdessen könnte jedoch z.B. Port 1390 auf dem Wirtssystem an Port 139 auf dem Gastsystem weitergegeben werden. Leider unterstützt das von FreeBSD geerbte mount_smbfs(8) unter Mac OS X im Gegensatz zum entsprechenden Tool mount.cifs(8) aus der Samba-Suite unter Linux nicht die Angabe einer Portnummer, sondern verwendet immer Port 139.

Daher erzeuge ich (was jetzt nicht so elegant ist) einen SSH-Tunnel in die virtuelle Maschine, der den Samba-Server auf dem Wirtssystem zur Verfügung stellt (vorausgesetzt, dort werden nicht schon SMB-Freigaben bereitgestellt):

sudo ssh -c blowfish -p 2200 linuxbenutzer@localhost -L 139:localhost:139

Nun lassen sich die Samba-Shares in Mac OS X von der Kommandozeile aus einhängen (mit Angabe der Server-Adresse im Finder hatte ich leider keinen Erfolg):

mkdir /Volumes/Daten /Volumes/Musik
mount -o noowners -t smbfs "//WORKGROUP;smbbenutzer:smbpasswd@localhost/daten" /Volumes/Daten
mount -o noowners -t smbfs "//WORKGROUP;smbbenutzer:smbpasswd@localhost/musik" /Volumes/Musik

Diese Lösung ist also, wie schon beschrieben, aus mehreren Gründen noch sehr unelegant:

• QEMU ist nicht soo sonderlich schnell
• die Verschlüsselung aller Dateien mit SSH kostet unnötig Performance — dies ließe sich leicht umgehen, indem QEMU priviligiert ausgeführt wird und sich somit an Port 139 binden darf oder durch Verwendung von Netcat, um den Verkehr z.B. von Port 1390 auf Port 139 umzuleiten.
• auf dem lokalen Rechner darf bei dieser Lösung nicht selbst schon ein SMB-Server laufen

Als Quick&Dirty-Hack reicht sie mir aber erstmal. Ich komme an meine Dateien von von XFS-Dateisystemen heran und die Performance reicht für Fotos, Musik und Dokumente locker aus.

Hinweis

Da ich oben schreibe, dass QEMU für diese Lösung nicht sonderlich performant ist, möchte ich an dieser Stelle aber noch erwähnen, dass QEMU als CPU-Emulator gegenüber Virtualisierern wie VirtualBox, VMware oder Parallels durchaus Vorteile hat, wie z.B. dass er im unpriviligierten Anwender-Modus läuft und auch andere Architekturen als die des Wirtssystems emulieren kann.

Nachtrag

Inzwischen habe ich eine QEMU-Version für Mac OS X, die sich als priviligierter Benutzer von der Kommandozeile ausführen lässt: Mehr dazu in diesem Artikel.

Computer, Linux, Mac OS X Mac OS X, QEMU, XFS