SSD langsam

mrtonik

Well-Known Member
Hallo,

ich habe wiedermal mein kleines Netbook hervorgekramt. Es handelt sich um ein Dell Mini 9 (Atom N270, 16gb SSD, 2gb Ram, Intel GMA 950, ...).
Leider verhält sich das System teilweise ziemlich langsam wenn es etwas auf der Platte arbeiten muss.

Beispiel "portsnap extract"
Code:
time portsnap extract
.
.
.
108.792u 186.844s 2:16:28.06 3,69%      64+633k 23238+357570io 1pf+0w

smartctl -a
Code:
smartctl 5.39.1 2010-01-28 r3054 [FreeBSD 8.1-RELEASE i386] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF INFORMATION SECTION ===
Device Model:     STEC PATA 16GB
Serial Number:    STM0000CCEDF
Firmware Version: E5221-10
User Capacity:    15,408,046,080 bytes
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   6
ATA Standard is:  Exact ATA specification draft version not indicated
Local Time is:    Mon Oct 18 11:35:17 2010 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x02)	Offline data collection activity
					was completed without error.
					Auto Offline Data Collection: Disabled.
Self-test execution status:      (   0)	The previous self-test routine completed
					without error or no self-test has ever 
					been run.
Total time to complete Offline 
data collection: 		 ( 430) seconds.
Offline data collection
capabilities: 			 (0x59) SMART execute Offline immediate.
					No Auto Offline data collection support.
					Suspend Offline collection upon new
					command.
					Offline surface scan supported.
					Self-test supported.
					No Conveyance Self-test supported.
					Selective Self-test supported.
SMART capabilities:            (0x0002)	Does not save SMART data before
					entering power-saving mode.
					Supports SMART auto save timer.
Error logging capability:        (0x01)	Error logging supported.
					No General Purpose Logging support.
Short self-test routine 
recommended polling time: 	 (   1) minutes.
Extended self-test routine
recommended polling time: 	 ( 115) minutes.

SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   100   100   025    Pre-fail  Always       -       0
  2 Throughput_Performance  0x0027   100   100   025    Pre-fail  Always       -       0
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       80
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       57
 13 Read_Soft_Error_Rate    0x002e   100   100   010    Old_age   Always       -       0
100 Unknown_Attribute       0x0032   097   097   005    Old_age   Always       -       5488501
103 Unknown_Attribute       0x0002   100   100   090    Old_age   Always       -       0
170 Unknown_Attribute       0x0033   099   099   010    Pre-fail  Always       -       93
171 Unknown_Attribute       0x0032   100   100   010    Old_age   Always       -       0
172 Unknown_Attribute       0x0032   100   100   010    Old_age   Always       -       0
173 Unknown_Attribute       0x0032   000   000   000    Old_age   Always       -       0
174 Unknown_Attribute       0x0032   000   000   000    Old_age   Always       -       0
184 End-to-End_Error        0x0033   100   100   090    Pre-fail  Always       -       0
187 Reported_Uncorrect      0x0032   100   100   001    Old_age   Always       -       0
188 Command_Timeout         0x0032   000   000   000    Old_age   Always       -       0
194 Temperature_Celsius     0x0002   000   000   000    Old_age   Always       -       0
196 Reallocated_Event_Count 0x0002   100   100   025    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0003   100   100   025    Pre-fail  Always       -       0
199 UDMA_CRC_Error_Count    0x0032   000   000   000    Old_age   Always       -       0

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
No self-tests have been logged.  [To run self-tests, use: smartctl -t]


SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

Das System ist frisch installiert. Ein großes / (ufs2+su). Ein kleineres Swap. Einziges Package ist smartmontools.

Weiß jemand wieso das kleine Ding so rumzickt?


Gruß
mrtonik
 
das haengt wohl damit zusammen dass ssds schnell sind beim daten lesen.
aber lahm beim daten schreiben. :belehren:

um naemlich ein einziges bit zu veraendern muss naemlich ein kompletter block (je nach flash-chips unterschiedlich) gelesen, geloescht, und anschliessend neu beschrieben werden.
von daher wuerde ich dir auch abraten eine swap-partition anzulegen.
bei 2gig ram ist das auch eh selten dass man die WIRKLICH braucht.
aber leider legt das betriebssystem unter umstaenden schonmal ein paar buchhaltungsinfos darauf an.
 
