Surely Netgear are not telling me I have to go out and BUY enough storage of a different medium - hundreds of dollars - to move my data temporarily purely for an upgrade
Surely you already have a backup of your valuable data. Right?
I mean... Of course it sucks to have to reformat your NAS in order to fix the blocksize problem, and restoring the data will be a drag even if your backup is another 6x3TB ReadyNAS with NFS or rsync already sorted. But honestly, you really should have a backup, and if finding yourself in this unfortunate situation forces you to make one, you'll be far better off in the long run.
Different people have different levels of backup needs. Not everyone needs to have a complete duplicate backup of all their data. It's silly to suggest everyone fits within that data backup scheme.
Imagine if you were forced to format all your hard drives (say you had 6 in your computer) every time you wanted or needed to reinstall the Windows operating system. And your average user was then forced to move all their data somewhere else in the mean time?? Imagine any leading OS vendor trying to get their customer base to perform this task!
This new range of ReadyNAS is aimed at all levels of users and marketed as the easiest to use yet with the brand new operating system 6.
To suggest the the lower level user base that makes this 'quality investment' has to then make another investment of equal cost of well over $1000 just to perform a software upgrade is ludicrous in anyone's language unless you are made of money!
While discussion regarding Netgear q&A, CTO and how people manage their backups are interesting I personally would prefer if this thread focused on the actual 6.1.5 release. I dont know if others agree.
Currently on 6.1.2 on my Pro 6 and waiting for feedback and quality of the release before taking the plunge. Will there for instance be a "proper" 6.1.5 (without RC9-label and maybe working USB3) that gets distributed through the other channels (netgear.com and the OTA upgrade).
While discussion regarding Netgear q&A, CTO and how people manage their backups are interesting I personally would prefer if this thread focused on the actual 6.1.5 release. I dont know if others agree.
Currently on 6.1.2 on my Pro 6 and waiting for feedback and quality of the release before taking the plunge. Will there for instance be a "proper" 6.1.5 (without RC9-label and maybe working USB3) that gets distributed through the other channels (netgear.com and the OTA upgrade).
Thanks fream. I do however believe my points are valid if the 6.1.5 upgrade still requires a full reinstall requiring me to place 13TB of data somewhere else requiring many hours and $$ for an upgrade that takes minimal time. In the context it's a valid question.
Yes, the need for a factory reset is regrettable. I believe if Netgear saw a way to avoid it, they would have.
My view is that you need to have the backup anyway. So I don't see the $$ component as valid (unless you are including labor to rebuild/restore the NAS). The time is another matter.
Breaking USB 3.0 is of course a huge issue for lots of people.
Well my system is working perfectly as it is. Is skipping this and other updates viable until an update addresses issues that affect me? Is there a chance a future upgrade won't require a full temporary data migration elsewhere?
Well my system is working perfectly as it is. Is skipping this and other updates viable until an update addresses issues that affect me? Is there a chance a future upgrade won't require a full temporary data migration elsewhere?
You can update to 6.1.5RC without doing a factory reset. Factory reset is needed for the block size change.
All the Backup jobs have been completed in good order, with the external seagate usb3.0 drive connected to the front usb2.0 port.
There is allso another issue i noticed. After one or more backup jobs are completed, the temperature of the NAS goes skyhigh (processor 75deg C) when doing nothing. Logged in with SSH and found with top that fvbackup-q is still running and taking all available processor resources. i tried it (even with new backupjobs to avoid errors)several times and fvbackup-1 always stays and eating all the processor load. When i stop the process using a ordinary kill or through systemctl the temp goes back rto 55 deg C I can not remember that i have seen this before.
Mace Windo posted in another thread (viewtopic.php?p=414161#p414161) that 6.1.5 is officially released. Sadly its the RC9 build still... (sigh)
Mace Windoo wrote:
Hello everyone,
ReadyNAS 6.1.5 is officially released on the support site, below is a link to the new firmware which includes BTRFS changes that have been implemented to resolve some of this issues mentioned this thread. Specifically, devices that experience performance issues or non-responsive behavior when consuming the majority of capacity (> ~70% ).
To take advantage of this update, you must format your existing volume after the update is applied, this will allow ReadyNASOS to create a new filesystem using a more optimum configuration (Warning: Factory Default will wipe existing data and settings from your ReadyNAS). After that the new filesystem configuration will now have a larger node size that can accommodate higher file system usage on systems with 512Mb RAM such as the ReadyNAS 104
I understand that this is an inconvenience however, it is the only way to make this type of change.
To upgrade your NAS to 6.1.5:
1. download the from the links below. Extract all the files from the downloaded zip file. 2. From the ReadyNAS UI go to System > Settings and click “Install Firmware”. 3. Browse to the .img file and open it. 4. Select upload 5. Once the upload is complete, you will need to reboot the system 6. For user experiencing the above issues we are recommending a factory default to get the new file system. As I stated earlier, please make sure you backup first as your system will be wiped clean
Mace hasn't posted in this thread, so he probably won't see your message. I quoted him from viewtopic.php?p=414161#p414161
Please feel free to message myself for more information or continue to give your feedback through this forum.
For that kind of foot note, I'd expect more than 18 posts over 3.5 years on here. And daily participation on the forums like mdgm,StephenB,myself. It's obvious they don't read the forums often, to get real feedback, as the USB issue has been commented on all week here, and they still released the firmware. Reminds me of the ReadyDATA forum (where they banned me for calling them on their B.S.), where they pretend to participate as well, but do drive by postings and never come back (eg. http://forum1.netgear.com/showthread.ph ... post437900). Former employees should not have to stand up for the customers, NETGEAR themselves should be doing that themselves. </rant>
For those asking what is node size / leaf size. To put it in a simple way, BTRFS stores metadata (data about data) to find the files. The basic settings were too limited for large volumes causing crash. The new version updates the BTRFS driver, meaning the thing that allows the system (readyNAS OS 6) to use BTRFS file system and now authorize to change the setting, Netgear did put another setting by default to avoid the problem. But changing the setting requires to start fresh, you can update this setting, you just can set it at launch, BTRFS problem, not netgear's. If you don't have the problem then you can avoid the update and keep your system as is, you can update and not perform the reset, do as you please. If you experience the problem, then the only way to solve is to recreate the BTRFS volume. The safest and fastest way is to do as netgear told.
The only other way I can think of is to recreate another volume with the good parameters via SSH and migrate data from one volume to the other. quick steps should be these : => shrink the data volume => create the new volume with good parameters => transfer data (shrink the old and expand the new volume as many times as needed) => update the FSTAB => reboot Risky in many ways in untested (Netgear could deny support until you reset, you can lose your data, you can be forced to do the reset anyway...) and with no warranty of success. Just an alternative way that should work but is really NOT ADVISED.
Well I'm doing the SLOW data move back to my original PC, where I had all the data before I moved it to the NAS just this week. Luckily I had not yet taken the hard drives out.
I've got the RN 316, which whilst I'm only a newbie and not aware of problems. I have found already in the week I've had it that it can be unresponsive and need to be rebooted to get it back up again. Hopefully 6.1.5 with factory reset will help me too. I've got the WD Red Drives 3TB that are on the HCL.
Let's hope that Netgear don't keep pushing out updates that need a factory reset/ALL data moved off the machine.... or am I kidding myself, is this something they do regularly?
Well now this IS annoying... trying to move all my data back from the RN 316 to my PC, and every time I try, it locks up the ReadyNAS and I have to reboot and try again, only for it to lock up.
The thing is, as BTRFS is in heavy development, there is absolutely no guarantee that this won't happen again, and it could happen very soon too. Having BTRFS as the only choice for a file system was -- and continues to be -- a very stupid idea, and as long as that is still the case, I don't see the ReadyNAS line as serious products. In fact, I can't see a single scenario or user case where the ReadyNAS line is a viable choice. I have completely stopped buying them and recommend Synology devices instead.
And this is not the only thing wrong with OS6. The lack of disk spin-down and the breaking of USB3 in some models hints at a broken organizational culture, where focus is on releasing anything (to give the impression of "being there") before making sure core functionality actually works. This is of course unacceptable, and such an organization will never produce quality software. To clarify, this is not the fault of single developers, but a management fault; either there are no working procedures for release quality control or they are not being followed.
If I were in your shoes (and I kind of am, I have an Ultra4, which I bought at a clearance sale fully aware of all this) I would investigate running a full Debian on your device. Dunno if anyone has done it on a RN316 though 😞
TL;DR: OS6 is still, after almost a year, not close to release quality.
The custom nodesize and leafsize have been able to be set since kernel 3.4 (which was released May 2012), I think.
Also, no filesystem is perfect. Users with older ARM devices running EXT4 have had similar issues to 104 users using BTRFS. At least with BTRFS there hopefully is a way to resolve the issue.
Disk spin-down would be a nice feature to have and with the level of interest shown in this feature one would think it is almost certain to be added in a future release.
The breaking of USB3 ports is disappointing.
As for running a 3rd party OS that is unsupported but the HDMI port might make it a bit easier to install (could hook up to display and connect USB keyboard and mouse and chainload to boot using the device of your choice). With the Ultra 4 you would need to use the serial console.
Installed 6.1.5 and as everyone has found out USB3 ports on the back of 104's now do not work. Attached my USB3 device to front port I can read but not write It seems to be mounted as read only. Is there a way to mount as read/write. I understand this will involve editing a file via SSH which dictates how the usb disc is mounted.
Where and what file/s? If someone can provide a simple step by step guide so that I can make a temporary fix until NETGEAR get the act together!! (serious doubts here)
mount is only a linux command, so yes if the filesystem is supported you should be able to mount in read/write via SSH at least. checkout -o (check at rw) et -t (tells mount the filesystem you use) options of the mount command. since the device is already mounted, mount -o remount,rw /folder/to/access/RW should be enough. This fix is temporary however, on a standard linux one would edit /etc/fstab but I don't know how it's handled with the readynas.
If you don't want to go SSH, then check your rights in the web interface and try to eject and plug again the disk, scan it for errors if it doesn't work.
for the USB3, can't help right now, I have nothing to test with, only old USB2 disks and moreover I'm not near any NAS right now.
Well now this IS annoying... trying to move all my data back from the RN 316 to my PC, and every time I try, it locks up the ReadyNAS and I have to reboot and try again, only for it to lock up.
What to do now?
Are you using Rsync to back up to your PC? If not, give it a shot since rsync also runs with a nice mode of 10 I believe.
As another suggestion, since you do not want to overtax CPU, don't use compression if you are having problems.
mount is only a linux command, so yes if the filesystem is supported you should be able to mount in read/write via SSH at least. checkout -o (check at rw) et -t (tells mount the filesystem you use) options of the mount command. since the device is already mounted, mount -o remount,rw /folder/to/access/RW should be enough. This fix is temporary however, on a standard linux one would edit /etc/fstab but I don't know how it's handled with the readynas.
If you don't want to go SSH, then check your rights in the web interface and try to eject and plug again the disk, scan it for errors if it doesn't work.
for the USB3, can't help right now, I have nothing to test with, only old USB2 disks and moreover I'm not near any NAS right now.
I have looked into etc\fstab but there are no commands in there so NTGR have hiddden it somewhere else
I'l try the mount method. I assume temporary means until the next reboot or until I eject the disk Edit
Tried remounting via ssh
No dice
comes up with not mounted when it is.
The web interface is of no use as the file access page is blank for the usb_hdd_1 mount
I would have hoped (taking from Doctor Who), "silence will fall when the question is asked". But everyone is asking that question, and no one from NETGEAR will speak up. Even a simple post of 'we acknowledge your comments, and are looking into how we f$%ked up, to try and fix it' would be nice. Playing dead just sends people in the Synology/etc direction, as seen in various posts here. It just seems like they've avoided the forums for so long now, it would be harder to come back, than just ignore it and watch it fade away. Why do you want to kill your own products?!?
@davexyz I didn't understand you message. What is exactly the error you get ? device is not mounted ? If so are you sure you gave the right folder/device ? You can try mount -o rw -t btrfs /dev/device/to/mount /folder/where/to/mount if the device is already mounted you should have something like "device is busy".
Yep temporary meant until reboot or until unmount/eject. Don't you have /data mounted in /etc/fstab ? if so maybe you can set you HDD in this (but since I don't know how Netgear handled the automount, I don't know what it'll do, so may be good or bad or useless...), but I'm not sure. Another way around is to set a script at boot time with cron when you found the right command, use a delay with sleep (if the script mess up, just reboot and shut cron via SSH before the script is loaded) and test you script before reboot (never too careful, are we ?).
@chirpa, good reference 😉 I'd hope it too, I believe I'll mention it in a ongoing support ticket. I have a classical question for you, is there noise when there is nobody to hear it ? I wonder if Netgear ever read this forum, if they don't, then you are speaking to no one. But I agree, they should speak to preserve the brand reputation, to satisfy customers (or they shouldn't have an official forum if they can't handle it) and to prevent customers from moving away.
typing "mount" I get these two lines which refer to the USB disk
/dev/sdf2 on /media/USB/dev/sdf2 on /media/USB_HDD_1 type ufsd (ro,noatime,nodiratime,nls=utf8,fmask=0,dmask=0) /dev/sdf2 on /run/nfs4/media/USB_HDD_1 type ufsd (ro,noatime,nodiratime,nls=utf8,fmask=0,dmask=0)
Did some more digging in the backup issue. (after a backup job is done, fvbackup-q keeps running at maximum processor load and this makes the nas really slow) Killing the process and restart it with fvbackup-q -d and then activate a backupjob 2 times from the webif:
root@Readynas:/etc/init.d# /frontview/bin/fvbackup-q -d fvbackup-q.c:287 Start fvbackup-q fvbackup-q.c:127 Command: enqueue:8 fvbackup_utils.c:654 write(/var/log/frontview/backup/status_backup_008,BACKUP_STATUS__IN_QUEUE!!1388345421!!OK) fvbackup-q.c:135 Push: job_id=8 q_wp=0 q_rp=0 fvbackup_utils.c:249 cmd=/frontview/bin/fvbackup -e 8 Create a readonly snapshot of '/data/Pictures' in '/data/._share/Pictures/.snapshot/b_1388345422_18526' Delete subvolume '/data/._share/Pictures/.snapshot/b_1388345422_18526' fvbackup-q.c:127 Command: enqueue:8 fvbackup_utils.c:654 write(/var/log/frontview/backup/status_backup_008,BACKUP_STATUS__IN_QUEUE!!1388345643!!OK) fvbackup-q.c:135 Push: job_id=8 q_wp=1 q_rp=1 fvbackup_utils.c:249 cmd=/frontview/bin/fvbackup -e 8 Create a readonly snapshot of '/data/Pictures' in '/data/._share/Pictures/.snapshot/b_1388345648_19122' Delete subvolume '/data/._share/Pictures/.snapshot/b_1388345648_19122'
taking a peek in the snapshot folder shows no shocking things:
root@Readynas:/data/._share/Pictures/.snapshot# ls -lsa total 0 0 drwxr-xr-x 1 root root 144 Dec 29 20:34 . 0 drwxr-xr-x 1 root root 192 Dec 25 23:23 .. 0 drwxrwxrwx+ 1 guest guest 0 Dec 23 12:31 c_1387839662 0 drwxrwxrwx+ 1 guest guest 590 Dec 24 21:49 c_1387926016 0 drwxrwxrwx+ 1 guest guest 498 Dec 25 14:35 c_1388012470 0 drwxrwxrwx+ 1 guest guest 498 Dec 25 14:35 c_1388098887 0 drwxrwxrwx+ 1 guest guest 498 Dec 25 14:35 c_1388185231 0 drwxrwxrwx+ 1 guest guest 498 Dec 25 14:35 c_1388271630 root@Readynas:/data/._share/Pictures/.snapshot#
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 18429 root 20 0 20844 1056 800 S 99.3 0.2 15:08.91 fvbackup-q 20419 root 20 0 5228 1460 1060 R 0.7 0.3 0:01.04 top 1 root 20 0 5516 2716 1532 S 0.0 0.5 0:02.71 systemd 2 root 20 0 0 0 0 S 0.0 0.0 0:00.03 kthreadd 3 root 20 0 0 0 0 S 0.0 0.0 0:08.29 ksoftirqd/0 5 root 20 0 0 0 0 S 0.0 0.0 0:00.02 kworker/u:0
restart fvbackup-q and it is fine. start a backupjob from the webif and the problem is back. Doesn't matter if it is about share backupjobs or remote rsync backup jobs
The subject says it all....... I copied a couple of cdrom iso''s to the nas and then then frontview disconnected and network access was down. It lasted about 10 15 minutes before it was back online. This is sad..... Will whe have to factory reset again with the next firmware?
@dishmagic As far as I know, most of the other parameters can be modified without erasing the files (like setting other mount options, updating drivers/utils...). I don't think there will be another factory-reset-update. That said, like mentioned before, BTRFS is under heavy development so nobody can tell you exactly if it will happen or not. I believe it's unlikely but still possible.
@davexyz you sent those : /dev/sdf2 on /media/USB/dev/sdf2 on /media/USB_HDD_1 type ufsd (ro,noatime,nodiratime,nls=utf8,fmask=0,dmask=0) /dev/sdf2 on /run/nfs4/media/USB_HDD_1 type ufsd (ro,noatime,nodiratime,nls=utf8,fmask=0,dmask=0)
This is really strange. => Your device is mounted two times, that's very uncommon, at least I never did it and I've never seen any place where it's recommended (although I found in the mount(2) manpage that "Since Linux 2.4 a single file system can be visible at multiple mount points, and multiple mounts can be stacked on the same mount point.") => The second strange thing is to mount something in /run (or /var/run) with is normally reserved for temporary files for running apps. Usually the only thing you mount there is a disk image (a big file in which you can write). => The third strange thing is your first line is mounted two times, on /media/USB/dev/sdf2 and /media/USB_HDD1. I see that the disk is NTFS (UFSD being like NTFS-3G designed to read NTFS) and in readonly, so the problem is clearly the mount options.
The second line seems to be related to NFS sharing protocol, unless you are unix/linux (which I doubt given that you have an NTFS drive but who knows ?) you shouldn't need it, can you disable it and reboot to see if you have two mount lines ? Your setup seems pretty unusual to me so let's consider this is valid for the moment and try : mount -o remount,rw /media/USB_HDD_1 If it says "device busy" or "device already mounted" then try to unmount the other line (umount /run/nfs4/media/USB_HDD_1). Then retry the previous command. If it still doesn't work, you can try mount -t ufsd -o rw /dev/sdf2 /media/USB_HDD_1
Your setup is pretty unusual as I already said and i cannot find out why and that's bugging me, but since the defaut OS6 setup is messy by itself it can be normal.
look at my mount list :
tmpfs on /dev type tmpfs (rw,noatime,nodiratime,size=10240k,mode=755) devpts on /dev/pts type devpts (rw,noatime,nodiratime,mode=600) /dev/md0 on / type ext4 (rw,noatime,nodiratime,user_xattr,barrier=1,data=ordered) proc on /proc type proc (rw,nosuid,nodev,noexec,noatime,nodiratime) sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,noatime,nodiratime) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755) tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755) cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,noatime,nodiratime,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd) cgroup on /sys/fs/cgroup/cpu type cgroup (rw,nosuid,nodev,noexec,noatime,nodiratime,cpu) cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,noatime,nodiratime,blkio) tmpfs on /media type tmpfs (rw,nosuid,nodev,noexec,noatime,nodiratime,mode=755) fusectl on /sys/fs/fuse/connections type fusectl (rw,noatime,nodiratime) configfs on /sys/kernel/config type configfs (rw,noatime,nodiratime) /dev/md127 on /data type btrfs (rw,noatime,nodiratime,nodatasum,space_cache) /dev/md127 on /home type btrfs (rw,noatime,nodiratime,nodatasum,space_cache) /dev/md127 on /apps type btrfs (rw,noatime,nodiratime,nodatasum,space_cache)
I was told to mount one device to one mount point and use symlinks, apparently Netgear guys weren't. Look at what OS X have (ok only one partition for system and data, I know it's bad but since all is backed up properly...).
/dev/disk0s2 on / (hfs, local, journaled) devfs on /dev (devfs, local, nobrowse) map -hosts on /net (autofs, nosuid, automounted, nobrowse) map auto_home on /home (autofs, automounted, nobrowse)
