I'm sorry, but I think your arguments fall under their own weight.
Well they are not "arguments", this is fact from being in the same part of the building with the very people who work on SMART code for new product. It's your right not to believe anything I say of course.
I was satisfied, but I did insist on getting what they should have just done from the start.
Disclosure: I work for Seagate but not in customer support but I do know some stuff about SMART. I am not an expert so I won't answer any questions but I do feel I have a different perspective to share.
Incorrect or invalid SMART interpretations are one of the biggest issues with "no problem found" failure returns. Often it comes down to third party software that isn't following the protocol and starts throwing red flags with the presence of raw counts. That is why Seagate support is asking people to run the Seatools software because it's written in a way to separate garden variety errors from catastrophic issues.
SMART does a great job, maybe too good of a job, in recording ANY and ALL aspects of drive operation. For example, raw and seek errors are a natural occurrence with disc drives and not a sign the drive is failing. The drive ECC is designed to correct normal bit errors and the user can sleep fine. Unfortunately people dump their SMART history and panic because they see numbers all over the place. Bad third party software will interpret these numbers and flag them as a problem when they really are not a problem.
If there is an inordinate amount of raw errors in a particular sector, the drive will map the sector out and reallocate accordingly. I have drives that reallocated early in their life and never was a problem thereafter. I had other drives that kept reallocating sectors until SMART finally flagged the drive as failing. Why would correctable errors start showing up after factory pass? It could simply be the conditions they are operating under at the end user. Just running in an elevated temperature environment can expose a weak area of the media that ordinarily is fine at lower temps.
I get the fact that Seatools is Windows only and not everyone wants to bother finding a Windows box and a USB/SATA adapter. Unfortunately that is the best software to determine if the drive has an onset of a lethal condition.
I'm not passing judgement about the situations I have read here, just informing people that you should be careful in the interpretation of SMART dumps and why Seatools is considered the proper way to diagnose the drive by Seagate Support.
Can you also report GPU temp? (Or maybe that is the 2nd core referenced by the OP.)
On some occasions, I connect a four bay QNAP TR-400 DAS to my RPI via USB and OMV handles it just like any other pluggable USB storage. I cannot vouch for any other interface though (SAS or Thunderbolt.)
Just to follow up, I managed to upgrade to OMV6 successfully without any issues (thankfully!) but I still can't see the network card.
I wonder where my message got lost. I stated that I fought this issue on OMV6 for months and the ultimate fix was move to OMV7.
That switch is only rated to 100 Mb/s so all you'll ever yield is 12.5 MB/s and realistically that 11 MB/s is reasonable. Can you get your hands on a cheap 1000 Mb/s switch? You'll see 115 MB/s with that.
To add to gderf, if you already littered OMV5 with a bunch of drivers for the Realtek, I'm not sure what happens with those drivers with in-place upgrades. I didn't want to deal with any fallout from my mess so I did a full do-over and installed OMV from scratch (so I can only vouch for that.)
I feel your only solution is to move to OMV7. I fought the Realtek 8125/26/52/56 2.5 Ghz driver issue for months on OMV6 and finally got fed up enough to move to OMV7. Works perfectly under OMV 7, full bandwidth is realized (280 MB/s) although I still have an annoying initialization problem that started after an update (as documented here: RE: RPI updates - Ethernet dongle - Remote Mount)
Targets NAS users with only two storage ports and no PCiE slot?
My assumption is the ethernet ports would be the connections for the raid but that requires a back end drive bay that has similar.
Another Topton stuffed with 8 - 2.5 G ports.
I don't mind the post email status. It lets me know the update installed correctly.
Hello, still looking for help/suggestions. The two referenced systems are running fine. The only exception is this annoying need to unplug/plug the ethernet dongle to be recognized during startup. Both systems have the same exact issue and it started with the update notification listing in the first message.
Unfortunately, I have to say, it uses an Rtl8125 network chip, which stops my system from going deeper than C3, which in term causes more power drain than necessary
Realtek offers a very fresh Driver here that might fix it.
What does "stops my system from going deeper than C3" mean?
I unpacked the driver you linked and found the datestamp is 10/23. If this truly accurate then OMV7 should already have it. Sometimes a Git entry is updated for other reasons than a new driver file.
An update and a request for help.
I have now got both systems in a stable state and the outstanding issues have become more focused. Both systems have the same issue behavior that began with the update..
1. Upon a reboot, the ethernet (2.5 Gb/s) USB dongle is not "seen" and the system cannot be accessed through SSH or UI. The IP is not active, ping returns nothing. Upon unplugging the USB dongle and replugging, OMV now sees the device and enabled it and everything works normal at 2.5 Gbits/s. It's as if something changed in the device sensing/driver loading sequence as a result of the updates listed in my first post. Curiously neither Syslog or Boot logs are listing anything about the dongles with this activity.
May or may not be relevant. If I setup the RJ45 1Gb/s, that is loading fine. It's seems isolated to the ethernet dongle driver and not ethernet in general.
2. Remote mounts no longer automatically mount/connect. They are present, I don't need to rebuild the mounts. All I have to do is remount with the triangle button. I now figured out it's due to the lack of network connection (item #1) Is it possible to have a network (re)connection automatically trigger the remount?
Looking for suggestions or things to try.
So the general conclusion that SMR are not working in a Raid is not correct.
I concur. I have two Seagate ST5000LM000 5T SMR drives in a RAID0. It's probably the worst scenario for a NAS configuration and yet I haven't experienced the data throughput issues that seem common with some SMR drives used in NAS. I get the max 280 MB/s xfer (2.5 Ghz ethernet) and haven't had any infamous stalling events (where the drive spends a inordinate amount of time writing a nearly full disc.) With that said, I know better than to use this as a mission critical system, it's just a hobby toy that I have been playing with to see when SMR starts being a problem. Maybe the slow RPM is helping smooth out the peaks and valleys, LOL.
As far as I know, this plugin is used to clone the system disk from the GUI. So I think you need to connect an empty disk/SD card/USB pendrive to be able to clone,.....
Oh, yes the destination has stuff on it and I assumed (doh!) that the cloning would simply overwrite everything with the same format and content.
Yesterday I received notification of several updates/upgrades to RPI via email. I went ahead and ran the Update Management search and installed 12 updates on both Pi NAS boxes and wowzaa, what a mess! Both systems are very similar (Geekworm hardware NAS with bridged SATA) and showed the same post-update behavior. The custom scripting for power switch goes into an endless loop running the CPU at 40% persistent so I uninstalled them. Mounts that refused to mount automatically but I can mount manual. Ethernet 2.5Ghz dongles that are not seen until booting with the RJ45 ethernet connection. Through a series of power cycling and unplugging, replugging USB, etc the systems are slowly working their way back to stable. These are not mission critical systems so it's nothing more than an annoyance. Wondering if anyone else noticed this behavior.
dphys-swapfile (20100506-7.1+rpt3) bookworm; urgency=medium
* Don't run if root overlay is enabled
-- Serge Schneider <serge@raspberrypi.com> Mon, 11 Mar 2024 16:47:00 +0000
linux (1:6.6.20-1+rpt1) bookworm; urgency=medium
* Raspberry Pi OS release * Remove unecessary patches * Add rpi featureset * Import Raspberry Pi defconfigs * Allow initramfs generation to be skipped in postinst * Move initramfs-tools to recommends * Install overlays README * Don't sign arm64 kernels * Compress arm64 kernel * Disable unecessary architectures * Use GCC 12 * Add +rpt to abiname * Add epoch support in version string * Linux commit: 6f16847710cc0502450788b9f12f0a14d3429668
-- Serge Schneider <serge@raspberrypi.com> Thu, 07 Mar 2024 14:51:31 +0000
raspi-config (20240228) bookworm; urgency=medium
[ Tim Gover ] * Allow EEPROM upgrades
[ Simon Long ] * Check wayvnc service to determine status
-- Simon Long <simon@raspberrypi.com> Wed, 28 Feb 2024 14:54:21 +0000
raspi-config (20240216) bookworm; urgency=medium
[ Simon Long ] * Call panel functions to update wifi country status when setting
-- Simon Long <simon@raspberrypi.com> Fri, 16 Feb 2024 13:18:03 +0000
raspi-config (20240214) bookworm; urgency=medium
[ Simon Long ] * Remove VNC resolution setting for Wayland
-- Simon Long <simon@raspberrypi.com> Wed, 14 Feb 2024 13:04:45 +0000
raspi-config (20240213) bookworm; urgency=medium
[ Simon Long ] * Add Wayland switching for x86 images
-- Simon Long <simon@raspberrypi.com> Tue, 13 Feb 2024 07:37:56 +0000
raspi-config (20240131) bookworm; urgency=medium
[ Simon Long ] * Remove logind power key settings in do_boot_behaviour
-- Simon Long <simon@raspberrypi.com> Wed, 31 Jan 2024 12:48:28 +0000
raspi-config (20240130) bookworm; urgency=medium
[ Simon Long ] * Add labwc screen blanking
-- Simon Long <simon@raspberrypi.com> Tue, 30 Jan 2024 07:43:59 +0000
raspi-config (20240111) bookworm; urgency=medium
[ Simon Long ] * Add labwc switching
-- Simon Long <simon@raspberrypi.com> Thu, 11 Jan 2024 14:39:54 +0000
raspi-firmware (1:1.20240306+ds-1+rpt1) bookworm; urgency=medium
* New upstream version 1.20240306+ds
-- Serge Schneider <serge@raspberrypi.com> Wed, 06 Mar 2024 16:42:23 +0000
openmediavault (7.0.2-2) stable; urgency=low
* Fix problem when deploying file system quota. * Issue #1725: Add search field to shared folder page.
-- Volker Theile <volker.theile@openmediavault.org> Sat, 09 Mar 2024 16:48:27 +0100I would appreciate that Soma, thank you!
I wanted to try using the Disk Clone plugin to backup my SD Card on my RPI4 and ran into an issue where the Destination does not show any File Systems or Shares under the Destination line.
The share is there, I can see it on any system through SMB. There are other drives present as well but none are showing up when clicking on the pulldown for the destination. They are all present when I click on the Source.
Is there something obvious I am overlooking?
Double the transfer speed? Did you check to see if the Intel NIC was half-duplex instead off full?