Nein und ja, mit etwas forschen funktioniert dieser Befehl zum Auslesen mit smartctl (TS-x64, QTS 5.2.3):
Ohne die Angabe des Device-Typs sata läuft es sonst bei mir auf einen Fehler.
Nein und ja, mit etwas forschen funktioniert dieser Befehl zum Auslesen mit smartctl (TS-x64, QTS 5.2.3):
Ohne die Angabe des Device-Typs sata läuft es sonst bei mir auf einen Fehler.
Antwort von ChatGPT:
ZitatAlles anzeigenSeagate hard drives that support FARM (Full Advanced Read Maintenance) values are typically those designed for enterprise and data center applications. These include drives that provide detailed SMART (Self-Monitoring, Analysis, and Reporting Technology) data, which includes FARM values.
Seagate Drive Series Likely Supporting FARM Values:
1. Seagate Exos Series (Enterprise HDDs)
• Exos X (e.g., X18, X16, X14)
• Exos 7E8, 7E10 (Data Center Drives)
2. Seagate Nytro Series (Enterprise SSDs)
• Some Seagate Nytro SSDs used in data centers may provide similar in-depth logging, but FARM values are primarily associated with HDDs.
3. Seagate IronWolf Pro & Seagate SkyHawk AI
• Some high-end NAS and surveillance drives may include detailed logging and maintenance data, but FARM values are mainly found in enterprise-grade HDDs.
Also möglicherweise keine FARM-Werte bei Ironwolf (ohne Pro)?
OK, man kann mit etwas Mühe auch die FARM-Werte von Seagate HDDs direkt im eingebauten Zustand in der QNAP prüfen. Und zwar wie folgt:
1. MyQNAP-Repo einbinden -> https://www.myqnap.org/install-the-repo/
2. OpenSeachest (CLI) via App Center installieren -> https://www.myqnap.org/product/openseachest-cli/
3. Shell via SSH auf der NAS öffnen
4. Device-Namen der HDDs auslesen:
[/share/Public] # openSeaChest_Logs --scan
==========================================================================================
openSeaChest_Logs - openSeaChest drive utilities - NVMe Enabled
Copyright (c) 2014-2024 Seagate Technology LLC and/or its Affiliates, All Rights Reserved
openSeaChest_Logs Version: 2.5.0-8_0_1 X86_64
Build Date: Oct 15 2024
Today: 20250203T161124 User: root
==========================================================================================
Vendor Handle Model Number Serial Number FwRev
ATA /dev/sg0 ST22000NT001-3LS101 EN01
ATA /dev/sg1 ST22000NT001-3LS101 EN01
ATA /dev/sg2 ST22000NT001-3LS101 EN01
ATA /dev/sg3 ST22000NT001-3LS101 EN01
NVMe /dev/nvme0n1 WD Red SN700 1000GB 111150WD
NVMe /dev/nvme1n1 WD Red SN700 1000GB 111150WD
Alles anzeigen
5. FARM logs speichern:
6. Die erzeugte Datei SERIALNO_FARM_DATUM.bin auf einen Windows Rechner kopieren
7. OpenSeaChestParser herunter laden und auf Windows Rechner entpacken: https://github.com/Seagate/ope…leases/tag/Release_24.5.1
8. Log parsen:
X:\>SeaChest_LogParser_FARM_x64.exe --inputLog XXXXXXXX_FARM_20250203T144540.bin --printType text
9. Finally, in der nun erzeugten Datei öffnen und die Werte prüfen:
03.02.2025 14:56 13.951 XXXXXXXX2_FARM_20250203T144540.txt
},
"Drive Information From Farm Log copy 0" : {
"Model Number" : "ST22000NT001-3LS101",
"Power on Hour" : 1293,
"Spindle Power on hours" : 1293,
"Head Flight Hours - Actuator 0" : 1293,
"Year of Assembled" : "23",
"Week of Assembled" : "33",
Sind davon auch IronWolf HDD betroffen? Leider scheint smartctl für die Ironwolf bei QNAP nicht zu tun:
[~] # smartctl --log=farm /dev/sda
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-5.10.60-qnap] (localbuild)
Copyright (C) 2002-23, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Vendor: Seagate
Product: ST22000NT001-3LS
Revision: EN01
Compliance: SPC-3
User Capacity: 22,000,969,973,760 bytes [22.0 TB]
Logical block size: 512 bytes
Physical block size: 4096 bytes
LU is fully provisioned
Rotation Rate: 7200 rpm
Form Factor: 3.5 inches
Logical Unit id: xxx
Serial number: xxx
Device type: disk
Local Time is: Mon Feb 3 08:06:55 2025 CET
SMART support is: Unavailable - device lacks SMART capability.
FARM log (SCSI Log page 0x3d, sub-page 0x3) not supported
Alles anzeigen
Ja, nach einem 2. Versuch gerade eben was die Installation auf meiner 664 ohne Auffälligkeiten.
Gerade über UI aktualisiert bei meiner Backup NAS (TS-664), bleibt bei 30% hängen und Meldung Volume / sei voll. Nach Reboot alles wieder OK. Also finger weg
So, ich bin jetzt wie folgt vorgegangen:
Fazit: Es stellt kein Problem dar, wenn sich mehrere System-Volume im System befinden. Das erste existierende Volume bleibt das System Volume. Mounts & Filesysteme usw. sind alle wie erwartet, es existieren keine Doppelstrukturen. Lediglich einige Ordner sind auf dem ehemaligen System-Volume zu löschen: .qpgk, homes, Web usw.
Ich habe eine TS-664 NAS mit 2 x 1 TB SSD Raid 1 als System Volume und 6 x 8 TB HDD als Raid5. Als Backup NAS verwende ich eine TS-653D mit 4 x 20 TB HDD.
Ich möchte nun die TS-664 mit den 4 x 20 TB HDD in Zukunft als Backup NAS verwenden und die TS-653D mit den 6 x 8 TB HDD dann verkaufen.
Die SSDs als System Volume sollen bleiben. Kann ich einfach die 4 HDD von der TS-653D in die TS-664 umstecken? Laut NAS Migration auf der QNAP Web Seite geht es.
Aber kann es zu Problemen kommen, weil die SSDs in der neuen NAS ja als System Volume bleiben und das Raid auf den HHDs sich ja auch für ein System Volume hält???
Wie ist eure Erfahrung.
P.S.: Backups sind vorhanden
Laut dem verlinkten Test sollten die EXOS X20 im Idle schon sehr leise und unter Last im noch im besseren Drittel. Auf jedenfall deutlich leiser als meine 8TB WD80EFAX. Leider ist eine X16 nicht dabei, aber die Zwischengeneration X18 wäre lauter als die X20.
Nach den Herstellerangaben sollten die ganzen EXOS X-Serien aber eigentlich gleich laut sein. Die leiseste moderne Platte wäre demnach die Ironwolf Pro 20 TB, die aber preislicht 30% teurer ist als die EXOS X20 20TB.
Hallo allerseits,
mal eine Frage - ist die Seagate EXOS X20 ST20000NM007D kompatibel mit meiner TS-653D?
Die X20 Serie taucht nicht auf der Kompatibilitätsliste auf, nur die X18. Hat vielleicht schon jemand prakische Erfahrungen?
Der Originalartikel ist mittlerweile von QNAP gelöscht worden.
Hier die alte Version der Seite in der Wayback Machine:
Das drawpic-Problem scheint auf meiner TS-653D behoben zu sein, aber auf meiner TS-664 ist es leider immer noch da.
Hello LittleJonny ,
ich hab ein kleines Script zum Löschen von DrawPic nach QTS-Updates:
killall drawPic
mv /usr/share/qnas_console_install/drawPic /usr/share/qnas_console_install/drawPic.bak
Manuell ausführen via SSH.
Bei mir läuft drawPic auch wieder mit 10% obwohl ich die Dateien mit der letzten FW gelöscht hatte. DrawPic wurde beim QTS Update auf 5.0.1 Build 2346 also wieder neu installiert. Update hatte ich gestern gemacht.
Einfach gehandelt
Ich meine, das ist QTS Build 2777 gekommen. Übrigens auch auf meiner TS-653D.
Bei meiner TS-664 kam der Fehler mehrfach wieder (bevor ich die Dateien gelöscht habe). Ich weiß nicht genau, wann genau das passiert ist, aber ich meine, jeweils nach einem Reboot.
Das Problem ist bei mir auch schon mehrfach aufgetreten.
Ich habe dann das drawpic Binary umbenannt und den Ordner mit dem Bild gelöscht, nachdem ich den Prozess gekilled habe.
Mal schauen, ob Ordner und Bild mit dem nächsten QTS-Update zurück kommen.
Meine Beiden NAS hängen am bei mir an einem 2104-2T mit jeweils 2.5GbE. Mein Mac via 10GbE und ein Drucker mit 100MBit und ein Uplink zum Router mit 1GbE.
Habe bisher keinerlei Probleme (knock on wood) gehabt - auch bei Copy Nas-2-NAS via Mac.
Also bei mir, TS-664, 2xSSD System-LW Raid 1, 6 x 8 TB WD Red Raid 5 Encrypted Thick Volume, Mac Ventura 13.2.1. NAS -> Switch mit 2.5GbE und Mac->Switch 10GbE.
Wenn ich einen Ordner mit 3700 Fotos auf dem Mac öffne, dauert es knapp 3 Sekunden bis Finder das Ergebnis zeigt. Dabei springt die NIC der NAS kurz auf 40 Mb/s.
Auf dem MAC via SMB gemounted, default Einstellungen auf dem NAS.
Vielleicht mal einen iPerf-Server auf dem NAS laufen lassen und vom Mac die Ethernet-Leistung messen?