Kann ich bei meinem EeePC 701 mit ner 4GB SSD ebenfalls bestätigen.
Da macht nicht mal normales Browsen mit dem FF3 spaß, weil der unentwegt was auf die Platte schreibt. Gewöhnt man im das allerdings ab, dann gehts ganz gut.
 
So, habe jetzt /tmp und /var/tmp als tmpfs.
Swap habe ich auskommentiert.
Außerdem habe ich / mit noatime gemountet.

Kann man sonst noch Etwas machen?
 
swap weg..
eventuell /var/log auf mfs, aber dann sind die logs nach shutdown weg, oder auf nen anderen syslog-server.
 
Hallo,

ich habe drei SSDs unter FreeBSD laufen. Meine Kisten auf der Messe rannten auch mit SSDs. Finde die Dinger prima. Leider noch etwas wenig Speicherkapazität und sie kosten mehr als Festplatten.
Die time mit portsnap extract messen möchte ich nicht, da ich die Angewohnheit habe im Portsbaum herumzufrickeln. Ich lass da immer die diffs einfach im Portverzeichnis liegen. portsnap würde da wohl keine Rücksicht drauf nehmen.
Das hier ist eine Samsung SSD PM800, 128GB, als FreeBSD Systemlaufwerk mit zwei geli Providern drauf, alles UFS2 mit Softupdates, die gerade randvoll mit Daten ist:
Code:
diskinfo -ctv ada0
ada0
        512             # sectorsize
        128035676160    # mediasize in bytes (119G)
        250069680       # mediasize in sectors
        0               # stripesize
        0               # stripeoffset
        248085          # Cylinders according to firmware.
        16              # Heads according to firmware.
        63              # Sectors according to firmware.
        (Samsung SSD PM800, 128 GB)    # Disk ident.

I/O command overhead:
        time to read 10MB block      0.051628 sec       =    0.003 msec/sector
        time to read 20480 sectors   1.370264 sec       =    0.067 msec/sector
        calculated command overhead                     =    0.064 msec/sector

Seek times:
        Full stroke:      250 iter in   0.035691 sec =    0.143 msec
        Half stroke:      250 iter in   0.035457 sec =    0.142 msec
        Quarter stroke:   500 iter in   0.070868 sec =    0.142 msec
        Short forward:    400 iter in   0.056496 sec =    0.141 msec
        Short backward:   400 iter in   0.055628 sec =    0.139 msec
        Seq outer:       2048 iter in   0.133512 sec =    0.065 msec
        Seq inner:       2048 iter in   0.137313 sec =    0.067 msec
Transfer rates:
        outside:       102400 kbytes in   0.507263 sec =   201868 kbytes/sec
        middle:        102400 kbytes in   0.507716 sec =   201688 kbytes/sec
        inside:        102400 kbytes in   0.520596 sec =   196698 kbytes/sec
Aufteilung von dem Ding:
Code:
gpart show
=>       34  250069613  ada0  GPT  (119G)
         34        128     1  freebsd-boot  (64K)
        162    4194304     2  freebsd-ufs  (2.0G)
    4194466   36700160     3  freebsd-swap  (18G)
   40894626    2097152     4  freebsd-ufs  (1.0G)
   42991778  207067136     5  freebsd-ufs  (99G)
  250058914      10733        - free -  (5.2M)
4 und 5 sitzen jeweils auf einem eigenen geli Provider.
Für den für mich unnötig großen swap könnte ich mich heute noch in den Hintern beißen, wenn ich bloß gelenkig genug dafür wäre. :ugly:
Für tmp nehme ich ein nullfs auf /usr/tmp.

Was möglicherweise noch erwähneswert ist: die hat einen Samsung Controller und die SSD hat Cachespeicher, 128 MB wenn mich nicht alles täuscht.
Möglicherweise gibt es da große Unterschiede.
 
Hier mal meins:
Code:
ad0
	512         	# sectorsize
	15408046080 	# mediasize in bytes (14G)
	30093840    	# mediasize in sectors
	0           	# stripesize
	0           	# stripeoffset
	29855       	# Cylinders according to firmware.
	16          	# Heads according to firmware.
	63          	# Sectors according to firmware.
	STM0000CCEDF	# Disk ident.

