I currently have the ReadyNAS 102 with one drive (Seagate 2TB) in X-RAID on firmware 6.1.4 Do I need to do a factory reset if I want to upgrade to 6.1.6 (RC10) and want to benefit of file transfer improvements? Or is a factory reset only needed if you have multiple drives in a different RAID setup?
The reset makes adjustments to the btrfs settings, which of course are above the RAID level. So overall, they should act to improve performance in all configurations.
However, if you aren't seeing any performance problems, you might chose to avoid the inconvenience of the reset, at least for now.
I am in the same situation btw - my RN102 has 2 drives in jbod mode, and is also running 6.1.4. I am not seeing many issues with performance. File transfers are completing, and I am not seeing obvious speed drops. I have noticed that disk scrub on one volume hangs (requiring a front panel shutdown to clear), but scrubbing the other volume does not.
I'm not sure yet if I will do a full reset, or if I will try destroying/recreating the volume on the second disk. Either way, I will wait a while longer before upgrading to 6.1.6, as I am not seeing major issues that I need to address right away.
I have 6.1.5 running on an RN516 with an EDA500 attached. When I performed a large rsync to a volume created on the EDA500, I noticed a number of "drive command timeout" errors. i pulled one of the drives that reported errors, and it tests fine in seatools. So, I am wondering whether the drive command timeout errors are device related more so than drive related.
I have the EDA500 volume set up as a Raid6 volume. The thing that was interesting in the command timeout errors, is that they would show up sequentially by drive: so, an error would occur on drive 2, then on drive 3, then on drive 4, and on drive 5. I assume this was due to the striping lay out, but still seems odd that this would be a drive error as indicated by the error message info that says "This condition often indicates an impending failure. Please be prepared to replace this disk to maintain data redundancy."
I have filed a support case on this (22596971), and have not yet tried 6.1.6, but will do so after hearing back from support. One thing that I did see in the 6.1.6 release notes is improvements to I/O latency, so maybe this will also address device timeout situations...
Anyone else encounter drive "command timeout" errors when doing transfers to an OS6 device? wondering if this is a 6.1.5 issue...
These errors are happening on all your drives? What model are they? Did you use seagate's download finder to check for new drive firmware?
In general, timeouts could be caused be (a) the drive itself, (b) an issue with the SATA hardware on the EDA500 (or its connection to the RN516), or (c) possibly a bug in the RN516 firmware related to that particular drive.
A tangential question: does anyone know what hardware is in the EDA500? Namely, which port multiplier, or if there is built-in pseudo-RAID hardware (SiL SteelVine-ish for example).
Can a single drive from the EDA be included in an array otherwise present on the main NAS?
These errors are happening on all your drives? What model are they? Did you use seagate's download finder to check for new drive firmware?
In general, timeouts could be caused be (a) the drive itself, (b) an issue with the SATA hardware on the EDA500 (or its connection to the RN516), or (c) possibly a bug in the RN516 firmware related to that particular drive.
...
The drives I have are Seagate 4TB ST4000VN000 (on the compatibility list). I have the same drives in the RN516, and have not seen any errors there. When I pulled one of the drives that the ReadyNAS reported as having errors, I ran the full complement of Seagate tests and did check the firmware version - everything checked out fine.
Interestingly, I did not see any errors on disc 1, but would see errors like this...
[14/01/14 08:57:38 PST] notice:disk:LOGMSG_SMART_CMD_TIMEOUT_WARN Detected increasing command timeouts: [32] on disk 2 (eSATA Port 1) [ST4000VN000-1H4168, Z300RNZX]. This condition often indicates an impending failure. Please be prepared to replace this disk to maintain data redundancy. [14/01/14 09:13:18 PST] notice:disk:LOGMSG_SMART_CMD_TIMEOUT_WARN Detected increasing command timeouts: [30] on disk 3 (eSATA Port 1) [ST4000VN000-1H4168, Z300R4F5]. This condition often indicates an impending failure. Please be prepared to replace this disk to maintain data redundancy. [14/01/14 09:13:21 PST] notice:disk:LOGMSG_SMART_CMD_TIMEOUT_WARN Detected increasing command timeouts: [33] on disk 4 (eSATA Port 1) [ST4000VN000-1H4168, Z300RP0E]. This condition often indicates an impending failure. Please be prepared to replace this disk to maintain data redundancy. [14/01/14 09:13:25 PST] notice:disk:LOGMSG_SMART_CMD_TIMEOUT_WARN Detected increasing command timeouts: [27] on disk 5 (eSATA Port 1) [ST4000VN000-1H4168, Z300RNZD]. This condition often indicates an impending failure. Please be prepared to replace this disk to maintain data redundancy.
While the errors were not always shown on consecutive drives like above, that was the case more often than not...
In all my time with ReadyNAS devices, I have never seen command timeout errors, so don't know whether this is really a cause for concern or just a blip in the transfer. I assume that if there was a timeout, the data would still be written ok, but don't know that...
A tangential question: does anyone know what hardware is in the EDA500? Namely, which port multiplier, or if there is built-in pseudo-RAID hardware (SiL SteelVine-ish for example).
Can a single drive from the EDA be included in an array otherwise present on the main NAS?
I can't answer the question on the hardware, but when I went to set up the EDA500, I did have the option to add the drives in the EDA500 to my existing Raid6 config from the RN516. From previous posts I read around here, I thought that i could only set up the EDA500 as a separate volume, so was surprised to see this. I could not find much info or documentation that described how to set up the EDA500 other than to plug it in and connect it...
I did not test adding the EDA500 drives to the Raid6 configuration as I was concerned about having the EDA500 affect my current Raid volume or having both boxes down if one stopped working. I more conservatively ended up setting up the EDA500 as a separate volume...
Generally speaking, I think the conservative approach is better. Splitting your volume across two chassis seems to be asking for trouble. Even if it was one chassis, it is a lot of drives to put in one array.
Generally speaking, I think the conservative approach is better. Splitting your volume across two chassis seems to be asking for trouble. Even if it was one chassis, it is a lot of drives to put in one array.
Thanks. Yeah, good point. Also, if the RN516 failed, it would be easy to move the EDA500 to another box if needed (assuming I had one)...
I have a RN102 running on OS 6.1.4 (with only one drive 2TB, X-raid). Currently I did not experience any performance drops in terms of copying large files from and to the RN102. So seems to me the btrfs performance issues reported are primarily related to the RN104. Anyway, I was wondering will it be a wise choice to upgrade to 6.1.5 or should I stay on 6.1.4? I do not know if 6.1.5 and 6.1.6 bring significant improvements to the RN102?
Please advice, also I would like to know if I first need to upgrade to version 6.1.5 before I can test version 6.1.6?
If I had an issue that couldn't wait I'd start with 6.1.6 beta, and pass on 6.1.5 altogether.
You can go directly to 6.1.6, there is no reason you need to install 6.1.5 first. 6.1.6 does include performance enhancements for the ARM units (in addition to the btrfs file system tweaks in 6.1.5).
If I had an issue that couldn't wait I'd start with 6.1.6 beta, and pass on 6.1.5 altogether.
You can go directly to 6.1.6, there is no reason you need to install 6.1.5 first. 6.1.6 does include performance enhancements for the ARM units (in addition to the btrfs file system tweaks in 6.1.5).
Thanks Stephen, That is a good advice, I will do the same! I am fine now with 6.1.4 but will certainly upgrade once 6.1.6 is available. However I do think I will not do a factory reset, it will be to much of a hassle to restore all my data to one disk.
On 6.1.6 you should be fine even without doing a factory reset. But if you did happen to encounter a serious performance issue you would still have a factory reset as an option.
