FreeBSD: Partitionieren & Div. Fragen (SSD, Release etc.)

Ryudo

Active Member
Hallo

Ich habe jetzt FreeBSD 8.2 Stable auf meinem Acer Aspire 8930 seid ca. 1 Monat am rennen, gestern habe ich eine Corsair P128 SSD neben meiner alten Seagate HDD ins Notebook eingebaut.

Jetzt stellts sich mir die Frage, ich möchte FreeBSD auf der SSD neuinstallieren, nehme ich da lieber das 8.2er Release oder kann man schon unbedenklich auf die FreeBSD 9 RC2 wechseln.
Soviel ich weiss, soll ja mind. noch ein weiterer RC. released werden, was wäre hier also die beste entscheidung?

Die Zweite Frage, die sich mir stellt ist, wie Partitioniere ich am besten die SSD & HDD richtig, ich habe mir dazu folgendes vorgestellt:

/ auf SDD
/home /var /tmp auf die HDD

bei /usr bin ich mir unschlüssig ob ich die auf die SSD oder auf die HDD schieben soll.
Eine weitere Frage die sich mir stellt, wo landen die Temporäre Dateien bez. Ports kompilieren, die gehen nehme ich mal unter /var & /tmp?

Wäre froh wenn man mir die Fragen beantworten kann, würde gerne heute noch die Installation beginnen.

Gruss Ryduo

PS: schönes Wochenende! ;)
 
Im Zweifel würde ich den RC2 nehmen. Die Unterschiede zwischen RC2, RC3 und dem RELEASE werden sehr gering sein, wahrscheinlich sind die letzten beiden sogar gleich. Natürlich unter der Voraussetzung, dass keine kritischen Fehler gefunden werden, aber das wird eher nicht passieren. Der Wechsel von RC2 auf RC3 und dann auf das RELEASE ist mit freebsd-update auch sehr einfach möglich und sollte kaum Aufwand sein...

Das mit den Dateisystemen ist Glaubenssache. Ich stehe auf dem Standpunkt, dass SSD gebaut wurden um genutzt zu werden und habe daher das ganze System ohne Rücksicht auf Verluste darauf geschrieben. Seine 3 Jahre wird es halten und länger sollte man meiner Meinung nach auch Festplatten nicht nutzen, wenn seine Daten einem lieb sind... Aber wie dem auch sei: Im Zweifel halt alles auf die SSD was hauptsächlich gelesen wird, alles andere auf die Festplatte. Wohin die Ports ihre Arbeitsdaten speichern, kann man in der 7etc/make.conf angeben, die Standardeinstellung ist nach /usr/ports/kategorie/portname/work.
 
dazu fällt meine Antwort unorthodox aus:
wenn du es nicht schon weißt, dann lass es ganz!

Das hört sich dramatischer an, als ich es dann meine.
Aber, du musst ja nicht partitionieren.
Damit will ich die Diskussion um den Sinn oder Unsinn von mehreren Partitionen nicht beleben. Dazu finden sich in diesem Forum eine Reihe von Beiträgen. Aber grundsätzlich fand ich meine Haltung immer wieder bestätigt: wer etwas bestimmtes damit im Sinn hat, der weiß auch schon, wie er partitionieren möchte und wer das ohnehin nicht weiß, der braucht sich auch keinen Knoten ins Hirn zu machen und kann es einfach sein lassen.
Für ein Notebook gibt es eine einzige zusätzliche Partition, die ich empfehlen möchte und das ist die für SWAP. Die muss auch nicht sein und es kann natürlich auch ein SWAP-File benutzt werden, das aber nur vom laufenden System erreicht werden kann. Evtl Dumps oder Hibernate-Informationen, die im SWAP landen sollen, sind besser auf einer Partition aufgehoben. Zudem ist diese Partition für SWAP gemessen an der Größe der heutigen Festplatten klein und bedeutet nicht wirklich eine Einschränkung. Sie später noch einzurichten ist schwierig, deshalb möchte ich die von Anfang an empfehlen.

Alles andere (wie gesagt, für den Fall, dass du eh keinen Plan davon hast), kann auf einer einzigen Partition landen und bringt dir keine Nachteile.
Die zweite Platte kann ebenfalls als einzige Partition genommen werden.
Willst du später Dateien verteilen, kannst du das mit zusätzlichen mountpoints und evtl md- Devices erledigen oder einfach mit Links.
Ob das Sinn macht, ist eine andere Frage.
Zum Beispiel bist du ja nicht gezwungen, Daten im /usr/home/user abzulegen. Du kannst ja dafür sorgen, dass hier nicht endlos viel Müll landet. Hast du eine Musiksammlung oder eine Reihe von Filmen, legst die einfach auf deine HDD unter /mein_HDD_mountpoint/Filme und /mein_HDD_mountpoint/Musik und vergibst die passenden Rechte. Willst die Verzeichnisse unter /usr/home/user "sehen", legst du Links an.
Wenn du für Filme und Musik direkt jeweils eine Partition nimmst, kannst du hier schnell an die Grenzen dieser Partitionen stoßen und hast damit weniger Möglichkeiten, dich auszutoben. Wenn Musik nur wenige GB groß gewählt wurde und nun die nächste CD dorthin soll, kann die Partition bereits vollgelaufen sein und damit das Speichern scheitern, obwohl du unter Filme vielleicht noch 100GB zusätzlich frei hast. Naja, du weißt schon, wie ich das meine.

Das tempfs ist zwar offiziell mit Vorsicht zu genießen, aber in der Praxis sehr gut zu gebrauchen. Besonders bei SSD willst du unnötige Schreibzyklen vermeiden und wählst ein Dateisystem ohne Journals und mountest auch noatime. Wenn du dann noch ausreichend Speicher hast und ein tempfs anlegst, kannst du 7tmp und /var/tmp und ähnliches hier gut unterbringen.


Mein letzter Versuch mit einem 9-RC1 auf einem kleinen Asus EEE sah gut aus. RC2 kann eigentlich nur empfohlen werden. Und dann sieh mal http://de.wikipedia.org/wiki/TRIM
 
Danke euch beiden, ich bin wie gesagt kein Neuling im UNIX Bereich, bin 1 Jahr mit Archlinux und 1,5 Jahre mit Gentoo bis jetzt gefahren.
Worauf ich hinauswollte ist, ob es sonst irgend einen speziellen unterschied zwischen BSD und bsp. Gentoo & Linux Allg. in der Verzeichnisstruktur gibt.

Unter Gentoo sah meine Partitionierung folgendermassen aus:

SSD:
/boot, /, /var

Platte 1, 2 etc.:
/home, /var/log, /tmp, /usr/portage ( Portage Tree), Rest auf andere Mountpoints; Filme, Musik etc.!

Backup läuft auf einem NAS, dann habe ich noch eine externe 320GB Festplatte. ;)

@pit234a
Das mit Trim ist mir bekannt, hab mich diesbezüglich unter FreeBSD schon eingelesen!

Ich werd mein FreeBSD dann folgendermassen partitionieren:

SSD:
/boot, /, /var

Festplatte:
/home, /usr/ports, /tmp, swap, /var/tmp, /var/log <- muss mal schauen, evt. ziehe ich /var gleich komplett auf die Festplatte, dann bleibt mir das rumpartitionieren mit x Mountpoints erspart.

Alles userbezogenes (Filme, Musik speichere ich unter /home) sehe da keinen Vorteil von externen Partitionen, wobei ich eh 1x im Monat ein Backup mache, von daher sollte das so optimal sein.

Gruss
 
Zuletzt bearbeitet:
es gibt ein paar Unterschiede zu diversen GNU/Linux Distros, wie weit das die von dir genannten anbelangt, weiß ich nun nicht.
FreeBSD versucht ziemlich konsequent System und third-Party zu trennen.
Deshalb landet vieles unter /usr/local, was du doch wegen schnelleren Programmstarts vielleicht auf der SSD haben möchtest. Du schreibst das nicht explizit, aber es könnte ja sein, dass du das anders haben wolltest.

