This is the old XigmaNAS forum in read only mode,
it will taken offline by the end of march 2021!
I like to aks Users and Admins to rewrite/take over important post from here into the new fresh main forum!
Its not possible for us to export from here and import it to the main forum!
it will taken offline by the end of march 2021!
I like to aks Users and Admins to rewrite/take over important post from here into the new fresh main forum!
Its not possible for us to export from here and import it to the main forum!
UFS Filesystem langsames schreiben
Moderators: b0ssman, apollo567, Princo, crowi
-
aesis
- NewUser

- Posts: 13
- Joined: 01 Apr 2013 15:32
- Status: Offline
UFS Filesystem langsames schreiben
Hallo,
ich habe in meinem NAS 4 gleiche 2TB Samsung HDDs. Die Clients gehen über SAMBA drauf. Auf jeder HDD (alle UFS mit 5% freiem Speicher) liegen TrueCrypt Container mit NTFS Dateisystem. Die Klient-OS sind Windows 7 bis 8. Sind nun die Container gemountet und schreibe ich große Dateien drauf, oder die Gesamtgröße der Dateien ist mehrere GB, so läuft eine Zeit lang die HDD ruhig und ich habe angeblich eine Übertragungsrate von ~90MB/sec.
Nach einiger Zeit bricht diese aber auf ~30MB/sec. ein und die Platte fängt an zu rödeln bis der Arzt kommt.
Gleiches ist bei den anderen Platten zu erkennen. Gestern ist mir nach so einem Vorgang eine HDD abgeschmiert (während des kopierens ist die Festplatte vom NAS System nicht mehr auffindbar und muss via Strom aus -an neu gestartet werden) und hat seither defekte Sektoren. Ich kopiere jetzt wo ich schreibe wieder was und die 2. HDD ist eben abgeschmiert. SMART wird sich auch hier sicher gleich melden.
Alles in allem kann ich nur sagen, dass das gesamte System in diesem Zustand nicht gut für meine Platten ist.
Wie kann sowas sein. Board hat einen AMD Chip mit 890GX Chipsatz.
Viele Grüße
aesis
Edit: eben reines kopieren in keinen TrueCrypt Container probiert und hier habe ich dieses Problem nicht.
P.S. die andere Platte hat keine SMART Fehler. Die 1. auch nur einen Pending Sektor -> bestimmt als sie abgeschaltet hat.
ich habe in meinem NAS 4 gleiche 2TB Samsung HDDs. Die Clients gehen über SAMBA drauf. Auf jeder HDD (alle UFS mit 5% freiem Speicher) liegen TrueCrypt Container mit NTFS Dateisystem. Die Klient-OS sind Windows 7 bis 8. Sind nun die Container gemountet und schreibe ich große Dateien drauf, oder die Gesamtgröße der Dateien ist mehrere GB, so läuft eine Zeit lang die HDD ruhig und ich habe angeblich eine Übertragungsrate von ~90MB/sec.
Nach einiger Zeit bricht diese aber auf ~30MB/sec. ein und die Platte fängt an zu rödeln bis der Arzt kommt.
Gleiches ist bei den anderen Platten zu erkennen. Gestern ist mir nach so einem Vorgang eine HDD abgeschmiert (während des kopierens ist die Festplatte vom NAS System nicht mehr auffindbar und muss via Strom aus -an neu gestartet werden) und hat seither defekte Sektoren. Ich kopiere jetzt wo ich schreibe wieder was und die 2. HDD ist eben abgeschmiert. SMART wird sich auch hier sicher gleich melden.
Alles in allem kann ich nur sagen, dass das gesamte System in diesem Zustand nicht gut für meine Platten ist.
Wie kann sowas sein. Board hat einen AMD Chip mit 890GX Chipsatz.
Viele Grüße
aesis
Edit: eben reines kopieren in keinen TrueCrypt Container probiert und hier habe ich dieses Problem nicht.
P.S. die andere Platte hat keine SMART Fehler. Die 1. auch nur einen Pending Sektor -> bestimmt als sie abgeschaltet hat.
-
aesis
- NewUser

- Posts: 13
- Joined: 01 Apr 2013 15:32
- Status: Offline
Re: UFS Filesystem langsames schreiben
Scheinbar hat NAS4Free gravierende Probleme mit Verschlüsselungen. Kaum verschlüssel ich meine HDD mit dem systemeigenen Verschlüsselungsdienst, formatiere neu, mounte und fange an zu kopieren geht das gleiche Spiel wieder los:
~50MB/sec (mehr schafft der Prozzi bei AES 256 nicht) und Festplatte ruhig, dann rattern und Datenrate bricht ein usw.
Das heißt für mich: tschüss, da ich so ein System nicht gebrauchen kann.
~50MB/sec (mehr schafft der Prozzi bei AES 256 nicht) und Festplatte ruhig, dann rattern und Datenrate bricht ein usw.
Das heißt für mich: tschüss, da ich so ein System nicht gebrauchen kann.
- NKL
- Advanced User

- Posts: 187
- Joined: 03 Feb 2013 17:03
- Status: Offline
Re: UFS Filesystem langsames schreiben
Wie hast du denn jetzt die Platten formatiert? Oben steht UFS, dann im zweiten Satz steht NTFS?
Man liest ja des Öfteren, dass N4F mit NTFS Dateisystemen größere Probleme hat und man diese nicht nutzen sollte.
Man liest ja des Öfteren, dass N4F mit NTFS Dateisystemen größere Probleme hat und man diese nicht nutzen sollte.
Case: MS-Tech CA-0270GR Xerxes | MB: Asrock C2550D4I | CPU: Intel Avoton C2550 Quad-Core @ 2.40GHz | RAM: 2x 8GB Samsung DDR3 PC1600 CL11 ECC | OS: x64-embedded 9.2.0.1 - Shigawire (Revision 972), on USB-Stick | Storage: 5x2TB Seagate Barracuda on RaidZ1 array, 2x4TB WD Red on ZFS mirror -> in Inter-Tech HDD-Draw-Out frames
-
aesis
- NewUser