I/O command overhead:
	time to read 10MB block      0.129415 sec	=    0.006 msec/sector
	time to read 20480 sectors   3.068401 sec	=    0.150 msec/sector
	calculated command overhead			=    0.144 msec/sector

Seek times:
	Full stroke:	  250 iter in   0.095987 sec =    0.384 msec
	Half stroke:	  250 iter in   0.059844 sec =    0.239 msec
	Quarter stroke:	  500 iter in   0.192589 sec =    0.385 msec
	Short forward:	  400 iter in   0.068317 sec =    0.171 msec
	Short backward:	  400 iter in   0.068280 sec =    0.171 msec
	Seq outer:	 2048 iter in   0.193631 sec =    0.095 msec
	Seq inner:	 2048 iter in   0.198703 sec =    0.097 msec
Transfer rates:
	outside:       102400 kbytes in   1.282194 sec =    79863 kbytes/sec
	middle:        102400 kbytes in   1.269130 sec =    80685 kbytes/sec
	inside:        102400 kbytes in   1.271138 sec =    80558 kbytes/sec

Schaut für mich irgendwie eine Ecke langsamer aus.
 
Oben im smartctl steht da was von PATA. Ist das eine P-ATA, oder ist das eine S-ATA SSD?
Bekannt ist, das die kleineren SSDs meist auch viel langsamer sind, als die etwas größeren. Auch sind die neueren SSD Generationen schneller als die alten.
Von älteren SSD Generationen wurde berichtet, dass das System schon mal kurz blockiert sein kann, wenn viel Schreibaktivität auf der SSD ist.

Bei mir es auch so, dass die SSD mit dem neuen ada Treiber läuft, außerdem habe ich ufs.dirhash hochgesetzt und für das Native Command Queuing (NCQ) das sysctl eingestellt.
Das ist der Auschnitt aus meiner /etc/sysctl.conf dazu:
Code:
# For AHCI and NCQ
vfs.read_max=32
# More memory for dirhashes
vfs.ufs.dirhash_maxmem=134217728

Kürzlich hatten wir auch gsched in der Diskussion:
http://www.bsdforen.de/showthread.php?t=25376
Das ist ein Scheduler für Laufwerke.
 
Kann ich bei meinem EeePC 701 mit ner 4GB SSD ebenfalls bestätigen.
Da macht nicht mal normales Browsen mit dem FF3 spaß, weil der unentwegt was auf die Platte schreibt. Gewöhnt man im das allerdings ab, dann gehts ganz gut.

Das kann ich ebenso beim Asus EEE 900A bestätigen, liegt aber auch daran, daß zumindest Asus SSDs nahm die nicht einmal den Titel SSD verdienten.
 
Es ist (leider) wirklich eine PATA-SSD.

Die zwei sysctl´s hatte ich schon so gesetzt. Habe ich vergessen zu schreiben.

gsched werde ich auch mal ausprobieren.

Insgesamt werde ich mich wohl aber mit der "schlechten" Performance abfinden müssen. Die genannten Hilfen können nun mal auch nicht zaubern :D

Danke soweit!
 
Das ist technisch gesehen wahrscheinlich nicht einmal eine SSD, stattdessen eine bessere CF-Karte. Das bedeutet, dass dort kein hochentwickelter und teurer Controller zwischen klebt, der die Nachteile des Flash ausgleicht, Daten intelligent vorweg in einen Cache lädt, Wearleveling macht und sowas. Dazu dann noch Billigflash und man den Ärger... :/
 
Hier mal meins:
Code:
ad0
I/O command overhead:
	time to read 10MB block      0.129415 sec	=    0.006 msec/sector
	time to read 20480 sectors   3.068401 sec	=    0.150 msec/sector
	calculated command overhead			=    0.144 msec/sector

Seek times:
	Full stroke:	  250 iter in   0.095987 sec =    0.384 msec
	Half stroke:	  250 iter in   0.059844 sec =    0.239 msec
	Quarter stroke:	  500 iter in   0.192589 sec =    0.385 msec
	Short forward:	  400 iter in   0.068317 sec =    0.171 msec
	Short backward:	  400 iter in   0.068280 sec =    0.171 msec
	Seq outer:	 2048 iter in   0.193631 sec =    0.095 msec
	Seq inner:	 2048 iter in   0.198703 sec =    0.097 msec