Vielleicht hilft das, vielleicht auch nicht:
Code:
pit@eee /:-> tree -d -C -A -L 3
.
├── bin
├── boot
│   ├── defaults
│   ├── firmware
│   ├── kernel
│   ├── kernel.old
│   ├── modules
│   └── zfs
├── compat -> usr/compat
├── dev
│   ├── dri
│   ├── fd
│   ├── pts
│   └── usb
├── etc
│   ├── X11
│   ├── bluetooth
│   ├── defaults
│   ├── devd
│   ├── fonts
│   ├── gnats
│   ├── gss
│   ├── mail
│   ├── mtree
│   ├── namedb -> ../var/named/etc/namedb
│   ├── ntp [error opening dir]
│   ├── pam.d
│   ├── periodic
│   │   ├── daily
│   │   ├── monthly
│   │   ├── security
│   │   └── weekly
│   ├── ppp
│   ├── rc.d
│   ├── security
│   ├── skel
│   ├── ssh
│   ├── ssl
│   └── zfs
├── home -> usr/home
├── lib
│   └── geom
├── libexec
│   └── resolvconf
├── media
├── mnt
│   ├── E-Filme
│   ├── smbpit
│   └── usb
├── proc
│   ├── 0
│   ├── 1
│   ├── 10
│   ├── 11
│   ├── 11629
│   ├── 11630
│   ├── 12
│   ├── 13
│   ├── 1306
│   ├── 14
│   ├── 15
│   ├── 16
│   ├── 17
│   ├── 1778
│   ├── 18
│   ├── 1842
│   ├── 1865
│   ├── 1930
│   ├── 1939
│   ├── 2
│   ├── 2006
│   ├── 2007
│   ├── 2008
│   ├── 2009
│   ├── 2010
│   ├── 2011
│   ├── 2012
│   ├── 2013
│   ├── 2014
│   ├── 2017
│   ├── 2022
│   ├── 2024
│   ├── 2026
│   ├── 2028
│   ├── 2029
│   ├── 2036
│   ├── 2156
│   ├── 2197
│   ├── 2208
│   ├── 2231
│   ├── 2441
│   ├── 2443
│   ├── 2449
│   ├── 2619
│   ├── 3
│   ├── 4
│   ├── 469
│   ├── 5
│   ├── 6
│   ├── 7
│   ├── 7442
│   ├── 7443
│   ├── 7883
│   ├── 7886
│   ├── 7887
│   ├── 8
│   ├── 9
│   ├── 92781
│   ├── 99597
│   ├── 99598
│   ├── 99623
│   └── curproc -> 11630
├── rescue
├── root
│   ├── Desktop [error opening dir]
│   ├── usb
│   └── usb2
├── sbin
├── tmp
│   ├── 0366939862 [error opening dir]
│   ├── fam-pit
│   ├── fam-root [error opening dir]
│   ├── kde-pit
│   ├── ksocket-pit
│   │   └── artsd-samples
│   └── pulse-czxaLN6zIhmk
├── usb2
│   └── DCIM
│       ├── 649CANON
│       ├── 650CANON
│       └── 651CANON
├── usr
│   ├── X11R6 -> /usr/local
│   ├── bin
│   ├── compat
│   │   └── linux
│   ├── games
│   ├── home
│   │   ├── gast
│   │   └── pit
│   ├── include
│   │   ├── altq
│   │   ├── arpa
│   │   ├── bsm
│   │   ├── bsnmp
│   │   ├── c++
│   │   ├── cam
│   │   ├── clang
│   │   ├── crypto
│   │   ├── dev
│   │   ├── edit
│   │   ├── fs
│   │   ├── gcc
│   │   ├── geom
│   │   ├── gnu
│   │   ├── gpib
│   │   ├── gssapi
│   │   ├── infiniband
│   │   ├── isofs
│   │   ├── kadm5
│   │   ├── libmilter
│   │   ├── lwres
│   │   ├── lzma
│   │   ├── machine
│   │   ├── net
│   │   ├── net80211
│   │   ├── netatalk
│   │   ├── netgraph
│   │   ├── netinet
│   │   ├── netinet6
│   │   ├── netipsec
│   │   ├── netipx
│   │   ├── netnatm
│   │   ├── netncp
│   │   ├── netsmb
│   │   ├── nfs
│   │   ├── nfsclient
│   │   ├── nfsserver
│   │   ├── openssl
│   │   ├── pcap
│   │   ├── protocols
│   │   ├── rdma
│   │   ├── readline
│   │   ├── rpc
│   │   ├── rpcsvc
│   │   ├── security
│   │   ├── ssp
│   │   ├── sys
│   │   ├── ufs
│   │   ├── vm
│   │   └── x86
│   ├── lib
│   │   ├── aout
│   │   ├── compat
│   │   ├── dtrace
│   │   ├── engines
│   │   └── i18n
│   ├── lib32
│   │   ├── dtrace
│   │   └── i18n
│   ├── libdata
│   │   ├── gcc
│   │   ├── ldscripts
│   │   └── lint
│   ├── libexec
│   │   ├── bsdinstall
│   │   ├── lpr
│   │   ├── sendmail
│   │   └── sm.bin
│   ├── local
│   │   ├── bin
│   │   ├── env
│   │   ├── etc
│   │   ├── i386-portbld-freebsd8.0
│   │   ├── include
│   │   ├── info
│   │   ├── lib
│   │   ├── libdata
│   │   ├── libexec
│   │   ├── live
│   │   ├── man
│   │   ├── modules
│   │   ├── openjdk7
│   │   ├── sbin
│   │   ├── share
│   │   ├── src
│   │   ├── translations
│   │   └── www
│   ├── obj
│   ├── ports
│   │   ├── Mk
│   │   ├── Templates
│   │   ├── Tools
│   │   ├── accessibility
│   │   ├── arabic
│   │   ├── archivers
│   │   ├── astro
│   │   ├── audio
│   │   ├── benchmarks
│   │   ├── biology
│   │   ├── cad
│   │   ├── chinese
│   │   ├── comms
│   │   ├── converters
│   │   ├── databases
│   │   ├── deskutils
│   │   ├── devel
│   │   ├── distfiles
│   │   ├── dns
│   │   ├── editors
│   │   ├── emulators
│   │   ├── finance
│   │   ├── french
│   │   ├── ftp
│   │   ├── games
│   │   ├── german
│   │   ├── graphics
│   │   ├── hebrew
│   │   ├── hungarian
│   │   ├── irc
│   │   ├── japanese
│   │   ├── java
│   │   ├── korean
│   │   ├── lang
│   │   ├── mail
│   │   ├── math
│   │   ├── misc
│   │   ├── multimedia
│   │   ├── net
│   │   ├── net-im
│   │   ├── net-mgmt
│   │   ├── net-p2p
│   │   ├── news
│   │   ├── packages
│   │   ├── palm
│   │   ├── polish
│   │   ├── ports-mgmt
│   │   ├── portuguese
│   │   ├── print
│   │   ├── russian
│   │   ├── science
│   │   ├── security
│   │   ├── shells
│   │   ├── sysutils
│   │   ├── textproc
│   │   ├── ukrainian
│   │   ├── vietnamese
│   │   ├── www
│   │   ├── x11
│   │   ├── x11-clocks
│   │   ├── x11-drivers
│   │   ├── x11-fm
│   │   ├── x11-fonts
│   │   ├── x11-servers
│   │   ├── x11-themes
│   │   ├── x11-toolkits
│   │   └── x11-wm
│   ├── sbin
│   ├── share
│   │   ├── calendar
│   │   ├── dict
│   │   ├── doc
│   │   ├── examples
│   │   ├── games
│   │   ├── groff_font
│   │   ├── i18n
│   │   ├── info
│   │   ├── locale
│   │   ├── man
│   │   ├── me
│   │   ├── misc
│   │   ├── mk
│   │   ├── nls
│   │   ├── openssl
│   │   ├── pc-sysinstall
│   │   ├── security
│   │   ├── sendmail
│   │   ├── skel
│   │   ├── snmp
│   │   ├── syscons
│   │   ├── tabset
│   │   ├── tmac
│   │   ├── vi
│   │   └── zoneinfo
│   └── src
└── var
    ├── account
    ├── agentx
    ├── at
    │   ├── jobs
    │   └── spool
    ├── audit [error opening dir]
    ├── backups
    ├── cache
    │   ├── PackageKit
    │   ├── cups
    │   ├── gdm
    │   └── hald
    ├── crash
    ├── cron
    │   └── tabs
    ├── db
    │   ├── dbus
    │   ├── entropy
    │   ├── fontconfig
    │   ├── freebsd-update
    │   ├── ipf
    │   ├── mysql
    │   ├── pkg
    │   ├── portaudit
    │   ├── ports
    │   ├── portsnap
    │   ├── rarian
    │   ├── samba4
    │   └── uma
    ├── empty
    ├── games
    ├── gdm [error opening dir]
    ├── heimdal [error opening dir]
    ├── lib
    │   ├── DeviceKit-power
    │   ├── PackageKit
    │   ├── PolicyKit
    │   ├── PolicyKit-public
    │   ├── dbus
    │   ├── hal
    │   ├── kdm
    │   ├── misc
    │   ├── polkit-1
    │   ├── rpm
    │   └── xkb
    ├── log
    │   └── ConsoleKit
    ├── mail
    ├── msgs
    ├── named
    │   ├── dev
    │   ├── etc
    │   └── var
    ├── preserve
    ├── run
    │   ├── ConsoleKit
    │   ├── cups
    │   ├── dbus
    │   ├── hald
    │   ├── resolvconf
    │   ├── xauth
    │   └── xdmctl
    ├── rwho
    ├── spool
    │   ├── clientmqueue
    │   ├── cups
    │   ├── lock
    │   ├── lpd
    │   ├── mqueue
    │   ├── opielocks
    │   ├── output
    │   └── spamd
    ├── tmp
    │   ├── kdecache-gast
    │   ├── kdecache-pit
    │   ├── kdecache-root
    │   ├── orbit-gast
    │   ├── orbit-pit
    │   ├── portupgradeNb43C0Hp
    │   ├── portupgradesIpTMp0A
    │   ├── texfonts
    │   └── vi.recover
    └── yp