- Posts: 13
- Joined: 01 Apr 2013 15:32
- Status: Offline
Re: UFS Filesystem langsames schreiben
Die Platten sind alle in UFS formatiert. Auf den Platten waren TrueCrypt Container, welche in NTFS formatiert sind und Daten beinhalten.
Ich habe also immer die Container vom NAS gemountet und dann die Daten hin und her geschubst.
Selbst wenn ich Daten auf eine systemeigens verschlüsselte Partition schiebe habe ich nur Ärger und langsame Datenraten, als auch Fehler von Kopiervorgängen, welche aus unbekannten Gründen nicht vollzogen werden konnten.
Ist die Platte nur in UFS, also komplett unverschlüsselt klappt alles normal, doch sobald sie verschlüsselt ist nicht.
Ich habe also immer die Container vom NAS gemountet und dann die Daten hin und her geschubst.
Selbst wenn ich Daten auf eine systemeigens verschlüsselte Partition schiebe habe ich nur Ärger und langsame Datenraten, als auch Fehler von Kopiervorgängen, welche aus unbekannten Gründen nicht vollzogen werden konnten.
Ist die Platte nur in UFS, also komplett unverschlüsselt klappt alles normal, doch sobald sie verschlüsselt ist nicht.
-
aesis
- NewUser

- Posts: 13
- Joined: 01 Apr 2013 15:32
- Status: Offline
Re: UFS Filesystem langsames schreiben
Da wird doch der Hund in der Pfanne verrückt. Ich hatte nun, bevor ich N4F gelöscht hätte, mal FTP probiert und da lief alles super. Nochmal die Samba Einstellungen angeschaut und mal AIO deaktiviert und siehe da es läuft -.-
Ich hatte nie gedacht, dass das zu so herben Fehlern führen würde. Da kann ich ja jetzt doch N4F laufen lassen. Jetzt muss ich nurnoch den Netbios Fehler von Samba mit dem Domain Name loswerden.
Ich hatte nie gedacht, dass das zu so herben Fehlern führen würde. Da kann ich ja jetzt doch N4F laufen lassen. Jetzt muss ich nurnoch den Netbios Fehler von Samba mit dem Domain Name loswerden.
- shakky4711
- Advanced User

- Posts: 273
- Joined: 25 Jun 2012 08:27
- Status: Offline
Re: UFS Filesystem langsames schreiben
Hallo,
schreib mal bitte welche NAS4Free Version Du hast, diese Unverträglichkeit von SMB2 in Verbindung mit AIO sollte in der aktuellen Version doch schon gefixt sein wie ich gelesen habe.
Gruß
Shakky
schreib mal bitte welche NAS4Free Version Du hast, diese Unverträglichkeit von SMB2 in Verbindung mit AIO sollte in der aktuellen Version doch schon gefixt sein wie ich gelesen habe.
Gruß
Shakky
-
aesis
- NewUser

- Posts: 13
- Joined: 01 Apr 2013 15:32
- Status: Offline
Re: UFS Filesystem langsames schreiben
Ich hab die 9.1.0.1 - Sandstorm (Revision 636) FreeBSD 9.1-RELEASE (reldate 901000)
-
jasch
- experienced User

- Posts: 136
- Joined: 25 Jun 2012 10:25
- Location: Germany
- Status: Offline
Re: UFS Filesystem langsames schreiben
Davon ab, wenn das Netzwerk ordentlich funktioniert bringt AIO eh nix.
Habe es auch aus, da es mehr Probleme bringt als nutzt und trotzdem 100MB+.
Im Prinzip macht es ja nur den speicher voll sprich asyncrones schreiben/lesen das kann etwas bringen bei kleinen Datenmengen, wenn die HDDs zu langsam sind sonst aber eh nix.
Habe es auch aus, da es mehr Probleme bringt als nutzt und trotzdem 100MB+.
Im Prinzip macht es ja nur den speicher voll sprich asyncrones schreiben/lesen das kann etwas bringen bei kleinen Datenmengen, wenn die HDDs zu langsam sind sonst aber eh nix.
Last edited by jasch on 02 Apr 2013 12:54, edited 1 time in total.
XigmaNAS 12.0.0.4 (6625)@PROXMOX 5.V - Supermicro X8DTH-6F | 2x Xeon L5640 | 96GB ECC | LSI 9210-8i|LSI 9500-8e|LSI 9201-16i | 40GBe IB Mellanox |
-
aesis
- NewUser

- Posts: 13
- Joined: 01 Apr 2013 15:32
- Status: Offline
Re: UFS Filesystem langsames schreiben
Hm naja komsich ist Samba aber schon. Klar geht bei vielen kleinen Daten die Rate runter wegen der Verzögerungszeit der Platte, doch auch bei großen Daten habe ich mal nur 20MB/sec und bei anderen dann mal wieder 55MB/sec, wo der Prozessor durch AES 256 dann limitiert.
- Princo
- Forum Moderator