Transfer rates:
	outside:       102400 kbytes in   1.282194 sec =    79863 kbytes/sec
	middle:        102400 kbytes in   1.269130 sec =    80685 kbytes/sec
	inside:        102400 kbytes in   1.271138 sec =    80558 kbytes/sec

Schaut für mich irgendwie eine Ecke langsamer aus.

Hallo,

deine Werte sind fast identisch mit meiner 500GB HDD, nur deine Seek time ist etwas schneller ;-)

Gruß ré
 
Mit ner Notebookfestplatte, ZFS+geli siehts dann so aus: *schnüff*

Code:
ad0
        512             # sectorsize
        120034123776    # mediasize in bytes (112G)
        234441648       # mediasize in sectors
        0               # stripesize
        0               # stripeoffset
        232581          # Cylinders according to firmware.
        16              # Heads according to firmware.
        63              # Sectors according to firmware.
        5LZ20D7Z        # Disk ident.

I/O command overhead:
        time to read 10MB block      0.239831 sec       =    0.012 msec/sector
        time to read 20480 sectors   3.423152 sec       =    0.167 msec/sector
        calculated command overhead                     =    0.155 msec/sector

Seek times:
        Full stroke:      250 iter in   6.530190 sec =   26.121 msec
        Half stroke:      250 iter in   4.799094 sec =   19.196 msec
        Quarter stroke:   500 iter in   8.052539 sec =   16.105 msec
        Short forward:    400 iter in   2.118066 sec =    5.295 msec
        Short backward:   400 iter in   3.406705 sec =    8.517 msec
        Seq outer:       2048 iter in   0.386520 sec =    0.189 msec
        Seq inner:       2048 iter in   0.283558 sec =    0.138 msec
Transfer rates:
        outside:       102400 kbytes in   2.414449 sec =    42411 kbytes/sec
        middle:        102400 kbytes in   2.753100 sec =    37194 kbytes/sec
        inside:        102400 kbytes in   4.859835 sec =    21071 kbytes/sec
 
Das ist mal wieder ein interessantes Thema, denn ich bastele nun auch schon eine Weile mit einem Asus 1000HE herum und benutze jetzt eine SSD.
SSD ist für mich gleich erste Wahl für dieses Gerät gewesen, weil ich Vorteile bei der Leistungsaufnahme, der Wärme- und Geräuschentwicklung sah. Performance-Vorteile spielten zunächst eine untergeordnete Rolle.
Leider war dieses Netbook weder direkt mit SSD zu bekommen, noch konnte ich die eingebaute HDD (mit vorinstalliertem M$) weglassen. So musste ich eine SSD extra bestellen und orientierte mich da eher am Preis, als an anderen Kriterien.
Auf diese SSD landete ein Ubuntu, womit ich den kleinen Asus eine Weile nutzte und das funktionierte gut und sehr schnell. Aus welchen Gründen ich dann lieber doch FreeBSD mit meinem geliebten KDE3 haben wollte, kann ich rein sachlich nicht erklären. Jedenfalls landete mein erster Versuch damit auf der freien HDD und das war sehr sehr viel langsamer, als Ubuntu von SSD. Also kaufte ich schließlich noch eine SSD für FreeBSD und nutze die nun.
Mit der SSD war FreeBSD noch immer nicht so schnell, wie Ubuntu. Vor allem beim Starten der Anwendungen, aber auch beim Booten. Es war aber deutlich schneller, als mit der HDD. Nur: wenn ich einen Film mit VLC spielte, ruckelte der von der SSD, was er mit der HDD nicht gemacht hatte. Ich konnte mir das nicht erklären. Seit ich das Journal des Filesystems abgeschaltet habe, ist das deutlich besser, ich möchte sagen, perfekt!
Diese SSD kann weder mit smartctl, noch mit ataidle.
Da gibt es ganz offenbar fulminante Unterschiede!
Alle Logs, die ich kenne, habe ich abgeschaltet und dies kommt:
Code:
pit@eee ~:-> diskinfo -ctv ad4
ad4
        512             # sectorsize
        80026361856     # mediasize in bytes (75G)
        156301488       # mediasize in sectors
        0               # stripesize
        0               # stripeoffset
        155061          # Cylinders according to firmware.
        16              # Heads according to firmware.
        63              # Sectors according to firmware.
        CVPO94900190080BGN      # Disk ident.

