Archiv

Artikel Tagged ‘Mac OS X’

ZFS auf Partitionen/Slices oder der ganzen Disk?

5. Mai 2009

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 , , , , , , ,

ZFS Pool (ZPOOL) und ZFS Posix Layer (ZPL) versions

4. April 2009

Mit dem Befehl “zpool upgrade -v” lässt sich eine Liste der vom System unterstützten Pool-Versionen anzeigen:

VER  DESCRIPTION
---  --------------------------------------------------------
 1   Initial ZFS version
 2   Ditto blocks (replicated metadata)
 3   Hot spares and double parity RAID-Z
 4   zpool history
 5   Compression using the gzip algorithm
 6   bootfs pool property
 7   Separate intent log devices
 8   Delegated administration
 9   refquota and refreservation properties
 10  Cache devices
 11  Improved scrub performance
 12  Snapshot properties
 13  snapused property
 14  passthrough-x aclinherit property support
 15  quota support

For more information on a particular version, including supported releases, see:

http://www.opensolaris.org/os/community/zfs/version/N

Ebenso gibt es für den ZFS POSIX Layer einen Befehl “zfs upgrade -v

The following filesystem versions are supported:

VER  DESCRIPTION
---  --------------------------------------------------------
 1   Initial ZFS filesystem version
 2   Enhanced directory entries
 3   Case insensitive and File system unique identifer (FUID)
 4   quota support

For more information on a particular version, including supported releases, see:

http://www.opensolaris.org/os/community/zfs/version/zpl/N

Where 'N' is the version number.

Zusammengefasst sieht die Unterstützung in den verschiedenen Portierungen von ZFS folgendermaßen aus:

OS uname -a ZFS pool version ZFS ZPL version
OpenSolaris 2008.11 Live-CD SunOS opensolaris 5.11 snv_101b [...] 13 3
Ubuntu GNU/Linux 9.04 „Jaunty Jackalope”, zfs-fuse 0.5.1-1ubuntu2 Linux [...] 2.6.28-11-generic #40-Ubuntu SMP Fri Apr 3 17:39:51 UTC 2009 i686 GNU/Linux 13 3
Mac OS X 10.5 (read-only, SNV build 61) 6 1
Mac OS X ZFS synced with Solaris SNV Build 72 8 2
FreeBSD 7.1-RELEASE FreeBSD [...] 7.1-RELEASE [...] 6 1
FreeBSD 8.0 FreeBSD [...] 8.0-CURRENT [...] 13 2

Allgemeines , , , , , , , , , , ,

Auf der Suche nach dem richtigen Datei- und Betriebssystem…

6. März 2009

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

Linux, Mac OS X , , , , , , , , , ,

QEMU unter Mac OS X selbst kompiliert

27. August 2008

QEMU

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 , ,

Zugriff auf Linux-Dateisysteme (XFS, ext2fs, ext3fs, ReiserFS, JFS …) unter Mac OS X

25. August 2008

Tux

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 , ,

Windows XP / Linux / Mac OS X 10.5.4 „Leopard” — Multi-Boot!

20. August 2008

Seit heute habe ich auf meinem Rechner folgende Multi-Boot-Konfiguration im Einsatz:

  • Windows XP
  • Ubuntu Linux 8.04 „Hardy Heron
  • Mac OS X 10.5.4 „Leopard”

Windows und Linux teilen sich dabei die erste SATA-Platte, während die Platte mit Mac OS nachträglich als zweite Platte „angeklemmt” wurde.
Zur Installation war diese aber als einzige SATA-Platte angeschlossen.

Folgender Eintrag in der /boot/grub/menu.lst macht’s möglich:

# Boot Mac OS X from second hard disk
# using boot0 from http://chameleon.osx86.hu/
# http://chameleon.osx86.hu/file_download/6/Chameleon-1.0.11-build.tar.gz
title		Mac OS X 10.5.4 "Leopard" (OSx86)
map		(hd1) (hd0)
rootnoverify	(hd0,4)
chainloader	/boot/mac/boot0

Die Datei boot0 stammt von Chameleon 1.0.11 und wurde von mir in das neu erstellte Verzeichnis /boot/mac/ auf meiner Linux-Boot-Partition (hd0,4) bzw. /dev/sda5 kopiert.

Links

Linux, Software , , , ,