- Posts: 1080
- Joined: 15 Jul 2012 01:21
- Location: Berlin, Germany
- Status: Offline
Re: UFS Filesystem langsames schreiben
Das sind nicht zufällig unfertige Bittorrent-Dateien? Da ist diese hohe Geschwindigkeit nämlich völlig normal, weil das Sparse-Dateien sind.aesis wrote:bei großen Daten habe ich mal nur 20MB/sec und bei anderen dann mal wieder 55MB/sec, wo der Prozessor durch AES 256 dann limitiert.
Meine Antworten beziehen sich immer auf die englischsprachige GUI. ECC-RAM ist Pflicht beim Einsatz von ZFS.
-
aesis
- NewUser

- Posts: 13
- Joined: 01 Apr 2013 15:32
- Status: Offline
Re: UFS Filesystem langsames schreiben
Nein sind in meinem Fall alles mkv Filme >8GB.
- Princo
- Forum Moderator

- Posts: 1080
- Joined: 15 Jul 2012 01:21
- Location: Berlin, Germany
- Status: Offline
Re: UFS Filesystem langsames schreiben
OK, dann schlüsseln wir dein Problem mal auf:
Dein NAS hat kein kein Problem mit Verschlüsselung, wie du es oben angedeutet hast. Wenn du deine TrueCrypt-Container bearbeitest, "weiß" das NAS gar nichts von der Verschlüsselung. Aus der Sicht des NAS bearbeitest du einfach nur eine sehr große Datei, und das sollte eigentlich kein Problem darstellen. Einziger Ansatzpunkt wäre eine Überprüfung der CIFS/SMB Konfiguration, sowie die Client-Konfiguration (also dein Windows).
Wie groß sind denn die TC-Container? Hast du bei der Netzkonfig an den MTU-Werten etwas verändert?
Zu den Platten: Daß Platten ausfallen ist zwar ärgerlich, aber es kommt eben vor. Daher sollte man solche Installationen immer mit Redundanz, also Soft-Raid, oder besser RaidZ betreiben. Allerdings ist das von dir beschriebene Verhalten schon ziemlich ungewöhnlich.
Könntest du bitte mal die SMART-Infos deiner Installation posten (Diagnostics -> Information -> S.M.A.R.T.)?
Dein NAS hat kein kein Problem mit Verschlüsselung, wie du es oben angedeutet hast. Wenn du deine TrueCrypt-Container bearbeitest, "weiß" das NAS gar nichts von der Verschlüsselung. Aus der Sicht des NAS bearbeitest du einfach nur eine sehr große Datei, und das sollte eigentlich kein Problem darstellen. Einziger Ansatzpunkt wäre eine Überprüfung der CIFS/SMB Konfiguration, sowie die Client-Konfiguration (also dein Windows).
Wie groß sind denn die TC-Container? Hast du bei der Netzkonfig an den MTU-Werten etwas verändert?
Zu den Platten: Daß Platten ausfallen ist zwar ärgerlich, aber es kommt eben vor. Daher sollte man solche Installationen immer mit Redundanz, also Soft-Raid, oder besser RaidZ betreiben. Allerdings ist das von dir beschriebene Verhalten schon ziemlich ungewöhnlich.
Könntest du bitte mal die SMART-Infos deiner Installation posten (Diagnostics -> Information -> S.M.A.R.T.)?
Meine Antworten beziehen sich immer auf die englischsprachige GUI. ECC-RAM ist Pflicht beim Einsatz von ZFS.
- Princo
- Forum Moderator

- Posts: 1080
- Joined: 15 Jul 2012 01:21
- Location: Berlin, Germany
- Status: Offline
Re: UFS Filesystem langsames schreiben
Nachtrag:
Ich befürchte, daß du deine TC-Container sehr groß gemacht hast. Für dich stellen sich die Container ja als Laufwerke dar, und du veränderst immer nur relativ kleine Teile davon. Aber wenn du die Container schließt, dann werden die die kompletten Containerdateien neu abgespeichert.
Damit das problemlos funktioniert, brauchst du aber auf der bereffenden UFS-Platte immer mindestens soviel freien Platz, wie die Gesamtgröße der aktuell gleichzeitig geöffneten TC-Container auf der Platte, eher sogar noch wesentlich mehr.
Das würde das seltsame Schreibverhalten erklären. Das hängt mit dem Journaling zusammen, denn du überschreibst die Daten nicht wirklich, sondern die neue Dateiversion wird geschrieben, und danach wird die alte Datei gelöscht. Und bei sehr großen Dateien und hohen Belegungsgrad der Platte wird dein System kurzzeitig "auf der letzten Rille laufen".
Lösung: kleinere TC-Container benutzen, genügend freien Platz auf den Platten lassen.
Bessere Lösung: System auf ZFS (RaidZ1) umstellen, iSCSI-Laufwerke einrichten, Windows für iSCSI konfigurieren, mit der TC-Laufwerksverschlüsselung die iSCSI-Lw bearbeiten. Das bringt dir Ausfallsicherheit und Geschwindigkeit.
So würde ich das machen.
Ich befürchte, daß du deine TC-Container sehr groß gemacht hast. Für dich stellen sich die Container ja als Laufwerke dar, und du veränderst immer nur relativ kleine Teile davon. Aber wenn du die Container schließt, dann werden die die kompletten Containerdateien neu abgespeichert.
Damit das problemlos funktioniert, brauchst du aber auf der bereffenden UFS-Platte immer mindestens soviel freien Platz, wie die Gesamtgröße der aktuell gleichzeitig geöffneten TC-Container auf der Platte, eher sogar noch wesentlich mehr.
Das würde das seltsame Schreibverhalten erklären. Das hängt mit dem Journaling zusammen, denn du überschreibst die Daten nicht wirklich, sondern die neue Dateiversion wird geschrieben, und danach wird die alte Datei gelöscht. Und bei sehr großen Dateien und hohen Belegungsgrad der Platte wird dein System kurzzeitig "auf der letzten Rille laufen".
Lösung: kleinere TC-Container benutzen, genügend freien Platz auf den Platten lassen.
Bessere Lösung: System auf ZFS (RaidZ1) umstellen, iSCSI-Laufwerke einrichten, Windows für iSCSI konfigurieren, mit der TC-Laufwerksverschlüsselung die iSCSI-Lw bearbeiten. Das bringt dir Ausfallsicherheit und Geschwindigkeit.
So würde ich das machen.
Meine Antworten beziehen sich immer auf die englischsprachige GUI. ECC-RAM ist Pflicht beim Einsatz von ZFS.
-
bense
- Starter