Der Übersicht halber habe ich die Tiefe der Ausgabe begrenzt, naja, die Farben der Ausgabe kommen hier natürlich so nicht an. Das stammt von einem Bastel-System, einem Asus EEE auf dem ich eben mal das 9-RC2 aufgespielt habe und nun dabei bin, einiges neu zu machen. Nicht alles wird zu deinem zukünftigen System passen.
Solange du noch kein System installiert hast, kannst du die Man-Pages hier lesen:
http://www.freebsd.org/cgi/man.cgi?...th=FreeBSD+9-current&arch=default&format=html
das ist sicher eine bessere Hilfe.
 
@pit234a
Eine Frage habe ich noch, muss ich die externen Partitionen wie /var, /var/tmp und /tmp etc. in die /etc/fstab bzw. in die rc.conf eintragen?
Und wie sieht das mit der berechtigung bezüglich chmod und /var/tmp /tmp unter freebsd aus, macht das der FreeBSD installer automatisch?

Dann ist noch die Sache mit den Soft Updates & Journaling, macht meiner Meinung nach keinen sinn auf einer /tmp Partition, liege ich da richtig?

EDIT:

Partition Schema sieht derzeigt wie folgt aus:

SSD ada0 120GB:
ada0p1 64KB freebsd-boot
ada0p2 119GB freebsd-ufs SU+SUJ+TRIM

HDD ada1 320GB:
ada1p1 4GB freebsd-swap none
ada1p2 220GB freebsd-ufs /home SU+SUJ
ada1p3 25GB freebsd-ufs /var SU+SUJ
ada1p4 25GB freebsd-ufs /var/tmp SU+SUJ
ada1p5 24GB freebsd-ufs /tmp SU+SUJ
 
Zuletzt bearbeitet:
@pit234a
Eine Frage habe ich noch, muss ich die externen Partitionen wie /var, /var/tmp und /tmp etc. in die /etc/fstab bzw. in die rc.conf eintragen?
Und wie sieht das mit der berechtigung bezüglich chmod und /var/tmp /tmp unter freebsd aus, macht das der FreeBSD installer automatisch?

Dann ist noch die Sache mit den Soft Updates & Journaling, macht meiner Meinung nach keinen sinn auf einer /tmp Partition, liege ich da richtig?

Den "neuen" Installer, wie er nun bei dem 9er dabei ist, den kenne ich noch nicht ausreichend.
"Externe Partitionen" gibt es nicht, das könnten allenfalls Netzwerkfreigaben sein.
Wenn ich mich recht entsinne, werden die Partitionen, die bei der Installation angelegt werden, automatisch in die /etc/fstab eingetragen. Sollte dies nicht automatisch erfolgen, müsstest du sie natürlich manuell einpflegen und evtl die Dateien dorthinein verschieben.
Damit, dass ich sage: "es gibt keine externen Partitionen", spiele ich darauf an, dass alles wie eingebaute Festplatten behandelt wird. Also etwa auch ein angesteckter USB-Stick. Das kann natürlich evtl später zu Konfusion führen, weil ein Stick vielleicht nicht da oder an einem anderen Eingang steckt oder einfach eine andere device-ID bekommt. Um das besser in den Griff bekommen zu können, kannst du dann in der fstab auch die Einträge der zugewiesenen UUID des Filesystems benutzen. Dazu findet sich auch einiges hier.

Weil ich den gerade noch dran habe, hier noch die Ausgabe des Spiel-Systems auf dem EEE:
Code:
pit@eee ~:-> cat /etc/fstab
# Device                Mountpoint              FStype  Options         Dump    Pass#
/dev/ad4s1a             /                       ufs     rw              1       1
tmpfs                   /tmp                            tmpfs           rw,mode=1777    2       0
tmpfs                   /var/run                        tmpfs           rw,mode=1777    2       0
tmpfs                   /var/log                        tmpfs           rw,mode=1777    2       0
linproc                 /compat/linux/proc/             linprocfs       rw              0       0
linsysfs                /usr/compat/linux/sys           linsysfs        rw              0       0
proc                    /proc                           procfs          rw
da will ich vor allem auf die Möglichkeit mit tmpfs hinweisen, das lohnt sich echt bei einem Notebook und bei SSD.
und noch dies:
Code:
pit@eee ~:-> tunefs -p /dev/ad4s1a
tunefs: POSIX.1e ACLs: (-a)                                disabled
tunefs: NFSv4 ACLs: (-N)                                   disabled
tunefs: MAC multilabel: (-l)                               disabled
tunefs: soft updates: (-n)                                 disabled
tunefs: soft update journaling: (-j)                       disabled
tunefs: gjournal: (-J)                                     disabled
tunefs: trim: (-t)                                         enabled
tunefs: maximum blocks per file in a cylinder group: (-e)  2048
tunefs: average file size: (-f)                            16384
tunefs: average number of files in a directory: (-s)       64
tunefs: minimum percentage of free space: (-m)             8%
tunefs: optimization preference: (-o)                      time
tunefs: volume label: (-L)                                 FreeBSD

edit: die Einträge in der /etc/fstab dienen dem automatischen Mount verfügbarer Dateisysteme. Sind diese Dateisysteme nicht zur Bootzeit verfügbar, kann das System hängen bleiben. Deshalb empfiehlt sich dann die Anwendung von mount-Scripts, die natürlich auch andere Festplatten (zusätzliche Dateisysteme) automatisch bei Vorhandensein einbinden können. Es gibt dazu die Möglichkeit eines sehr einfachen scriptes oder auch fertige Helfer, die auch Wechelmedien "on-the-fly" mounten können. Da nenne ich etwa den automounter von Kamikaze oder die komplexen Anwendungen, wie sie unter KDE3 oder GNOME2 mit Hilfe von HAL aufgebaut sind (KDE4 und GNOME3 kenne ich nicht).
 
Zuletzt bearbeitet:
@pit234a

SSD ada0 120GB:
ada0p1 64KB freebsd-boot
ada0p2 119GB freebsd-ufs TRIM

HDD ada1 320GB:
ada1p1 4GB freebsd-swap none
ada1p2 220GB freebsd-ufs /home SU+SUJ
ada1p3 25GB freebsd-ufs /var SU+SUJ
ada1p4 25GB freebsd-ufs /var/tmp SU+SUJ
ada1p5 24GB freebsd-ufs /tmp SU+SUJ

Müsste so dann ok sein, werd es nachträglich nach der installation noch überprüfen.

PS: Damit wir uns nicht missverstehen ich meinte mit ext. Partition alles was nicht auf die SSD gehört auf die 2te interne Festplatte im Notebook auszulagern! ;)

EDIT:

Installation verlief problemlos, steht alles richtig in der /etc/fstab drin.
 
Zuletzt bearbeitet:
SSD ada0 120GB:
ada0p1 64KB freebsd-boot
ada0p2 119GB freebsd-ufs TRIM

Sorry, habe ich eben erst gesehen und nun hast du das ja alles eh schon gemacht.
Wenn freebsd-boot = /boot ist, dann könnte das eng werden und besonders, wenn du mal mit unterschiedlichen Kerneln spielen willst.
Sieh dir mal die Ausgabe von meinem laufenden System an, einem AMD64
Code:
senyo# du -d 0 -h /boot /usr/home /tmp /var /var/tmp
266M    /boot
 32G    /usr/home
