QTS 5.1.1.2491 build 20230815

[rednag]

QNAP hat sein QTS getauftem OS wieder ein neues Update spendiert.
Anhand der Liste der Bugfixes frage ich mich aber ernsthaft ob sowas vor Veröffentlichung wenigstens einmal getestet wurde....
Ich persönlich werde die Meldungen und Erfahrungen der "Early Adopter" abwarten

Security Updates

Applied multiple security updates to further enhance system security.

Enhancement
Network & Virtual Switch

Optimized the switch configuration UI for QGD rackmount series running QTS, with added support for models that do not support PoE.

Control Panel

System Status now displays the statuses of all power supply units on all external storage enclosures, regardless of whether the NAS supports redundant power supply.

Initialization

Users can now configure firmware update settings in the Smart Installation Guide during QTS initialization.

Storage&Snapshots

Upgraded the IronWolf Health Management (IHM) utility to implement support for the latest ST drive models as well as future models within the IHM-supported range.
Upgraded the Western Digital Device Analytics (WDDA) utility to update the generated recommended actions.

Fixed Issues

Fixed an issue where some users would encounter certain unexpected storage issues when reinserting a disk after a firmware update.
Fixed an issue where some users would encounter disk partition issues on a JBOD enclosure after disconnecting and reconnecting the JBOD enclosure.
Fixed an issue where mounting ISO files in File Station would trigger an "Unknown Error" message.
Resolved an issue where the system sometimes could not create a snapshot due to insufficient metadata space.
Fixed an issue where some files could not be recovered when recovering a folder with a large number of files from a recycle bin.
Fixed an issue where some files could not be transferred when dragging and dropping a folder with a large number of files.
Improved Thunderbolt compatibility between M1 macOS computers and QNAP NAS devices.
Fixed an issue where if during shared folder creation the shared folder's path was entered manually, virus files that were later found in the shared folder and sent to quarantine would fail to appear in Control Panel > Applications > Antivirus > Quarantine.
Resolved an issue where macOS devices could not access via Samba any shared folders that were created on a USB drive connected to the NAS.
Fixed an issue where when the system default gateway had an IPv6 address and was connected to a virtual switch, the myQNAPcloud > DDNS page did not display the IPv6 address when My DDNS was enabled.
Fixed an issue in HybridMount where users could not connect to a remote mount via Samba if the password contained certain special characters.
Fixed an issue where when two users were simultaneously logged in to the same NAS and one user performed certain actions on a folder (either in File Station or via Samba from a remote client), the other user would encounter an unexpected error message when trying to access the same folder in File Station.
Addressed an issue where after transferring a massive amount of data through a share link, users would experience reduced speeds when downloading through the share link later.
Fixed an issue where creating a LUN in a volume-less storage pool would trigger a huge amount of repeated logs.
Fixed an issue where users would encounter an erroneous authentication error message and fail to log in to a NAS using a domain user account via Samba.
Resolved a rare issue in HybridMount where users might encounter the HTTP 414 error "Request-URI Too Long" when trying to create a mount connection to OneDrive for Business.
Fixed an issue where users could not open Microsoft Office files in Office Online.
Fixed an issue where if "Always keep SMB file attributes" was enabled in File Station > More > Settings > File Operations, and the user had uploaded a file to the NAS via SMB, copying the file to another folder in File Station would result in the file being stuck in "Preparing" status and the /tmp folder becoming full.
Fixed a rare issue where Snapshot Replica jobs with a large amount of source data would fail to finish due to timeout.
Fixed an issue where users could not configure a service to use a port number already reserved for another service even though the two services used different communication protocols (e.g., TCP and UDP).
Fixed an issue where users could not access folders via Samba if their username contained certain special characters.
Resolved an issue in HBS 3 where some users could not enable Time Machine service.
Fixed an issue in File Station where if the NAS time is ahead of the client time, uploading a file would cause Background Tasks to incorrectly display a "Failed" message until the upload is complete.
Improved MariaDB support for all time zones.
Improved the display ratio of the desktop wallpaper.
Improved the login process.
Fixed an issue in File Station where folders would be incorrectly sorted if one or more of the folder names included certain special characters.
Fixed an issue in File Station where if the NAS time was ahead of the client time, uploading a file would cause Background Tasks to incorrectly display a "Failed" message until the upload was complete.
Fixed an issue in File Station where some action options were missing when right-clicking XLSM files.
Fixed an issue where under certain circumstances, File Station would be stuck at "Searching..." after trying to search files by keyword.
Fixed an issue where Notification Center could not send notification emails when notification rules were triggered.
Resolved an issue where trying to add a QNAP ID that already existed in myQNAPcloud > Access Control > Custom Settings would incorrectly trigger an "Unknown error" message.
Resolved an issue in Network & Virtual Switch where users would encounter an unexpected error when trying to add a static route using a VPN interface.
Resolved an issue where iSCSI & Fibre Channel would stop responding for some users after trying to open the application.
Fixed an issue in Notification Center where the system would continue to send email notifications to a recipient who had been removed from a notification rule.
Resolved an issue where the system would incorrectly display an "Unable to send firmware update notifications" message after creating a notification rule for firmware updates.
Fixed an issue in Qsirch where users could not search NAS files in Finder in macOS Ventura.
Fixed an issue where users could not fully delete a shared folder if the shared folder contained a very large number of files.
Resolved an issue where properly shutting down the NAS caused the S.M.A.R.T. attribute "Power-Off Retract Count" in HDDs to unexpectedly increase in value.

 