- Posts: 32
- Joined: 06 Jan 2013 09:33
- Status: Offline
Re: UFS Filesystem langsames schreiben
meines wissens nach wird in einen tc nur der echt veränderte wert gesichert.
das soll heißen, wenn der tc zb:2TB groß ist und mann darin 1MB ändert, wird auch nur dieser eine MB geschrieben und nicht die vollen 2TB.
das gegenteil wäre wenn die bearbeitete datei 2TB hat dann sieht es natürlich anders aus, da n4f meines wissens kein inkrementelles verwalten hat wie zb: Dropbox.
ich hoffe ich habe mit meinen letzten satz recht.
das soll heißen, wenn der tc zb:2TB groß ist und mann darin 1MB ändert, wird auch nur dieser eine MB geschrieben und nicht die vollen 2TB.
das gegenteil wäre wenn die bearbeitete datei 2TB hat dann sieht es natürlich anders aus, da n4f meines wissens kein inkrementelles verwalten hat wie zb: Dropbox.
ich hoffe ich habe mit meinen letzten satz recht.
-
aesis
- NewUser

- Posts: 13
- Joined: 01 Apr 2013 15:32
- Status: Offline
Re: UFS Filesystem langsames schreiben
Naja ich hab 5% freien Speicher gelassen und hatte somit noch 1,6xTB nutzbaren Speicher von 1,8TB.
Den gesamten Speicher hab ich natürlich ausgenutzt.
1. Platte + 2. Platte (Backup) nur ein Contailer ala 1,6TB
3. Platte + 4. Platte (Backup) 4 Container mit insg. 1,6TB
Ich hab das ganze jetzt komplett geändert: TC Container weg und die Platten über N4F verschlüsselt. Geht zwar nur 1-phasig und keine Keyfiles, aber nunja...
Hier mal jetzt noch die SMART Werte. Der Pending Sektor der 1. HDD ist wieder weg - konnte also wieder geschrieben werden. Warum die Platte, sowie die 2. allerdings so viele G-Sence Fehler hat weiß ich nicht. Die Platten sind in einem Rack und dieser wackelt wohl nicht.
Den gesamten Speicher hab ich natürlich ausgenutzt.
1. Platte + 2. Platte (Backup) nur ein Contailer ala 1,6TB
3. Platte + 4. Platte (Backup) 4 Container mit insg. 1,6TB
Ich hab das ganze jetzt komplett geändert: TC Container weg und die Platten über N4F verschlüsselt. Geht zwar nur 1-phasig und keine Keyfiles, aber nunja...
Hier mal jetzt noch die SMART Werte. Der Pending Sektor der 1. HDD ist wieder weg - konnte also wieder geschrieben werden. Warum die Platte, sowie die 2. allerdings so viele G-Sence Fehler hat weiß ich nicht. Die Platten sind in einem Rack und dieser wackelt wohl nicht.
Code: Select all
Gerät /dev/ada0 - SAMSUNG HD204UI 1AQ10001
=== START OF INFORMATION SECTION ===
Model Family: SAMSUNG SpinPoint F4 EG (AF)
Device Model: SAMSUNG HD204UI
Serial Number: xxxxxxxxxx8652
LU WWN Device Id: 5 0024e9 205b71bb2
Firmware Version: 1AQ10001
User Capacity: 2,000,398,934,016 bytes [2.00 TB]
Sector Size: 512 bytes logical/physical
Rotation Rate: 5400 rpm
Device is: In smartctl database [for details use: -P show]
ATA Version is: ATA8-ACS T13/1699-D revision 6
SATA Version is: SATA 2.6, 3.0 Gb/s
Local Time is: Thu Apr 4 14:13:01 2013 CEST
==> WARNING: Using smartmontools or hdparm with this
drive may result in data loss due to a firmware bug.
****** THIS DRIVE MAY OR MAY NOT BE AFFECTED! ******
Buggy and fixed firmware report same version number!
See the following web pages for details:
http://knowledge.seagate.com/articles/en_US/FAQ/223571en
http://sourceforge.net/apps/trac/smartmontools/wiki/SamsungF4EGBadBlocks
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
See vendor-specific Attribute list for marginal Attributes.
General SMART Values:
Offline data collection status: (0x00) Offline data collection activity
was never started.
Auto Offline Data Collection: Disabled.
Self-test execution status: ( 121) The previous self-test completed having
the read element of the test failed.
Total time to complete Offline
data collection: (20580) seconds.
Offline data collection
capabilities: (0x5b) SMART execute Offline immediate.
Auto Offline data collection on/off 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: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 343) minutes.
SCT capabilities: (0x003f) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.
SMART Attributes Data Structure revision number: 16
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 051 Pre-fail Always - 476
2 Throughput_Performance 0x0026 252 252 000 Old_age Always - 0
3 Spin_Up_Time 0x0023 068 020 025 Pre-fail Always In_the_past 9842
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 65
5 Reallocated_Sector_Ct 0x0033 252 252 010 Pre-fail Always - 0
7 Seek_Error_Rate 0x002e 252 252 051 Old_age Always - 0
8 Seek_Time_Performance 0x0024 252 252 015 Old_age Offline - 0
9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 462
10 Spin_Retry_Count 0x0032 252 252 051 Old_age Always - 0
11 Calibration_Retry_Count 0x0032 252 252 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 54
181 Program_Fail_Cnt_Total 0x0022 100 100 000 Old_age Always - 122522
191 G-Sense_Error_Rate 0x0022 098 098 000 Old_age Always - 24008
192 Power-Off_Retract_Count 0x0022 252 252 000 Old_age Always - 0
194 Temperature_Celsius 0x0002 060 054 000 Old_age Always - 40 (Min/Max 14/46)
195 Hardware_ECC_Recovered 0x003a 100 100 000 Old_age Always - 0
196 Reallocated_Event_Count 0x0032 252 252 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 252 100 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 252 252 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0036 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x002a 100 100 000 Old_age Always - 54
223 Load_Retry_Count 0x0032 252 252 000 Old_age Always - 0
225 Load_Cycle_Count 0x0032 100 100 000 Old_age Always - 69
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed: read failure 90% 367 1689518616
SMART Selective self-test log data structure revision number 0
Note: revision number not 1 implies that no selective self-test has ever been run
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Completed_read_failure [90% left] (0-65535)
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.
Gerät /dev/ada1 - SAMSUNG HD204UI 1AQ10001
=== START OF INFORMATION SECTION ===
Model Family: SAMSUNG SpinPoint F4 EG (AF)
Device Model: SAMSUNG HD204UI
Serial Number: xxxxxxxxxx8651
LU WWN Device Id: 5 0024e9 205b71b95
Firmware Version: 1AQ10001
User Capacity: 2,000,398,934,016 bytes [2.00 TB]
Sector Size: 512 bytes logical/physical
Rotation Rate: 5400 rpm
Device is: In smartctl database [for details use: -P show]
ATA Version is: ATA8-ACS T13/1699-D revision 6
SATA Version is: SATA 2.6, 3.0 Gb/s
Local Time is: Thu Apr 4 14:13:02 2013 CEST
==> WARNING: Using smartmontools or hdparm with this
drive may result in data loss due to a firmware bug.
****** THIS DRIVE MAY OR MAY NOT BE AFFECTED! ******
Buggy and fixed firmware report same version number!
See the following web pages for details:
http://knowledge.seagate.com/articles/en_US/FAQ/223571en
http://sourceforge.net/apps/trac/smartmontools/wiki/SamsungF4EGBadBlocks
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: (0x00) Offline data collection activity
was never started.
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: (20520) seconds.
Offline data collection
capabilities: (0x5b) SMART execute Offline immediate.
Auto Offline data collection on/off 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: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 342) minutes.
SCT capabilities: (0x003f) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.
SMART Attributes Data Structure revision number: 16
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 051 Pre-fail Always - 0
2 Throughput_Performance 0x0026 252 252 000 Old_age Always - 0
3 Spin_Up_Time 0x0023 069 043 025 Pre-fail Always - 9683
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 61
5 Reallocated_Sector_Ct 0x0033 252 252 010 Pre-fail Always - 0
7 Seek_Error_Rate 0x002e 252 252 051 Old_age Always - 0
8 Seek_Time_Performance 0x0024 252 252 015 Old_age Offline - 0
9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 418
10 Spin_Retry_Count 0x0032 252 252 051 Old_age Always - 0
11 Calibration_Retry_Count 0x0032 252 252 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 50
181 Program_Fail_Cnt_Total 0x0022 100 100 000 Old_age Always - 217617
191 G-Sense_Error_Rate 0x0022 100 100 000 Old_age Always - 2172
192 Power-Off_Retract_Count 0x0022 252 252 000 Old_age Always - 0
194 Temperature_Celsius 0x0002 060 054 000 Old_age Always - 40 (Min/Max 14/46)
195 Hardware_ECC_Recovered 0x003a 100 100 000 Old_age Always - 0
196 Reallocated_Event_Count 0x0032 252 252 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 252 252 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 252 252 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0036 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x002a 100 100 000 Old_age Always - 2
223 Load_Retry_Count 0x0032 252 252 000 Old_age Always - 0
225 Load_Cycle_Count 0x0032 100 100 000 Old_age Always - 63
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed without error 00% 325 -
SMART Selective self-test log data structure revision number 0
Note: revision number not 1 implies that no selective self-test has ever been run
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Completed [00% left] (0-65535)
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.
Gerät /dev/ada2 - SAMSUNG HD204UI 1AQ10001
=== START OF INFORMATION SECTION ===
Model Family: SAMSUNG SpinPoint F4 EG (AF)
Device Model: SAMSUNG HD204UI
Serial Number: xxxxxxxxxx5990
LU WWN Device Id: 5 0024e9 205fd427e
Firmware Version: 1AQ10001
User Capacity: 2,000,398,934,016 bytes [2.00 TB]
Sector Size: 512 bytes logical/physical
Rotation Rate: 5400 rpm
Device is: In smartctl database [for details use: -P show]
ATA Version is: ATA8-ACS T13/1699-D revision 6
SATA Version is: SATA 2.6, 3.0 Gb/s
Local Time is: Thu Apr 4 14:13:03 2013 CEST
==> WARNING: Using smartmontools or hdparm with this
drive may result in data loss due to a firmware bug.
****** THIS DRIVE MAY OR MAY NOT BE AFFECTED! ******
Buggy and fixed firmware report same version number!
See the following web pages for details:
http://knowledge.seagate.com/articles/en_US/FAQ/223571en
http://sourceforge.net/apps/trac/smartmontools/wiki/SamsungF4EGBadBlocks
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: (0x00) Offline data collection activity
was never started.
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: (20040) seconds.
Offline data collection
capabilities: (0x5b) SMART execute Offline immediate.
Auto Offline data collection on/off 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: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 334) minutes.
SCT capabilities: (0x003f) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.
SMART Attributes Data Structure revision number: 16
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 051 Pre-fail Always - 0
2 Throughput_Performance 0x0026 252 252 000 Old_age Always - 0
3 Spin_Up_Time 0x0023 067 063 025 Pre-fail Always - 10006
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 265
5 Reallocated_Sector_Ct 0x0033 252 252 010 Pre-fail Always - 0
7 Seek_Error_Rate 0x002e 252 252 051 Old_age Always - 0
8 Seek_Time_Performance 0x0024 252 252 015 Old_age Offline - 0
9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 390
10 Spin_Retry_Count 0x0032 252 252 051 Old_age Always - 0
11 Calibration_Retry_Count 0x0032 252 252 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 92
181 Program_Fail_Cnt_Total 0x0022 100 100 000 Old_age Always - 263063
191 G-Sense_Error_Rate 0x0022 100 100 000 Old_age Always - 4
192 Power-Off_Retract_Count 0x0022 252 252 000 Old_age Always - 0
194 Temperature_Celsius 0x0002 064 047 000 Old_age Always - 34 (Min/Max 15/53)
195 Hardware_ECC_Recovered 0x003a 100 100 000 Old_age Always - 0
196 Reallocated_Event_Count 0x0032 252 252 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 252 252 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 252 252 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0036 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x002a 100 100 000 Old_age Always - 1
223 Load_Retry_Count 0x0032 252 252 000 Old_age Always - 0
225 Load_Cycle_Count 0x0032 100 100 000 Old_age Always - 271
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed without error 00% 295 -
SMART Selective self-test log data structure revision number 0
Note: revision number not 1 implies that no selective self-test has ever been run
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Completed [00% left] (0-65535)
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.
Gerät /dev/ada3 - SAMSUNG HD204UI 1AQ10001
=== START OF INFORMATION SECTION ===
Model Family: SAMSUNG SpinPoint F4 EG (AF)
Device Model: SAMSUNG HD204UI
Serial Number: xxxxxxxxxx5986
LU WWN Device Id: 5 0024e9 205fd427a
Firmware Version: 1AQ10001
User Capacity: 2,000,398,934,016 bytes [2.00 TB]
Sector Size: 512 bytes logical/physical
Rotation Rate: 5400 rpm
Device is: In smartctl database [for details use: -P show]
ATA Version is: ATA8-ACS T13/1699-D revision 6
SATA Version is: SATA 2.6, 3.0 Gb/s
Local Time is: Thu Apr 4 14:13:04 2013 CEST
==> WARNING: Using smartmontools or hdparm with this
drive may result in data loss due to a firmware bug.
****** THIS DRIVE MAY OR MAY NOT BE AFFECTED! ******
Buggy and fixed firmware report same version number!
See the following web pages for details:
http://knowledge.seagate.com/articles/en_US/FAQ/223571en
http://sourceforge.net/apps/trac/smartmontools/wiki/SamsungF4EGBadBlocks
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: (0x00) Offline data collection activity
was never started.
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: (20760) seconds.
Offline data collection
capabilities: (0x5b) SMART execute Offline immediate.
Auto Offline data collection on/off 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: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 346) minutes.
SCT capabilities: (0x003f) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.
SMART Attributes Data Structure revision number: 16
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 051 Pre-fail Always - 0
2 Throughput_Performance 0x0026 252 252 000 Old_age Always - 0
3 Spin_Up_Time 0x0023 067 066 025 Pre-fail Always - 10273
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 149
5 Reallocated_Sector_Ct 0x0033 252 252 010 Pre-fail Always - 0
7 Seek_Error_Rate 0x002e 252 252 051 Old_age Always - 0
8 Seek_Time_Performance 0x0024 252 252 015 Old_age Offline - 0
9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 268
10 Spin_Retry_Count 0x0032 252 252 051 Old_age Always - 0
11 Calibration_Retry_Count 0x0032 252 252 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 64
181 Program_Fail_Cnt_Total 0x0022 100 100 000 Old_age Always - 418183
191 G-Sense_Error_Rate 0x0022 100 100 000 Old_age Always - 1
192 Power-Off_Retract_Count 0x0022 252 252 000 Old_age Always - 0
194 Temperature_Celsius 0x0002 064 064 000 Old_age Always - 31 (Min/Max 15/36)
195 Hardware_ECC_Recovered 0x003a 100 100 000 Old_age Always - 0
196 Reallocated_Event_Count 0x0032 252 252 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 252 252 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 252 252 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0036 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x002a 100 100 000 Old_age Always - 2
223 Load_Retry_Count 0x0032 252 252 000 Old_age Always - 0
225 Load_Cycle_Count 0x0032 100 100 000 Old_age Always - 154
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed without error 00% 174 -
SMART Selective self-test log data structure revision number 0
Note: revision number not 1 implies that no selective self-test has ever been run
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Completed [00% left] (0-65535)
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.
-
jtk
- NewUser