I/O command overhead:
        time to read 10MB block      0.094477 sec       =    0.005 msec/sector
        time to read 20480 sectors   3.712730 sec       =    0.181 msec/sector
        calculated command overhead                     =    0.177 msec/sector

Seek times:
        Full stroke:      250 iter in   0.035435 sec =    0.142 msec
        Half stroke:      250 iter in   0.039252 sec =    0.157 msec
        Quarter stroke:   500 iter in   0.081537 sec =    0.163 msec
        Short forward:    400 iter in   0.062587 sec =    0.156 msec
        Short backward:   400 iter in   0.062832 sec =    0.157 msec
        Seq outer:       2048 iter in   0.291286 sec =    0.142 msec
        Seq inner:       2048 iter in   0.277617 sec =    0.136 msec
Transfer rates:
        outside:       102400 kbytes in   0.926660 sec =   110504 kbytes/sec
        middle:        102400 kbytes in   0.926312 sec =   110546 kbytes/sec
        inside:        102400 kbytes in   0.926023 sec =   110580 kbytes/sec

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: gjournal: (-J)                                     disabled
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)

pit@eee ~:-> cat /etc/fstab
# Device                Mountpoint                      FStype          Options         Dump    Pass#
#/dev/ad4s1b            none                            swap            sw              0       0
/dev/ad4s1a             /                               ufs             rw,noatime      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

pit@eee ~:-> cat /etc/sysctl.conf
# $FreeBSD: src/etc/sysctl.conf,v 1.8.34.1.4.1 2010/06/14 02:09:06 kensmith Exp $
#
#  This file is read when going to multi-user and its contents piped thru
#  ``sysctl'' to adjust kernel values.  ``man 5 sysctl.conf'' for details.
#

# Uncomment this to prevent users from seeing information about processes that
# are being run under another UID.
#security.bsd.see_other_uids=0

vfs.usermount=1
vfs.ufs.dirhash_maxmem=134217728
vfs.read_max=32

kern.ipc.shmmax=67108864
kern.ipc.shmall=32768


#hw.acpi.reset_video=1
#hw.acpi.sleep_button_state=S5

compat.linux.osrelease=2.6.16
gsched habe ich seit dem bereits zitierten Beitrag auch eingesetzt, sehe dabei aber nicht wirklich einen Vorteil.
Überhaupt und generell ist es ja oft sehr subjektiv und furchtbar schlecht zu messen, wie schnell ein System arbeitet. Entweder, man kann damit leben, oder aber, man muss was ändern, im Zweifel eben auch mal andere HW einsetzen. Das geht ja bei Netbooks kaum.
Das schnellste Betriebssystem für einen Netbook, das ich bisher gesehen habe, ist Ubuntu 10.04. Das hat vielleicht damit zu tun, dass es spezielle Treiber passend zur HW gibt, aber ganz sicher auch damit, dass dies ein Schwerpunkt in der Entwicklung gewesen ist. "Schnell=Gut".
Dass ich selbst trotzdem lieber bei dem langsameren FreeBSD bleibe, liegt daran, dass es mir keineswegs zu langsam ist und dass ich noch immer mit KDE3 versorgt werde, an das ich so gewöhnt bin.

diskinfo ist wieder neu für mich und ich habe nichts dazu nachgelesen und einfach den Befehl nachgeäfft. Es scheint ähnlich zu testen, wie hdparm in der Linux-Welt, also ein reiner HW-Test, unabhängig vom benutzten Dateisystem. (OK, die SW startet und läuft von einem bestimmten Dateisystem, aber das ist sicher irrelavant für die Ergebnisse). Es gibt aber eben auch Unterschiede zwischen den benutzten Dateisystemen und diese können auch unterschiedlich optimiert werden.
Für ein Netbook würde mir etwa nicht einfallen, ZFS zu wählen. Mein Netbook wird wohl auch kein NFS-Server sein. Bei einer SSD oder einem System vom USB-Stick, will ich möglichst wenig "Schreibarbeit" haben und so weiter. Jeder hat hier vielleicht andere Vorstellungen, aber das scheinen mir sinnvolle Punkte zu sein, wo man über den tatsächlichen Anwendungsbreich den ein oder anderen Ballast vermeiden kann.
 