[tiermutter]

Bei mir soweit alles unauffällig, aber ich hatte auch nie eins der genannten Probleme...
Außer vielleicht dass Snapshot Replica seit langem schon ultra langsam sind, daran hat sich bis heute nichts geändert, auch wenn daran schon seit mehreren Releases geschraubt wird....

 

[rednag]

Snapshots kann ich nicht nutzen. Auf das lokale Gerät macht es wenig Sinn und ne andere QNAP hab ich nicht. Außerdem hab ich ein statisches Volumen. Ja, man könnte die Snapshots lokal speichern und dann per Hybid Backup wegsichern. Aber wer will das schon.

 

[tiermutter]

Auf das lokale Gerät macht es wenig Sinn

Je nachdem was man erreichen will kann das schon Sinn machen. Insbesondere wenn Daten häufig geändert werden kann das sinnvoll sein

Ja, man könnte die Snapshots lokal speichern und dann per Hybid Backup wegsichern.

Nein, HBS kann mit Snapshots nichts anfangen... Snapshots können nur
a) lokal sein
b) als Replika auf ein anderes QNAP ausgelagert werden
c) als Replika auf einen ext. Datenträger zum Verbringen in ein anderes QNAP ausgelagert werden

 

[rednag]

Ist doch egal ob Hybrid Backup was damit anfangen kann. Snapshots z. B. Lokal unter Backup anlegen lassen. Dieses Verzeichnis wird dann mit rsync auf ein anderes NAS geschoben. Im Worst Case diesen Ordner dann auf ein neues NAS kopieren und dort wiederherstellen.
So zumindest nach menem Verständnis.

 

[tiermutter]

Snapshots sind aber kein Ordner... Es sind nichtmal Dateien in dem Sinne, da weil es ja blockbasiert ist. Zumeist befinden sich "in einem snapshot" auch nur Bruchstücke der eigentlichen Daten, die zu Teilen aus anderen Snapshots und vorhandenen Daten auf dem eigentlichen Volume zusammengesetzt werden.
Man könnte sicherlich einen Snapshot erstellen, diesen einbinden und diese Daten dateibasiert über HBS oder sonstwie wegsichern, aber dann kann man das besser direkt machen, da das einbinden das Snapshots die volle Volume Kapa benötigt und die dateibasierte Sicherung auch nochmal samt zusätzlicher Kapa für die Versionierung. Damit wären alle Vorteile von Snapshots zunichte gemacht und schlimmer sogar noch: es wird unnötig kompliziert und aufwändig

 