- Posts: 12
- Joined: 26 Jun 2012 21:39
- Status: Offline
Re: UFS Filesystem langsames schreiben
Hallo easis welche schreibgeschwindigkeit hast du nun mit deinen verschlüsselten Platten. Ich hatte im freenas um die 30MB/s nun nur noch 10-14MB/s
Gruß jtk
Gruß jtk
-
aesis
- NewUser

- Posts: 13
- Joined: 01 Apr 2013 15:32
- Status: Offline
Re: UFS Filesystem langsames schreiben
Bei AES 256 50-60MB/sec und das nur, weil der Prozessor dann voll ausgelastet ist.
- Princo
- Forum Moderator

- Posts: 1080
- Joined: 15 Jul 2012 01:21
- Location: Berlin, Germany
- Status: Offline
Re: UFS Filesystem langsames schreiben
Tja, da hätten wir doch einen ganz starken Hinweis auf den Fehler. Stadardmäßig sind nämlich 8% freier Platz vorgesehen. Und was passiert, wenn man den Wert senkt?aesis wrote:Naja ich hab 5% freien Speicher gelassen und hatte somit noch 1,6xTB nutzbaren Speicher von 1,8TB.
Steht gleich daneben: "Bedenken Sie, dass das Absenken des Schwellenwertes sowohl die Performance als auch die Auto-Defragmentation nachteilig beeinflussen kann."
Zum Stichwort Auto-Defragmentation unter UFS findet sich dieser Link: Klick
Rein technisch gesehen, beschreibt der Text dein Problem ziemlich genau. Die Lösung des Problems hatte ich weiter oben schon beschrieben.
OK, ich verstehe. In deiner Konfiguration geht es dir darum, eigene und technische Fehler abzufangen (eigene Fehler: Datei versehentlich gelöscht, technischer Fehler: Plattenausfall).Den gesamten Speicher hab ich natürlich ausgenutzt.
1. Platte + 2. Platte (Backup) nur ein Contailer ala 1,6TB
3. Platte + 4. Platte (Backup) 4 Container mit insg. 1,6TB
Technisch können dir bis zu 2 Platten ausfallen, wenn es denn die richtigen sind, ohne daß du alle Daten verlierst.
Ich würde dennoch empfehlen, dich vom UFS zu verabschieden, und deine Platten zu einem ZFS-RaidZ1 Verbund zusammen zu schließen. Dann hättest du 6TB freien Platz und wärst für den Ausfall einer Platte exzellent gerüstet.
Gagen das versehentliche Löschen (menschlicher Fehler) könntest du bei ZFS mit Snapshots arbeiten. Der Vorteil gegenüber deiner jetzigen Methode wäre, daß die Umkopieraktionen auf die Backup-Platten quasi wegfallen würden.
Nachteil: Um auf ZFS umzusteigen müsstest du deine Daten vorübergehend auslagern. Zudem müßtest du dich von deiner laufwerksorientierten Arbeitsweise verabschieden. Beides wäre lösbar.
Was hast du nur für Daten auf deinen Platten? Raketenabschußcodes? (Den konnte ich mir nicht verkneifenIch hab das ganze jetzt komplett geändert: TC Container weg und die Platten über N4F verschlüsselt. Geht zwar nur 1-phasig und keine Keyfiles, aber nunja...
Ich habe übrigens ein paar Performance-Tests zu Truecrypt auf ZFS mit iSCSI-Laufwerksverschlüsselung oder mit TC-Container-Dateien gemacht. Falls da noch Bedarf besteht, könnte ich sie hochladen.
Diese G-Sense Fehler sind tatsächlich seltsam. Beobachte mal, ob die sich verändern.Hier mal jetzt noch die SMART Werte. Der Pending Sektor der 1. HDD ist wieder weg - konnte also wieder geschrieben werden. Warum die Platte, sowie die 2. allerdings so viele G-Sence Fehler hat weiß ich nicht. Die Platten sind in einem Rack und dieser wackelt wohl nicht.
Meine Antworten beziehen sich immer auf die englischsprachige GUI. ECC-RAM ist Pflicht beim Einsatz von ZFS.
-
aesis
- NewUser

- Posts: 13
- Joined: 01 Apr 2013 15:32
- Status: Offline
Re: UFS Filesystem langsames schreiben
Der G-Sense Wert steigt ständig. Ist jetzt schon bei 24033. Die Platte wird diese Woche eingeschickt.
Naja ich hatte mal ein RAID 5 aus 6 Platten doch ein falscher Handgriff und vieles war weg. Seither geh ich auf Nummer sicher und separiere alles. Ich hatte gelesen, dass 5% das Minimum für UFS seien und daher hab ich das auch genommen.
Die Performance von ~55MB/sec für die alte kleine AMD 270u CPU reichen mir und Sicherheit habe ich ja. Das doppelte kopieren kann ich verkraften.
Naja ich hatte mal ein RAID 5 aus 6 Platten doch ein falscher Handgriff und vieles war weg. Seither geh ich auf Nummer sicher und separiere alles. Ich hatte gelesen, dass 5% das Minimum für UFS seien und daher hab ich das auch genommen.
Die Performance von ~55MB/sec für die alte kleine AMD 270u CPU reichen mir und Sicherheit habe ich ja. Das doppelte kopieren kann ich verkraften.
- Princo
- Forum Moderator

- Posts: 1080
- Joined: 15 Jul 2012 01:21
- Location: Berlin, Germany
- Status: Offline
Re: UFS Filesystem langsames schreiben
Das verstehe ich. Wenn man da einmal so schlechte Erfahrungen gemacht hat, ist man sehr vorsichtig.aesis wrote:Naja ich hatte mal ein RAID 5 aus 6 Platten doch ein falscher Handgriff und vieles war weg. Seither geh ich auf Nummer sicher und separiere alles.
Allerdings ist RaidZ da eine etwas andere Liga, und nur annähernd mit Raid zu vergleichen. Bei RaidZ ist es z.B. vollkommen egal, an welchem System, und in welcher Reihenfolge man die Platten anschließt, es funktioniert immer. Plattenausfälle hatte ich auch schon, aber dank RaidZ habe ich dabei kein einziges Byte verloren.
Ich photographiere viel, und hänge natürlich an meinen Bildern. Habe lange nach einer bezahlbaren Möglichkeit gesucht, diese möglichst sicher abzuspeichern, und erst mit ZFS (und RaidZ) war ich richtig zufrieden. Ich habe sogar ein zusätzliches Backup-NAS im Einsatz, und kann mit simplen Befehlen die Daten in kürzester Zeit synchronisieren. Mit UFS wäre das weder mit der Gechwindigkeit, noch mit der erforderlichen Sicherheit möglich. Das bedeutet nicht, daß UFS schlecht ist, sonder nur, daß mir ZFS genau das bietet, was mir wichig ist.
Und aus diesem Grund kann ich es problemlos empfehlen.
Das ist ein Empfehlungswert für die "normale" Nutzung des Systems. Das ganze System mit einer einzigen, gigantisch großen, Datei zu belegen, zählt aber nicht mehr als "normal". Da sind dann wesentlich höhere Werte anzusetzen.Ich hatte gelesen, dass 5% das Minimum für UFS seien und daher hab ich das auch genommen.
Jo, die Performance ist ganz ok, aber mit der Sicherheit ist das so einie Sache. Deine Backup-Platten sind im gleichen System verbaut, und damit z.B. bei Überspannungen mit gefährdet. Ich habe schon erlebt, wie nach dem Ausfall eines Umspannwerkes die aktiven Platten reihenweise den Serientod gestorben sind. Das kommt zum Glück aber nur sehr selten vor.Die Performance von ~55MB/sec für die alte kleine AMD 270u CPU reichen mir und Sicherheit habe ich ja. Das doppelte kopieren kann ich verkraften.
Meine Antworten beziehen sich immer auf die englischsprachige GUI. ECC-RAM ist Pflicht beim Einsatz von ZFS.
-
aesis
- NewUser

- Posts: 13
- Joined: 01 Apr 2013 15:32
- Status: Offline
Re: UFS Filesystem langsames schreiben
Was muss man denn für ein RaidZ einrichten? Einfach nur Raidcontroller zBsp RAID 5 konfigurieren und dass dann als ZFS? Bei kommender Intel Generation bau ich mir ein neues NAS mit 2x RAID -> 1. Daten und 2. Backup.
- Princo
- Forum Moderator

- Posts: 1080
- Joined: 15 Jul 2012 01:21
- Location: Berlin, Germany
- Status: Offline
Re: UFS Filesystem langsames schreiben
Einen Raidcontroller brauchst du für ZFS nicht, der wäre sogar "schädlich", denn der verhindert, daß du deine Platten im Desasterfall einfach in einen anderen Rechner einbauen könntest. Ein RaidZ funktioniert als Softraid.aesis wrote:Was muss man denn für ein RaidZ einrichten? Einfach nur Raidcontroller zBsp RAID 5 konfigurieren und dass dann als ZFS? Bei kommender Intel Generation bau ich mir ein neues NAS mit 2x RAID -> 1. Daten und 2. Backup.
Für ein RaidZ1 benötigt man mind. 3 Festplatten gleicher Größe. Ich empfehle jedoch 4, weil da der Kapazitätsverlust durch die Redundanz nicht so weht tut. Außerdem sollte der Rechner genügend RAM haben (mind. 4GB, ich packe idR 16GB rein, weil RAM relativ günstig ist).
Als Mainboard setze ich gerne Mini-ITX Boards mit AMD E-350 Prozessor ein. Die verbrauchen nur wenig Strom und haben 5+1 SATA Anschlüsse. Ideal für NAS4Free. Intel-Boards in der gleichen Kategorie sind da übrigens etwas schwächer unterwegs.
Die Form des Backups, wie du es bisher gemacht hast, ist bei ZFS nicht mehr nötig (und nicht sinnvoll). Bei ZFS kannst du Snapshots erstellen, das sind quasi eingefrorene Zustände deines Dateisystems. Man kann beliebig viele Snapshots erstelllen, und zusätzlicher Speicherplatz wird immer nur für veränderte Dateien belegt. Man kann auf die Inhalte der Snapshots (also die einzelnen Dateien) ganz normal über den Dateimanager zugreifen. Das funktioniert bei ZFS simpel und absolut zuverlässig. Mit diesen Snapshots kann man übrigens noch sehr viel mehr anfangen, aber das würde das Thema hier sprengen.
Willst du ein echtes Backup deiner Daten haben (also etwas, was man z.B. in einem anderen Brandabschnitt liegen haben möchte), dann bastelt man sich einfach ein weiteres NAS4Free System. ZFS hat eigene Befehle, um die Daten zu synchronisieren, und das sicher und schnell.
Wie man ein ZFS RaidZ1 einrichtet, wird aktuell >>HIER<< sehr schön beschrieben.
Meine Antworten beziehen sich immer auf die englischsprachige GUI. ECC-RAM ist Pflicht beim Einsatz von ZFS.