5,9M    /tmp
2,4G    /var
755M    /var/tmp
Du siehst, was ich meinte? Du nimmst für /var /tmp und /var/tmp jeweils ca 25G und belegst die damit. Das bringt keine Vorteile. Der Platz auf der Platte ist damit blockiert, festgeschrieben und kann nicht dynamisch genutzt werden.
Nicht, dass du bei der Plattengröße, die du hier hast tatsächlich sparsam sein müsstest. Aber Vorteile hat es eben auch nicht, es sei denn, du möchtest da explizit ein bestimmtes Filesystem benutzen (etwa mit Verschlüssellung oder hinsichtlich späterer Freigaben).
Alternativ hättest du ja (nur als Beispiel) die HDD als eine Partition anlegen können, die dann irgendwohin mounten (über die fstab) und dann Verzeichnisse über Links in dein System legen können. Also etwa: /dev/ada1p2 /platte2 und dann anlegen /platte2/var /platte2/var/tmp etc und dann mv /var/tmp/* /platte2/var/tmp etc und dann rm -rf /var/tmp ... und dann ln -s /platte2/var/tmp /var/tmp. Wie gesagt, nur als Beispiel um zu verdeutlichen, was ich meine.
Dann hättest du nicht eine eigene Partition gebraucht aber trotzdem die entsprechenden Verzeichnisse auf die HDD ausgelagert und die hätten dort nicht unnötig viel Platz durch übergroße Partitionen belegt, sondern wären eben dynamisch gewachsen und fertig.

Wie gesagt, die Diskussion wollte ich hier nicht führen. Es gibt gute Gründe dafür, mehrere Partitionen nutzen zu wollen und wer das tut, weiß das in der Regel auch und wer es nicht weiß, macht meist keinen Fehler, wenn er es bleiben lässt. Die Hauptgründe, die früher für das Partitionieren sprachen sind inzwischen Vergangenheit und besonders bei Einsatzzwecken eines Systems für einen Desktop-Rechner, speziell für Notebooks und Netbooks, da empfinde ich viele Partitionen nicht angesagt und eher störend. Aber ich schalte da auch alle Logs ab, wenn das System läuft und das ist eben meine persönliche Entscheidung. Andere sehen das anders und haben andere Schwerpunkte.

So long.
 
SSD ada0 120GB:
ada0p1 64KB freebsd-boot
ada0p2 119GB freebsd-ufs TRIM

Sorry, habe ich eben erst gesehen und nun hast du das ja alles eh schon gemacht.
Wenn freebsd-boot = /boot ist, dann könnte das eng werden und besonders, wenn du mal mit unterschiedlichen Kerneln spielen willst.

Er benützt GPT, somit benötigt es noch eine freebsd-boot Partition für den Bootloader. 64k ist dort schon angemessen.
/boot liegt dann auf ada0p2.

Mit dem Alignment der UFS-Partition an die unterliegenden Flashspeicher könnte es einen Performancegewinn bringen. Für / ist das wohl unnötig.

https://forums.freebsd.org/showthread.php?t=19093

Seit FreeBSD-9 gibt es auch die alignment Option für gpart add.
Code:
               -a alignment  If specified, then gpart utility tries to align
                             start offset and partition size to be multiple of
                             alignment value.
 
@pit234a
Nukama hat es richtig angedeutet, ich verwende GPT, die 64KB Partition ist für den FreeBSD Bootloader, ada0p2 wäre dann das Wurzelverzeichniss.
Ok Jetzt gibt mir dein Kommentar schon ein bisschen zu denken, ich hab FreeBSD bisher nur frisch aufgesetzt und noch nichts konfiguriert, bin noch nicht dazu gekommen.

Was wäre dann deiner Meinung eine Optimale Partionierung?
Ich möchte wie gesagt später noch KDE aus den Ports bauen, und mein Hauptziel ist damit, das die SSD so wenig writes wie möglich abkriegt, wie gehe ich da am besten vor?

Eine Weitere Frage die sich mir stellt ist, bringt Journaling überhaupt etwas, oder ist das eher ein Festplatten Performancefresser?

Zur Verfügung stehen wie gesagt eine SSD mit 128GB und eine Toshiba HDD mit 320GB!

Gruss
 
du hast Glück, weil du hier in diesem Forum auf Leute treffen kannst, die wirklich gut mit solchen Themen Bescheid wissen und du hast Pech, dass ausgerechnet ich nun Zeit habe und dir zu antworten versuche.
Vor über 20 Jahren machte ich mal eine Ausbildung im Themenkreis Computer. Seither versuche ich den Kontakt zu solchen Geräten zu minimieren und möglichst wenig Energie und Zeit zu investieren; das Leben hält für mich deutlich interessantere Dinge bereit ;-)
Deshalb ist alles, was ich mir da zu Recht gelegt und überlegt habe, in keinster Weise fundiert. Lediglich einige der Dinge, die ich aus der grauen Vorzeit erinnere, begegnen mir heute noch immer und immer wieder werden ungefragt die gleichen Lösungen benutzt, die es schon vor 20 Jahren gab und die damals angesichts der verfügbaren HW einen großen Sinn machten. Heute sollten solche Automatismen überdacht werden.
Dabei ist es sicher ein Unterschied, ob ich einen Server betreiben möchte, der nur wenige Aufgaben wahrnimmt, diese aber sehr stabil und zuverlässig ausführen soll, wo ich Analysen betreibe und Logs studiere, um Fehlverhalten, unerwünschte Vorkommnisse und einiges mehr in Erfahrung zu bringen, wo auch mal einen Dump studieren muss um vielleicht einen Fehler zu finden und wo ich also "Informatik" betreibe, oder ob ich einen Desktop-PC aufbaue den ich zum Ansehen von Filmen, Bildern und Mails benutzen möchte und wo ich selbst als User gar nicht in der Lage bin, die diversen Logs zu deuten und deshalb auch auf sie verzichten kann.
Ich hoffe, dass du aus diesem verstehst und siehst, dass du es bei mir mit einem User der letzten Kategorie zu tun hast. Mein PC soll ein Desktop sein, wo eine Grafische Oberfläche mir bequemes Arbeiten ermöglicht und wo ich nicht ein Informatik-Studium brauche, um Programme bedienen zu können. Der PC selbst interessiert mich wenig bis gar nicht und das gilt auch ein wenig für das Betriebssystem und seine Feinheiten. Ich will das Ding nutzen und möglichst so, wie ich mir das vorstelle. Weshalb ich da gerade bei FreeBSD gelandet bin, ist sicher nicht uninteressant. Es ist das erste System gewesen, das ich in der gewünschten Art überhaupt hinbekommen konnte und seither bin ich dabei geblieben.
Computer sind für mich unwichtig und eher ein Spielzeug. SIe sind auch produktiv, keine Frage, aber mein Grundsatz bleibt: was wichtig ist, gehört nicht auf einen PC. Ich gehe weiter und sage, was im Leben wichtig ist, hat nichts mit PC zu tun.
Das gilt sicher nicht für alle Anwender.
Es ist aber bei mir so und deshalb gehe ich auch recht sorglos damit um.

Vor diesem Hintergrund also zurück zu deinen Fragen.
Was ich machen würde, unterscheidet sich also von dem, was andere empfehlen und es ist nur zu verstehen, wenn man meine (nicht vorhandenen) Ansprüche kennt.
Ich würde eine Einzige Partition auf der SSD für alles belegen (den 64k Block zum Booten zähle ich nicht eigens). Dann würde ich ausreichend Speicher einbauen und wie schon mal gepostet ein tmpfs nutzen, um einige Dinge dort zu halten, die ich beim nächsten Einschalten auch nicht wieder brauche. SWAP würde ich, genau wie du, auf der HDD anlegen und dann aber nicht nutzen (swapoff schaltet im laufenden Betrieb ab, damit kann einfach getestet werden, ob das geht. Dann, wenn es geht (es geht eigentlich fast immer) würde ich SWAP herauskonfigurieren). Den Rest der HDD würde ich wieder als eine Partition anlegen und hier die zusätzlichen Daten lagern, Filme, Musik, Mail....

Als Dateisystem würde ich für beide Partitionen das gleiche nehmen und wenn du die Berichte gelesen hast, mit gpart -a dafür sorgen, dass die Partitionen auch passend angelegt werden.
Dann würde ich alle Journals und Softupdates und solche Dinge von beiden Platten weglassen und noatime mounten. Die SSD würde ich zusätzlich mit TRIM anlegen.
Bevor die Journals erfunden wurden, lebten wir eigentlich auch schon ganz gut. Manchmal ging ein Filesystem kaputt. Da hört man wirkliche Horror-Geschichten, aber mir ist das nicht ein einziges Mal passiert, bei keinem Dateisystem. Ich nutzte eine Weile ext2 und später XFS (mit einem Journal) und danach nur noch FreeBSD-UFS(2). Ich lebe in einem Land, wo häufig mal der Strom ausfällt und den Luxus einer UPS gönnte ich mir erst ziemlich spät. Deshalb hatte ich häufig damit zu tun, dass ich fsck anwenden musste, doch es war nicht ein einziges Mal ein System dabei zerstört worden. Es gab einmal eine ziemlich aufwendige reparatur mit Austausch von Superblocks und das hatte mich Nerven gekostet, aber es funktionierte letztlich auch. Diese Aktionen kamen nur mit Rechnern und plötzlichem Stromausfall vor.
Das bedeutet, auf einem Laptop mit Akku fühle ich mich da grundsätzlich um mehrere Stufen sicherer. Es gab bei meinen Bastelleien aber auch schon Hänger, bei denen ich tatsächlich den Laptop ausschalten musste und dabei kam es auch schon mal vor, dass ich ein fsck beim nächsten Boot laufen lassen musste. Mehr nicht.
Also, aus meiner Sicht ganz klar: beim Einsatz von SSD und überhaupt auf Laptops, nehme ich keine Journals, weil ich gut ohne sie leben kann und die Vorteile für mich nicht so wichtig sind, wie die gesteigerte Performance und Lebensdauer (vor allem bei SSD) .
Den Unterschied in der Performance merkt man tatsächlich spürbar.
Als ich das bei einer Installation mal vergessen hatte, wunderte ich mich, dass das Systems beim Spielen von Filmen von SSD ruckelte, bei der HDD hatte es indessen ohne Ruckeln funktioniert. Alle Optimierungen halfen nicht, bis ich schließlich merkte, dass tatsächlich das eingeschaltete Journal dieses Ruckeln verursachte. Die an sich schnellere SSD wurde dadurch so sehr ausgebremst (viel Schreiben, Schreiben auf SSD relativ langsam...), dass sie sogar schlechter funktionierte, als eine HDD.
Außerdem erscheint es mir bei Laptops auch sinnvoll, auf Journals und zusätzliche Schreibarbeit (etwa Systemlogs) zu verzichten, um damit überhaupt erst die Vorraussetzung zu schaffen, möglicherweise die Platte auch mal schlafen zu legen. Wenn da dauernd Dienste drauf zugreifen wollen, wird das nämlich nicht passieren. Weil ich oft Filme von Stick oder über Netzwerk sehe, ärgerte es mich eben, dass die Platte nicht zum Stillstand zu bewegen war. Dabei muss ich allerdings zusätzlich einschränken, dass bei gleichem System eine HDD und eine SSD sich schlafen legten, während zwei andere SSD nicht dazu zu bewegen waren. Hier gibt es offensichtlich Unterschiede in der HW.
Nun darfst du trotzdem nicht unbedingt den Trugschluss ziehen, dass moderne Dateisysteme mit Journal langsamer sind, als die älteren Systeme ohne Journal. Ich weiß überhaupt nicht, wie das alles funktioniert und ob jemand Perfrmance-Tests gemacht hat. Meine Erinnerung an die alten Systeme ist natürlich auch die Erinnerung an ältere und langsamere HW. Aber es ist nicht etwa so, dass an den Code für ein Dateisystem einfach der Teil für das Journal angehangen wird. Die neuen Dateisysteme sind eine vollkommene Überarbeitung oder Neugestalltungen. Ich habe das Gefühl, dass etwa das neuere ext4 deutlich schneller ist, als das ältere ext3 und beide erscheinen mir auch mit Journal schneller, als es ext2 gewesen ist. Das Journal nicht zu nutzen bleibt deshalb für mich die Ausnahme, die ganz bewusst entschieden werden sollte. Aber gerade auf Sticks, USB-Platten oder eben auf Platten in Laptops und besonders auf SSD sehe ich keine Vorteile in einem Journal, sondern eher nur Nachteile.

Wenn du die Ports nutzen willst und da intensiv baust, würde ich das über einen Link erledigen und die auf der HDD unterbringen.
Du kannst auch einfach die Konfigurationsdateien ändern und dann ein beliebiges Verzeichnis zum Portsverzeichnis machen. Genau, wie die Anwendungen, suche ich aber selbst natürlich in /usr/ports und nicht irgendwo sonst. Deshalb möchte ich gerne die ports in /usr/ports finden.
Für alle, die mitlesen und nicht wissen, wie ich das meine, vielleicht nochmal konkret dieses Beispiel:
ls /usr
das zeigt dir, ob da schon ein ports existiert. Ist das der Fall, verschiebst du es auf die HDD. Angenommen, der Mountpoint ist /platte2.
mv /usr/ports /platte2
ln -s /platte2/ports /usr/ports
Das sollte schon genügen. Evtl kontrollierst du noch die Zugriffrechte deines Links und natürlich darf /platte2 nicht etwa nur ro eingebunden sein. Ich denke, diese Dinge verstehen sich aber von selbst.
Ist /usr/ports nicht da, kannst du direkt ports auf /platte2 anlegen und dann verlinken. Anschließend passiert alles genau, wie vorgesehen, denn /usr/ports wird ja gefunden, nur dass nun die Daten dem Link folgen und entsprechend auf der HDD landen.
Das ist, finde ich, wesentlich einfacher und flexibler als viele Partitionen zu nutzen.
Und nochmal: es gibt allerdings gute Gründe (besonders bei Servern) trotzdem Partitionen zu nutzen. Nur für mich habe ich die Entscheidung anders getroffen und besonders im Hinblick auf den Gebrauch als Desktop-Rechner halte ich das auch für vertretbar und gerade bei Laptops sogar für Vorteilhaft.

Vielleicht sollte ich das nochmal detaillierter an einem anderen Beispiel zeigen. Ich weiß es nicht, ob es da Verständnis-Probleme gibt. Es ist so, dass meine Kollegen mich bei solchen Dingen immer sehr merkwürdig anblicken und ich das Gefühl habe, nicht verstanden zu werden. Es fehlt mir wohl an der nötigen Ausdrucksstärke. Allerdings vermute ich eigentlich, dass ich hier viel zu viel tue und alle längst wissen, was ich meine. Also, dann einfach übergehen.
Die Ausgabe von ls -l zeigte in meinem Verzeichnis einen Link:
Code:
lrwxr-xr-x    1 pit   wheel           16 22 Nov 10:43 .thumbnails -> /tmp/.thumbnails
Da ist ein Verzeichnis .thumbnails auf /tmp als Ziel meines Links .thumbnails. Ursprünglich war das Verzeichnis .thumbnails in meinem Heimatordner angelegt und dort landen Vorschaubilder einiger Programme. Diese Vorschaubilder möchte ich nicht für die Ewigkeit sammeln und erhalten. Es genügt mir, diese während einer laufenden Sitzung zu speichern. Deshalb habe ich dieses Verzeichnis in /tmp angelegt und dann durch den Link in mein Heimatverzeichnis zugewiesen.
Code:
pit@syo ~:-> ll /tmp/.thumbnails
total 4
drwx------  2 pit  wheel     0 22 Nov 10:47 large
drwx------  2 pit  wheel  1240 22 Nov 10:47 normal

pit@syo ~:-> ll .thumbnails
lrwxr-xr-x  1 pit  wheel  16 22 Nov 10:43 .thumbnails -> /tmp/.thumbnails

pit@syo ~:-> ll .thumbnails/
total 4
drwx------  2 pit  wheel     0 22 Nov 10:47 large
drwx------  2 pit  wheel  1240 22 Nov 10:47 normal

pit@syo ~:-> mount | grep tmp
tmpfs on /tmp (tmpfs, local)
Die Ausgaben sagen wohl mehr und besser alles, was ich irgendwie anscheinend nie richtig erklären kann. So habe ich diese .thumbnails also einfach auf ein vollkommen anderes Dateisystem verfrachtet (ob ich das bei jedem Systemstart mit einem Script neu mache oder dieses Verzeichnis im /tmp (tmpfs) erhalten bleibt, weiß ich nun nicht).
Natürlich: /tmp wäre nicht nur mir zugänglich! Das wollte ich garantiert nicht so (einfach) haben, wenn mein Rechner mehreren Nutzern verfügbar wäre oder wenn da sensible Daten lagern würden. Doch das sind wieder eigene Überlegungen, die jeder dann für sich selbst anstellen muss.

Die Möglichkeit mit tmpfs "etwas" in den RAM zu legen ist sehr empfehlenswert, gerade bei Laptops und SSD. Ab etwa 1.5GB RAM sollte das auch funktionieren und auch ohne SWAP.
Bei noch mehr Speicher könnte man sich Gedanken um weitergehende Technologien machen. Sogenannte RAMDISKS ermöglichen es, ganze Verzeichnisse zu mounten. Diese Technologie ist vor allem im Embeded-Bereich verbreitet, wo zusätzlich dann bestimmter Speicher nicht einfach beschrieben werden kann. Dieser (Flash-)RAM ist eigentlich als ROM zu betrachten und da wird oft ein Image eines Systems durch eine spezielle Prozedur eingespielt, das unveränderlich bleibt und in einem Bootvorgang "ausgepackt" und auf einzelne RAMDISKS verteilt wird. Veränderliche Teile (meist so etwas wie /var) werden dann einfach auf beschreibbarem Speicher gehalten und entsprechend gemountet. Grundsätzlich sind das in meinen Augen ganz ausgezeichnete Technologien, den Schreibbedarf auf eine SSD zu minimieren. Ich spiele schon länger mit dem Gedanken, so etwas auf einem Laptop zu probieren, aber ich kann dazu nicht genug und es würde mich viel Zeit kosten.
Ein gutes Beispiel dafür, wie so etwas gehen kann, ist KNOPPIX oder auch FreeNAS.
In einem solchen Szenario würde dann die SSD also nahezu ausschließlich als Boot-Medium dienen und beinahe der komplette Systembetrieb wäre in den RAM verlagert.
Da bleibt dann eigentlich nur die Frage: wozu denn noch eine SSD? Da würde ein USB-Stick es nämlich genausogut tun. Da denke ich ähnlich, wie es Yamagi beschreibt. Wenn ich schon eine SSD habe, möchte ich die doch auch nutzen und nicht vor lauter Schonung gar nicht angreifen.
Ich glaube nicht, dass die Benutzung in einem Laptop ein wirklicher Stress für diese SSD sind. Im laufenden Betrieb machen die eher Pause und besonders, wenn du Daten auf der HDD liegen hast, wird die SSD kaum gebraucht. Das sollte eigentlich Schonung genug sein. Mehr Gedanken würde ich mir da nicht machen, neben dem schon erwähnten Abschalten von Softupdates etc und einschalten von TRIM.
 
Ich habe mich inzwischen auch nochmals informiert, und FreeBSD handhabt das teilw. ähnlich wie Linux.
Massiv beschriebene Bereiche wären /usr/ports und /var/tmp hier landen die ganzen temporäre Dateien beim kompilieren.
Ich habe einen Kollegen gefragt der Gentoo / FreeBSD Privat/Beruflich einsetzt und der hat mir empfohlen, 2GB für /var sowie 10GB für /tmp auf die HDD zu partitionieren und /var/tmp mit einen symlink auf /tmp zu setzen.
Seiner Meinung nach benötigt man schon mind. 5GB für /var/tmp für die ganz grossen Kompilierorgien wie z.B. KDE, ein anderer Grund der auch dafür sprach sei /var/log, hier sollen ja teilw. massive kleine schreiboperationen stattfinden.

Musik und Videos werd ich einfach normal unter /usr/home/Music-/Movies etc. speichern, ich sehe lediglich hier keinen sinn, das noch zu symlinken.
Die Daten von /usr/home bleiben ja auch bei einer neuinstallation von FreeBSD enthalten, /usr/home möchte ich sowieso auf der zweiten HDD Platte haben.

Soft-Updates & Journal werde ich womöglich dann wie laut deiner Meinung nach für beide Platten deaktivieren, ich werd hier aber nochmal im IRC deswegen nachfragen (Vorteile/Nachteile)!

Das einzige wo ich mir noch nicht sicher bin, betrifft /usr/ports möchte ich am liebsten auch gleich auf der HDD, aber ich weiss nicht wie Gross der Userspace diesbezüglich ist, 5GB sollten aber denk ich mal reichen, werd hier auch nochmals im IRC nachfragen.

Somit würde die Partitionierung nun so aussehen

SSD:
64KB Boot-Loader
119GB / TRIM

HDD:
270GB /usr/home bzw. /home
5GB /usr/ports
2GB /var
10 GB /tmp (+ Symlink von /var/tmp auf /tmp und ggf. /var/tmp in den RAM schieben)
2GB SWAP (mehr macht sowieso hier keinen sinn, ich besitze 6GB RAM, werds dann mal nachträglich deaktivieren und testen obs ohne auch ohne Probleme funktioniert)
 
ich würde da ein wenig widersprechen. Mein laufendes System, das gerade nichts anderes macht, als eine Datei herunterzuladen, zeigt etwa dies:
Code:
senyo# du -d 0 -h /usr/ports
 11G    /usr/ports
senyo# du -d 1 -h /var
6,0K    /var/at
2,0K    /var/agentx
2,0K    /var/.snap
 18K    /var/backups
1,2G    /var/crash
6,0K    /var/cron
272M    /var/db
2,0K    /var/empty
755M    /var/tmp
 14M    /var/log
2,0K    /var/mail
4,0K    /var/msgs
 34K    /var/named
100K    /var/run
167M    /var/spool
 24K    /var/yp
 52K    /var/lib
344K    /var/cache
2,4G    /var
Dabei ist hier keines dieser Verzeichnisse als tmpfs realisiert, Logs sind hier aktiv und es gibt hier auch mehrere Partitionen. Das passt also nicht genau zu dem, was ich für einen Laptop als Desktop PC ansetze.
Es zeigt aber schon ein wenig andere Größenverhältnisse, als du sie annimst, wobei das bei mir nicht dauernd gesäubert wird.
Das hier ist auch ein FreeBSD8er das seit einem 6er immer upgedatet wurde und entsprechend vielleicht schon etwas Ballast sammelte.
Bisher stellte ich fest, dass FreeBSD dem /var nicht die gleiche große Bedeutung zukommen lässt, wie ich das von verschiedenen GNU/Linux her gesehen habe. Die temporären Dateien beim Bauen der Ports stehen, soweit ich das sehe, direkt in den Ports, sowie auch die Quellen hier landen. In jedem Port wird ein Verzeichnis work angelegt, wenn da was kompiliert wird und hier ist wohl die Hauptdaten-Last zu sehen.
Bei Updates werden neue Quellen gezogen, die alten Versionen werden nicht automatisch gelöscht. Deshalb kann hier schon mal etwas mehr Platz gebraucht werden.
OpenOffice schreibt etwas von 11GB Platz, was es zum Kompilieren braucht.

/var/log
wo die logs landen, ist dauernd in Gebrauch. Wenn die Logs nicht abgeschaltet werden. Für einen Desktop und besonders einen Laptop, brauche ich die nicht. (während des System-Baus und fummelns, hatte ich die eingeschaltet. Nachdem alles eine Weile stabil gelaufen war, brauchte ich die nicht mehr).

/var/tmp
hat Dinge, die ich evtl lieber über einen Neustart hinaus behalten möchte und die ich deshalb nicht als tmpfs anlegen wollte.

/tmp ist so eine Sache.
Zum Beispiel nutzen einige Anwendungen per Default /tmp, um Daten hier zu speichern. Etwa bei einem DVD-Rip Programm könnte hier also eine komplette DVD landen, oder bei einem Brennprogramm vielleicht das Abbild und da leuchtet es ein, dass selbst 10GB dann schnell zu klein werden. Es ist natürlich nicht nötig, das so zu lassen und besonders, wenn /tmp auf ein tmpfs soll, muss so etwas bedacht werden.
Im laufenden Betrieb auf einem tmpfs habe ich noch nie mehr als 2G belegt gesehen, wobei ich der Ausgabe nicht unbedingt traue.

SWAP ist eine andere Sache: mit 6GB RAM machen tatsächlich > 6GB SWAP schon Sinn auf einem Laptop und zwar als Hibernations-Partition. Nun geht das bislang wohl eh nicht mit FreeBSD, aber es ist mitunter schwierig, nachher dafür eine Partition herzustellen. Das bedeutet aber dann tatsächlich ungenutzten Platz auf der Platte brach liegen zu haben.

Siehst du ernsthaft einen Vorteil darin, /usr/home, /usr/ports, /var und /tmp in eigenen Partitionen zu haben?
Ich meine, auf einem Laptop, nicht generell gesprochen. Es geht mich zwar nichts an, aber vielleicht erklärst du mir das? (Dann kann ich vielleicht nochmal widersprechen :ugly: )
 
Das Partitionieren hat sich mittlerweile geändert, hab mich im bsdforen irc informiert.

Ist jetzt folgendermassen:

SSD:
128GB / UFS2 Soft Updates, TRIM

HDD (alle Partitionen mit Soft Updates)
246GB /usr/home <-- Ist geschmackssache, ich hätts jetzt auch einfach auf der SSD lassen, und stattdessen Ordner wie Videos/Musik über symlinks auf die Partition setzten können.
Ich persönlich mach das schon immer so bei meinem Arch / Gentoo Linux und kenne auch eher weniger die /home auf der gleichen Platte haben.

25GB /var <--- Hier habe habe ich zusätzlich noch einen symlink in die make.conf bez. Ports Workdir & Distdir erstellt, /usr/ports lasse ich jetzt damit definitiv auf der SSD.
Der ganze scheiss landet also nicht mehr auf der SSD, was mein Ziel war.
Bezüglich zu den logs, es mag ja sein das du keinen spezifischen nutzen diesbezüglich hast, aber ich persönlich bin schon manchmal froh gewesen das ich logs hatte, die die Problemsuche um einiges verkürzt haben, u.o. Kontrolle.
Das ist aber auch wieder geschmackssache.

25GB /tmp <-- Habe mich vorher noch schnell informiert und habe gelesen das FreeBSD doch, bei TMP bei zu wenig Speicher die Puste ausgeht.

2GB SWAP

Übrigens bin ich gerade verwundert das dass ganze System mit Soft-Updates auf der SSD um einiges flotter läuft, portsnap extract war bei meiner vorherigen Installation ohne Soft-Updates krücken langsam. oO

Gruss und ein zufriedener Ryudo :)
 
[...] gestern habe ich eine Corsair P128 SSD neben meiner alten Seagate HDD ins Notebook eingebaut.


Ist das so eine?
Code:
camcontrol identify ada0 | grep device

pass0: <CORSAIR CMFSSD-128GBG2D VBM19C1Q> ATA-7 SATA 2.x device
device model          CORSAIR CMFSSD-128GBG2D

Die läuft bei mir schon ein paar Jahre einwandfrei mit FreeBSD darauf.
Meine FreeBSD Installation läuft komplett auf der SSD.
Zunächst hatte ich nichts getan um die SSD besonders zu schonen,
denn falls sie Normalbetrieb nicht aushält, dann hätte sie kein Laufwerk werden sollen.
Außerdem sind innerhalb der ersten 6 Monate nach Kauf die Gewährleistungsansprüche für den Kunden vorteilhafter.
Später habe ich dann nach und nach ein wenig optimiert. Etwa tmpfs benutzt, noatime gesetzt und vor nicht allzu langer Zeit dann auch TRIM eingeschaltet.
http://www.bsdforen.de/showthread.php?t=26875
Es war aber auch vorher kein Problem auf der SSD FreeBSD rennen zu lassen.
Aufteilung bei mir wie folgt:
gpart
Code:
gpart show

=>       34  250069613  ada0  GPT  (119G)
         34        128     1  freebsd-boot  (64k)
        162    4194304     2  freebsd-ufs  (2.0G)
    4194466   17604608     3  freebsd-swap  (8.4G)
   21799074  228259840     4  freebsd-zfs  (108G)
  250058914      10733        - free -  (5.2M)
mount
Code:
mount

/dev/label/rootfs0 on / (ufs, local, noatime, soft-updates)
devfs on /dev (devfs, local, multilabel)
fdescfs on /dev/fd (fdescfs)
procfs on /proc (procfs, local)
tank0/usr on /usr (zfs, local, noatime, nfsv4acls)
tank0/var on /var (zfs, local, noatime, nfsv4acls)
linprocfs on /compat/linux/proc (linprocfs, local)
linsysfs on /compat/linux/sys (linsysfs, local)
tmpfs on /tmp (tmpfs, local)
tmpfs on /var/tmp (tmpfs, local)
fstab
Code:
cat /etc/fstab

# Device                Mountpoint              FStype          Options Dump Pass
/dev/label/rootfs0      /                       ufs             rw,noatime      1       1
/dev/ada0p3.eli         none                    swap            sw              0       0
fdesc                   /dev/fd                 fdescfs         rw              0       0
proc                    /proc                   procfs          rw              0       0
linprocfs               /compat/linux/proc      linprocfs       rw,late         0       0
linsys                  /compat/linux/sys       linsysfs        rw,late         0       0
tmpfs                   /tmp                    tmpfs           rw,late,mode=1777    0       0
tmpfs                   /var/tmp                tmpfs           rw,late,mode=1777    0       0
In einer anderen Kiste habe ich die gleiche SSD mit dem Original Samsung Label drin.
Corsair labelte bei diesem Modell wohl im großen und ganzen nur um.
Ist der gleiche Samsung Controller drin mit relativ viel Cache (128MB) und das Teil hat offensichtlich ein recht gut funktionierende Garbage Collection, jedenfalls hat das lange benutzen ohne TRIM auch nichts ausgemacht.
Eine konventionelle Festplatte hänge ich nur gelegentlich ein, wenn die SSD knallvoll ist und ich Platz schaffen muss, weil einfach nichts mehr drauf passt.
Würde ich aber nicht ständig mitlaufen lassen wollen, so eine konventionelle Festplatte, den selbst eine leise konventionelle Festplatte ist noch viel lauter als der ganze Rest der Kiste.
 
Solange man keine Anwendungen hat die atime brauchen (fällt da jemandem überhaupt eine ein?) kann man überflüssige Writes sparen mit noatime. FreeBSD 9.0 hat TRIM Support für UFS allerdings müssen allte beteiligten GEOM Klassen BIO_DELETE dafür weiterleiten. GELI tut das leider nicht. Es dürfte allerdings nicht zu schwer sein das zu implementieren.
 
Ist das so eine?
Code:
camcontrol identify ada0 | grep device

pass0: <CORSAIR CMFSSD-128GBG2D VBM19C1Q> ATA-7 SATA 2.x device
device model          CORSAIR CMFSSD-128GBG2D

Die läuft bei mir schon ein paar Jahre einwandfrei mit FreeBSD darauf.
Meine FreeBSD Installation läuft komplett auf der SSD.

Aufteilung bei mir wie folgt:
gpart
Code:
gpart show

=>       34  250069613  ada0  GPT  (119G)
         34        128     1  freebsd-boot  (64k)
        162    4194304     2  freebsd-ufs  (2.0G)
    4194466   17604608     3  freebsd-swap  (8.4G)
   21799074  228259840     4  freebsd-zfs  (108G)
  250058914      10733        - free -  (5.2M)
Ja exakt diese SSD mit dieser Firmware ist es!
Bei dir versteh ich aber nicht warum du ne 8,4GB SWAP Partition hast.
ZFS scheint doch atm. TRIM auch nicht zu beherrschen oder liege ich da falsch?

Ich werd die Kiste jetzt so lassen, später tüftle ich noch ein bisschen mit nem tmpfs im ram rum.
 
ZFS wird auf absehbare Zukunft kein TRIM unterstützen, weil es wohl ziemlich aufwändig wäre das Effizient zu implementieren und niemand bereit ist die nötigen Ressourcen zu investieren.
 
Es gibt hier eine schöne Diskussion über ZFS und TRIM: http://comments.gmane.org/gmane.os.solaris.opensolaris.zfs/44855

Dazu kommt natürlich die hypothetische Frage wie lange TRIM überhaupt noch notwendig sein wird. Natürlich ist es auch Sicht der SSD bzw. ihres Controllers immer besser zu wissen, welche Blöcke wirklich leer sind, als sich auf die Garbage Collection zu verlassen. Nur konnte man die ersten bezahlbaren SSD ohne TRIM praktisch vergessen, da sie sich schnell in Read-Only-Medien verwandelten, bricht die aktuelle Generation ohne TRIM auf längere Sicht kaum mehr ein. Das führt zu der Frage, ob der durch die Garbage Collection einzugehende Kompromiss nicht in absehbarer Zeit kleiner werden könnte, als der Ärger, den eine vernünftige TRIM-Implementierung macht. Sie war schon in UFS nicht gerade trivial, viele Dateisysteme unter Linux können nach wie vor ebenfalls kein TRIM und von Geschichten wie RAID brauchen wir erst gar nicht zu sprechen...
 
Ja exakt diese SSD mit dieser Firmware ist es!
Bei dir versteh ich aber nicht warum du ne 8,4GB SWAP Partition hast.
ZFS scheint doch atm. TRIM auch nicht zu beherrschen oder liege ich da falsch?

Die Aufteilung mit / als UFS, SWAP, ZFS und Verschlüsselung hatte ich mir von Kris Moore abgeguckt. Der hatte das damals auch so mit UFS und ZFS.
TRIM hatte damals keine Relevanz.
Heute würde man das wohl gleich alles mit ZFS regeln.
Falls aber TRIM so wichtig wäre, alles mit UFS.
geli wäre mir aber allemal wichtiger als TRIM.
Hat ja jahrelang ohne TRIM auf der SSD funktioniert.
Was das ZFS und TRIM angeht, Pawel Jakub Dawidek hat sich da schon Gedanken dazu gemacht:
http://mail.opensolaris.org/pipermail/zfs-discuss/2011-February/047289.html
 
Zuletzt bearbeitet:
pass0: <KINGSTON SNVP325S264GB AGYA0202> ATA-8 SATA 2.x device
device model KINGSTON SNVP325S264GB



Code:
Mem: 122M Active, 1297M Inact, 193M Wired, 29M Cache, 112M Buf, 345M Free
Swap:
Code:
pit@eee ~:-> uptime
 8:03pm  up 2 days,  7:20, 3 users, load averages: 1,06 0,83 0,69
Code:
pit@eee ~:-> mount
/dev/ad4s1a on / (ufs, local, noatime)
devfs on /dev (devfs, local, multilabel)
tmpfs on /tmp (tmpfs, local)
tmpfs on /var/run (tmpfs, local)
tmpfs on /var/log (tmpfs, local)
linprocfs on /usr/compat/linux/proc (linprocfs, local)
linsysfs on /usr/compat/linux/sys (linsysfs, local)
procfs on /proc (procfs, local)

pit@eee ~:-> df -h
Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/ad4s1a     57G     26G     27G    49%    /
devfs          1.0k    1.0k      0B   100%    /dev
tmpfs          1.4G    360k    1.4G     0%    /tmp
tmpfs          1.4G     80k    1.4G     0%    /var/run
tmpfs          1.4G     76k    1.4G     0%    /var/log
linprocfs      4.0k    4.0k      0B   100%    /usr/compat/linux/proc
linsysfs       4.0k    4.0k      0B   100%    /usr/compat/linux/sys
procfs         4.0k    4.0k      0B   100%    /proc

Code:
Family 6 - Pentium Pro
Model 28 - Intel Atom processor, 45nm
Stepping 2
Reserved 0

Extended brand string: "         Intel(R) Atom(TM) CPU N280   @ 1.66GHz"
CLFLUSH instruction cache line size: 8
Hyper threading siblings: 2

OK. Meiner ist ein kleiner Asus EEE mit einem relativ schwachem Atom.
Relativ ist eben relativ, ich nutze auch noch immer einen P3 und da geht auch alles, was ich brauche.
Es ist aber leicht zu sehen: der kleine müht sich nun schon seit über zwei Tagen ab um Ports zu bauen. Das wird auch noch ne Weile dauern, aber wichtig ist doch: er tut es! kdebase3 sah ich vorhin vorbei ziehen. Das sind doch keine Kleinigkeiten, aber ohne SWAP und mit tmpfs und nur 2GB Ram schafft er so vor sich hin und stürzt nicht ab.
Das ist aber auch ein Grund, weshalb ich auf einer anderen SSD das FreeBSD ausschließlich aus Binärpaketen aufsetzte. Das geht sehr viel flotter und ist in meinen Augen gerade für die hier vorgesehene Anwendung auch angesagt.
ZFS hatte sich wegen des schwachen Rechners auch gleich verboten und ich würde nicht gerne zwei Dateisysteme mixen wollen, nunja, logischerweise ergibt sich das ja auch daraus, dass ich für eine einzige Partition plädiere.
Mit 25 GB /tmp und 25 GB /var wäre ja auch meine SSD schon voll ausgelastet, derartige Aufteilungen und damit auch Begrenzungen verbieten sich für meinen Fall also eh von selbst. Ich habe nur diese SSD im Asus drin und da muss alles drauf passen. Zusätzliche Partitionen engen mich da nur ein und sie bringen mir auch nichts.
Anders, als bei Fusselbär möglich, möchte ich zum Beispiel nicht irgendwas über NFS sharen.

Wie schon gesagt, es muss letztlich jeder selbst wissen, was er wozu braucht und haben will. Es wundert mich allerdings, dass sehr häufig Partitionen genutzt und eingesetzt werden, ohne dass da ein weiterer Sinn dahinter steckt. Irgendwie aus Tradition. Aber tatsächlich bringen tut es oft gar nichts, außer vielleicht zusätzlichen Ärger durch unnötige Begrenzungen.

Nun also viel Spaß damit.

Achso. Vielleicht ist der schwache Rechner dann ein möglicher Grund, weshalb meine Beobachtung genau anders war, dass nämlich Soft-Updates die SSD sehr wohl erheblich bremsten? Oder vielleicht die HW der SSD, sprich, ein kleinerer oder schlechterer Cache?
Beim Abspielen eines Filmes werden ja nicht viele Dateien angelegt oder geschrieben. Es wird eine einzige Datei gelesen (grundsätzlich, im Detail ist es natürlich etwas mehr action). Jedenfalls eine deutlich andere Situation, als beim portsnap extract.
Schon interessant.
Mit TRIM habe ich bisher noch keine praktische Erfahrung und es erst nach Artikeln in diesem Forum und nachdem ich sah, dass Mac-OS-X es nun auch bei den eingebauten SSD eingeschaltet hat, vor dem aktuel laufenden Update bei meinem Asus aktiviert.
Die Argumente dafür haben mich einfach beeindruckt.

So long.
Bye.

edit:
Bei der oben gelisteten SSD und dem nun neuen 9.0-RC2 habe ich Softupdates nun nochmal an und abgeschaltet und konnte dabei keinen Unterschied bemerken, keinen, also weder einen negativen Einfluss, noch einen positiven.
 
Zuletzt bearbeitet:
Nur konnte man die ersten bezahlbaren SSD ohne TRIM praktisch vergessen, da sie sich schnell in Read-Only-Medien verwandelten, bricht die aktuelle Generation ohne TRIM auf längere Sicht kaum mehr ein.
Heißt das, dass die SSD-Karte selbst auch TRIM können muss, damit ich die "alte Geschwindigkeit" wieder bekomme? Ich habe hier einen Asus EEEPC der ersten Generation (701 aka 4g). IIRC hat der eine SSD-Karte verbaut. Wenn die nun selbst kein TRIM kann, bringt mir ein Update/Neuinstallation auf 9.0 nichts? Die Schreibgeschwindigkeit von der Karte ist nämlich inzwischen mehr als unterirdisch schlecht.
 
Ja. Damit du TRIM nutzen kannst, müssen alle Beteiligten in der Kette es unterstützen. Von oben nach unten:
1. Das Dateisystem.
2. Der Treiber des Betriebssystem (bei uns ahci.ko).
3. Der Controller.
4. Das Medium (bei dir also die SSD).

EDIT: Per "camcontrol identify /dev/adaX" kann man herausfinden, ob ein Medium TRIM kann...

Code:
root@happy:pts/4 ~> camcontrol identify /dev/ada0                                                                                                   [DING!]
pass0: <INTEL SSDSA2CW120G3 4PC10362> ATA-8 SATA 2.x device
pass0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)

protocol              ATA/ATAPI-8 SATA 2.x
device model          INTEL SSDSA2CW120G3
firmware revision     4PC10362
serial number         CVPR1202000A120LGN
WWN                   50015179595735f5
cylinders             16383
heads                 16
sectors/track         63
sector size           logical 512, physical 512, offset 0
LBA supported         234441648 sectors
LBA48 supported       234441648 sectors
PIO supported         PIO4
DMA supported         WDMA2 UDMA6 
media RPM             non-rotating

Feature                      Support  Enabled   Value           Vendor
read ahead                     yes	yes
write cache                    yes	yes
flush cache                    yes	yes
overlap                        no
Tagged Command Queuing (TCQ)   no	no
Native Command Queuing (NCQ)   yes		32 tags
SMART                          yes	yes
microcode download             yes	yes
security                       yes	no
power management               yes	yes
advanced power management      no	no
automatic acoustic management  no	no
media status notification      no	no
power-up in Standby            no	no
write-read-verify              no	no
unload                         yes	yes
free-fall                      no	no
data set management (TRIM)     yes
Code:
root@happy:pts/4 ~> camcontrol identify /dev/ada1                                                                                                [11:00:37]
pass1: <ST2000DL003-9VT166 CC32> ATA-8 SATA 3.x device
pass1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes)

protocol              ATA/ATAPI-8 SATA 3.x
device model          ST2000DL003-9VT166
firmware revision     CC32
serial number         6YD08XFY
WWN                   5000c500369239d5
cylinders             16383
heads                 16
sectors/track         63
sector size           logical 512, physical 512, offset 0
LBA supported         268435455 sectors
LBA48 supported       3907029168 sectors
PIO supported         PIO4
DMA supported         WDMA2 UDMA6 
media RPM             5900

Feature                      Support  Enabled   Value           Vendor
read ahead                     yes	yes
write cache                    yes	yes
flush cache                    yes	yes
overlap                        no
Tagged Command Queuing (TCQ)   no	no
Native Command Queuing (NCQ)   yes		32 tags
SMART                          yes	yes
microcode download             yes	yes
security                       yes	no
power management               yes	yes
advanced power management      no	no
automatic acoustic management  yes	yes	254/0xFE	254/0xFE
media status notification      no	no
power-up in Standby            no	no
write-read-verify              yes	no	0/0x0
unload                         no	no
free-fall                      no	no
data set management (TRIM)     no
 
Zuletzt bearbeitet:
Zurück
Oben