[rednag]

Das klingt beim lesen schon schrecklich...
Also brauche ich ne zweite QNAP welches dann Thin/Thick hat. Der Performanceverlust zu statischen Volumes wird sich in meiner Umgebung vermutlich nicht bemerkbar machen.
Hast du nicht die Garage voll QNAPs?

 

[tiermutter]

Ist eigentlich eine nette Sache
Performanceeinbußen spüre ich auch nicht.

Hast du nicht die Garage voll QNAPs?

Privat sind es 5 produktive und 4 Spielsysteme wovon 2 Defekte aufweisen. Alle anderen habe ich schon verkauft...

 

[Barungar]

Ich behaupte einfach mal, dass die Performaceeinbußen auch eher theoretischer Natur sind bzw. maximalen in High I/O Lasten zu finden sind.

Denn was passiert bei einem Snapshot?

Vereinfacht gesagt werden zum Zeitpunkt des Snapshots alle beschriebenen Blöcke der Volumes virtuell in "read-only" gesetz.
Alle nach diesem Zeitpunkt erfolgten Schreibzugriffe werden auf einen neuen Block "umgeleitet", spricht der ursprüngliche Block wird kopiert und die Änderungen des Schreibzugriffs werden dann auf der Kopie angewandt.

Ab diesem Zeitpunkt gibt es diesen Datenblock genau zweimal: den ursprünglichen (time stamp = snapshot) und den geänderten Block (time stamp NACH snapshot). Alle zukünftigen Lese- und Schreibvorgänge werden durch die "Logik" des Volumes auf den neuen Block umgeleitet.

Die denkbaren Performaceeinbußen wären also nach meinem Verständnis:

• beim ersten Ändern des Blocks nach dem Snapshot wird einmal der Block kopiert und es wird eine "Umleitung" in der Block-Allokation-Table gesetzt
• alle nachfolgenden Lese-/Schreiboperationen werden auf diesen neuen, umgeleiteten Block umgelenkt

Ja, theoretisch gibt es also zusätzliche Lese-/Schreiboperationen, aber da muss schon "sehr viel Musik" auf einem Volume sein, dass man das bemerkt.

Ich arbeite nicht nur privat mit Snapshots, sondern auch dienstlich und das sind andere Welten... da werden große Volumes von IBM DB/2-Datenbanken oder auch Oracle Enterprise Edition im laufenden Betrieb gesnapshottet und auch das geht ohne das die Performance einbricht.

 

[tiermutter]

Ich denke es liegt einfach daran, dass Dateien wegen Snapshots ja aus den Blöcken des Volumes (Situation vor Snapshoterstellung) und den Blöcken aus dem/ mehreren Snapshots (Situation nach Snapshoterstellung und Änderung) zusammengesetzt werden muss.
Es ist also quasi eine gewollte Fragmentierung der Daten, sofern diese oft in unterschiedlichen Teilen geändert werden. Dann muss der Lesekopf an zig unterschiedliche Stellen springen um eine Datei zu lesen und das dauert nunmal länger. Spürbar? Keine Ahnung, ich merke nichts, ändere aber auch nicht so viel, dass die Daten stark "fragmentiert" werden.

 

[Mavalok2]

Ich denke mir, dass es bei sehr vielen vorgehaltenen Snapshots und schwacher Hardware spürbar wird, also vermutlich sehr schleichend.

Ach übrigens zum Topic:
TS-473A und TS-328 bis jetzt keine Probleme. Sind aber auch meine Spielwiese. Will also nichts heißen. Alle produktiven NAS sind noch auf der letzten 5.0.1.