Das ist mal wieder ein interessantes Thema, denn ich bastele nun auch schon eine Weile mit einem Asus 1000HE herum und benutze jetzt eine SSD.
SSD ist für mich gleich erste Wahl für dieses Gerät gewesen, weil ich Vorteile bei der Leistungsaufnahme, der Wärme- und Geräuschentwicklung sah. Performance-Vorteile spielten zunächst eine untergeordnete Rolle.
Leider war dieses Netbook weder direkt mit SSD zu bekommen, noch konnte ich die eingebaute HDD (mit vorinstalliertem M$) weglassen. So musste ich eine SSD extra bestellen und orientierte mich da eher am Preis, als an anderen Kriterien.
Auf diese SSD landete ein Ubuntu, womit ich den kleinen Asus eine Weile nutzte und das funktionierte gut und sehr schnell. Aus welchen Gründen ich dann lieber doch FreeBSD mit meinem geliebten KDE3 haben wollte, kann ich rein sachlich nicht erklären. Jedenfalls landete mein erster Versuch damit auf der freien HDD und das war sehr sehr viel langsamer, als Ubuntu von SSD. Also kaufte ich schließlich noch eine SSD für FreeBSD und nutze die nun.
Mit der SSD war FreeBSD noch immer nicht so schnell, wie Ubuntu. Vor allem beim Starten der Anwendungen, aber auch beim Booten. Es war aber deutlich schneller, als mit der HDD. Nur: wenn ich einen Film mit VLC spielte, ruckelte der von der SSD, was er mit der HDD nicht gemacht hatte. Ich konnte mir das nicht erklären. Seit ich das Journal des Filesystems abgeschaltet habe, ist das deutlich besser, ich möchte sagen, perfekt!
Diese SSD kann weder mit smartctl, noch mit ataidle.
Da gibt es ganz offenbar fulminante Unterschiede!
Alle Logs, die ich kenne, habe ich abgeschaltet und dies kommt:
Code:
pit@eee ~:-> diskinfo -ctv ad4
ad4
        512             # sectorsize
        80026361856     # mediasize in bytes (75G)
        156301488       # mediasize in sectors
        0               # stripesize
        0               # stripeoffset
        155061          # Cylinders according to firmware.
        16              # Heads according to firmware.
        63              # Sectors according to firmware.
        CVPO94900190080BGN      # Disk ident.

I/O command overhead:
        time to read 10MB block      0.094477 sec       =    0.005 msec/sector
        time to read 20480 sectors   3.712730 sec       =    0.181 msec/sector
        calculated command overhead                     =    0.177 msec/sector

Seek times:
        Full stroke:      250 iter in   0.035435 sec =    0.142 msec
        Half stroke:      250 iter in   0.039252 sec =    0.157 msec
        Quarter stroke:   500 iter in   0.081537 sec =    0.163 msec
        Short forward:    400 iter in   0.062587 sec =    0.156 msec
        Short backward:   400 iter in   0.062832 sec =    0.157 msec
        Seq outer:       2048 iter in   0.291286 sec =    0.142 msec
        Seq inner:       2048 iter in   0.277617 sec =    0.136 msec
Transfer rates:
        outside:       102400 kbytes in   0.926660 sec =   110504 kbytes/sec
        middle:        102400 kbytes in   0.926312 sec =   110546 kbytes/sec
        inside:        102400 kbytes in   0.926023 sec =   110580 kbytes/sec

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: gjournal: (-J)                                     disabled
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)

pit@eee ~:-> cat /etc/fstab
# Device                Mountpoint                      FStype          Options         Dump    Pass#
#/dev/ad4s1b            none                            swap            sw              0       0
/dev/ad4s1a             /                               ufs             rw,noatime      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

pit@eee ~:-> cat /etc/sysctl.conf
# $FreeBSD: src/etc/sysctl.conf,v 1.8.34.1.4.1 2010/06/14 02:09:06 kensmith Exp $
#
#  This file is read when going to multi-user and its contents piped thru
#  ``sysctl'' to adjust kernel values.  ``man 5 sysctl.conf'' for details.
#

# Uncomment this to prevent users from seeing information about processes that
# are being run under another UID.
#security.bsd.see_other_uids=0

vfs.usermount=1
vfs.ufs.dirhash_maxmem=134217728
vfs.read_max=32

kern.ipc.shmmax=67108864
kern.ipc.shmall=32768


#hw.acpi.reset_video=1
#hw.acpi.sleep_button_state=S5

compat.linux.osrelease=2.6.16
gsched habe ich seit dem bereits zitierten Beitrag auch eingesetzt, sehe dabei aber nicht wirklich einen Vorteil.
Überhaupt und generell ist es ja oft sehr subjektiv und furchtbar schlecht zu messen, wie schnell ein System arbeitet. Entweder, man kann damit leben, oder aber, man muss was ändern, im Zweifel eben auch mal andere HW einsetzen. Das geht ja bei Netbooks kaum.
Das schnellste Betriebssystem für einen Netbook, das ich bisher gesehen habe, ist Ubuntu 10.04. Das hat vielleicht damit zu tun, dass es spezielle Treiber passend zur HW gibt, aber ganz sicher auch damit, dass dies ein Schwerpunkt in der Entwicklung gewesen ist. "Schnell=Gut".
Dass ich selbst trotzdem lieber bei dem langsameren FreeBSD bleibe, liegt daran, dass es mir keineswegs zu langsam ist und dass ich noch immer mit KDE3 versorgt werde, an das ich so gewöhnt bin.

diskinfo ist wieder neu für mich und ich habe nichts dazu nachgelesen und einfach den Befehl nachgeäfft. Es scheint ähnlich zu testen, wie hdparm in der Linux-Welt, also ein reiner HW-Test, unabhängig vom benutzten Dateisystem. (OK, die SW startet und läuft von einem bestimmten Dateisystem, aber das ist sicher irrelavant für die Ergebnisse). Es gibt aber eben auch Unterschiede zwischen den benutzten Dateisystemen und diese können auch unterschiedlich optimiert werden.
Für ein Netbook würde mir etwa nicht einfallen, ZFS zu wählen. Mein Netbook wird wohl auch kein NFS-Server sein. Bei einer SSD oder einem System vom USB-Stick, will ich möglichst wenig "Schreibarbeit" haben und so weiter. Jeder hat hier vielleicht andere Vorstellungen, aber das scheinen mir sinnvolle Punkte zu sein, wo man über den tatsächlichen Anwendungsbreich den ein oder anderen Ballast vermeiden kann.

Du schreibst, seit dem du das Journal abgeschalten hast, läuft es super. Meinst Du gjournal? Wenn ja, warum hast Du SoftUpdates aus?

Übersehe ich was?

Grüße
Kai
 
kai_001:
Du schreibst, seit dem du das Journal abgeschalten hast, läuft es super. Meinst Du gjournal? Wenn ja, warum hast Du SoftUpdates aus?

Übersehe ich was?

ich meinte die SoftUpdates.
Auch nach einigen Jahren FreeBSD bin ich in den Begriffen nicht firm geworden und teilweise werden sie bei der Beschreibung anderer Filesysteme auch unterschieldich benutzt. Was die SU bei FreeBSD sind, wird da oft als Journaling bezeichnet und kann ebenso an- oder ausgeschaltet werden.

Bemerkenswert finde ich, dass generell die Empfehlung zu SU gilt, eben mit der Begrünung, Performance zu steigern.
Mit SU wird aber mehr auf Platte geschrieben, als ohne SU und scheinbar ist genau das eine Bremse im Zusammenhang mit SSD. In einem Beitrag weiter oben wird das auch deutlich erklärt (ich glaube von dettus). Einen Test ist es jedenfalls wert.
 
Bei FreeBSD gibt es doch jetzt auch Journaling für UFS, oder irre ich mich da? Softupdates sind etwas anderes als journaling...
 
Jein, was du meinst sind sicher die "Journaled Softupdates". Die kommen aber erst mit 9.0 und sind kein Journal im klassischen Sinne. Es sind normale Softupdates, lediglich das Freigeben von Speicherplatz wird zusätzlich in einer Log vermerkt. Damit hat man alle Vorteile von Softupdates, muss aber kein fsck mehr laufen lassen.
 
Zurück
Oben