OS6 now works on x86 Legacy WARNING: NO NTGR SUPPORT!

tadgy wrote:
As far as I could tell, from the first boot of 6.x a new btrfs filesystem is created on your drives. Since btrfs is a totally different filesystem from ext* (which 4.x used), it would have had to re-format the disk table/inode structure to suit the new filesystem. That is a data destructive operation

This is partly correct, in that it is NOT a completely data-destructive operation, but its a metadata-destructive one. It is also complicated by the fact that there is a new, blank filesystem on top of the old one, but the simple XORing of a resync isn't a data-destructive operation in itself (it doesn't write zeros, it XORs the existing data, MD doesn't know or care about which file system is on the resulting datablob). Data is still there, but it might be hard getting it out.

tadgy wrote:
even if you are, it's going to need forensic data-recovery tools, a truck load of desire and a metric shit-tonne of time to do so.

This is 100% right. It would take several days, probably a week of work, if at all possible.

mangrove wrote:

This is partly correct, in that it is NOT a completely data-destructive operation, but its a metadata-destructive one. It is also complicated by the fact that there is a new, blank filesystem on top of the old one, but the simple XORing of a resync isn't a data-destructive operation in itself (it doesn't write zeros, it XORs the existing data, MD doesn't know or care about which file system is on the resulting datablob). Data is still there, but it might be hard getting it out.

We might be talking cross-purposes here.

You're talking about the MD driver and how it distributes across an array; which is - as you say - filesystem agnostic.

But, in the process of upgrading to 6.x he's gone from ext4 as the filesystem on that MD device to another filesystem that has an utterly different on-disk data structure.

Imagine the on disk data "blocks" like this:
For ext4: XXYYYY
For btrfs: XYXYXY
Where X is a bit of metadata, and Y is actual data.
(This is only an example, the structure is utterly more complex and not like this in any way - it serves only as example)

The process of initialising the btrfs filesystem *may* have created those metadata blocks all over the disk, where actual data may have been in the ext4 filesystem. This depends on the init process for btrfs, which I have no idea about.

So, even if you could trick the system into recognising the filesystem as ext4 (unlikely at best), the on-disk data is going to be completely in the wrong format for it to try and recover anything.

thanks for the replies. I appreciate the insight (not being facetious, honest).

I am no expert, but I'd say that the initialization was rather on the slow side of things (I have 4x2TB disks and took less than 5 minutes to change the whole thing), so I am prone to think it was a lazy start. I am in the process of securing USB enclosures, r-studio, a spare machine to create images and scour the surface of the disks.

At the end of the day I only want to recover around 15GB to 20GB of data, which, yes, I need to first locate.

Lesson learnt the hardest way possible.

Hi guys,

first of all great respect for the ability to put OS6 on my ReadyNAS Ultra 2. I started with 4.2.24 and upgraded to 25 after which I went uploading files to my NAS to test the speed. I was happy with the 60MB/s transfer it managed but couldn't resist to try the new features of OS6. After installing which went like a charm I tried uploading files again and got a staggering 80MB/s. I'd say that's worth the upgrade...
However I seem to have the same issues others experienced. I get sudden drop outs after which my NAS isn't reachable by SSH and the file tranfer hangs for a few minutes after which my iMac gives me an error. Sometimes it continues in time again to complete the transfer but more often I need to hard reset the NAS. I've had a better experience with a transfer via FTP (2 threads) to upload the data to my 2x2TB drives in JBOD but now it hangs more often even when trying to copy a 2GB video file.

My question is, is this also related to the BTRFS which will be fixed in the 6.1.5? Or am I better of with the 4.2.24 Radiator although it will be less fast. I don't mind the factory reset since my data is still on the NAS and external harddrives (which I intend to wipe after everything works as it should).

Hello everyone,

I've been a long time ReadyNAS user but this is my first time posting to the forum. Like many of you I was quite disappointed in Netgear's decision to not officially support OS6 on "last" generation hardware. I'm even more dissapointed in their decision to use BTRFS... but I digress.

In any case I installed 6.1.4 on my ReadyNAS Ultra 2 (Thanks guys!) and for the most part appears to work great. At first glance I can't be too sure if the fan/temp sensors are working as they should. My system runs at 70-80c (CPU) and 30-40c (SYSTEM) which should be within spec from what I understand.

Anyway...

The reason I'm posting this is because I recently upgraded my ReadyNAS to 6.1.5 (RC?)

Original post is here([url] is OFF for me apparently):

http://www.readynas.com/forum/viewtopic.php?f=154&t=74192&start=30#p413593

I simply downloaded the relevant image file and upgraded through the GUI, did a factory reset (apparently required as discussed, and through the GUI), and am now running 6.1.5 :D

I've only been playing with it for a couple of hours but all seems well!

Some nice shell output to show you the differences...

root@readynas:~# btrfs filesystem show
Label: '758ad486:data'  uuid: 642a625a-071b-4939-b699-61c31ab5e14e
        Total devices 1 FS bytes used 4.38GB
        devid    1 size 926.89GB used 7.04GB path /dev/md127

Label: '758ad486:root'  uuid: d69cc7ba-3242-4f03-97e9-5ba005fbf10a
        Total devices 1 FS bytes used 275.36MB
        devid    1 size 4.00GB used 854.31MB path /dev/md0

Btrfs v0.20-rc1
root@readynas:~# cat /proc/mdstat
Personalities : [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md127 : active raid1 sda3[0] sdb3[1]
      971910784 blocks super 1.2 [2/2] [UU]
      [===>.................]  resync = 17.5% (170255616/971910784) finish=118.5min speed=112731K/sec
      bitmap: 7/8 pages [28KB], 65536KB chunk

md1 : active raid1 sdb2[1] sda2[0]
      523712 blocks super 1.2 [2/2] [UU]
        resync=DELAYED

md0 : active raid1 sdb1[1] sda1[0]
      4190208 blocks super 1.2 [2/2] [UU]

unused devices: <none>
root@readynas:~# btrfs-show-super /dev/md127
superblock: bytenr=65536, device=/dev/md127
---------------------------------------------------------
csum                    0x546e2911 [match]
bytenr                  65536
flags                   0x1
magic                   _BHRfS_M [match]
fsid                    642a625a-071b-4939-b699-61c31ab5e14e
label                   758ad486:data
generation              44
root                    58949632
sys_array_size          226
chunk_root_generation   33
root_level              0
chunk_root              21004288
chunk_root_level        0
log_root                0
log_root_transid        0
log_root_level          0
total_bytes             995236642816
bytes_used              4700119040
sectorsize              4096
nodesize                32768
leafsize                32768
stripesize              4096
root_dir                6
num_devices             1
compat_flags            0x0
compat_ro_flags         0x0
incompat_flags          0x21
csum_type               0
csum_size               4
cache_generation        44
dev_item.uuid           e8c6792a-7957-4555-b988-14218d6b1a0b
dev_item.fsid           642a625a-071b-4939-b699-61c31ab5e14e [match]
dev_item.type           0
dev_item.total_bytes    995236642816
dev_item.bytes_used     7553941504
dev_item.io_align       4096
dev_item.io_width       4096
dev_item.sector_size    4096
dev_item.devid          1
dev_item.dev_group      0
dev_item.seek_speed     0
dev_item.bandwidth      0
dev_item.generation     0

root@readynas:~# uname -a
Linux readynas 3.0.101.RNx86_64.2.1 #1 SMP Thu Dec 5 12:31:10 PST 2013 x86_64 GNU/Linux
root@readynas:~#

Happy Holidays!


Cheers,

The factory reset after updating to 6.1.5 from an earlier ReadyNAS OS 6 is recommended but not mandatory. Once 6.1.5 has been released the update image will be replaced with one to update direct to 6.1.5. So in the future users newly upgrading their systems from 4.2.x to ReadyNAS OS 6 will get the benefits of 6.1.5 when the required factory default takes place.

mdgm wrote:
The factory reset after updating to 6.1.5 from an earlier ReadyNAS OS 6 is recommended but not mandatory. Once 6.1.5 has been released the update image will be replaced with one to update direct to 6.1.5. So in the future users newly upgrading their systems from 4.2.x to ReadyNAS OS 6 will get the benefits of 6.1.5 when the required factory default takes place.

Based on the following thread it sounds more like it will be mandatory:

https://www.readynas.com/forum/viewtopic.php?f=65&t=73537&start=45#p411589

Although strictly speaking I guess you could get away with not using the larger metadata block sizes. Your second statement makes sense since upgrading directly to 6.1.5 from 4.2.x requires a factory default anyway.


Cheers,

Is there a way to modify the 6.1.5 RC so that it can run on a ReadyNAS Pro 2? I tried to upgrade from 6.1.4 but it returns "... not for this device".

Thanks!

My fault. Tried to use the ARM image for my 102 on the Pro 2, which is Intel. :-/

Did you use the x86_64 image on the Pro 2 already running OS6?

ReadyNASOS V6.1.5 Final out

ReadyNAS OS V6.1.5 Release Notes:

Enhancements & Bug Fixes:

Improved Active Directory handling of slow/remote connections by adding an option to force authentication each time. The "Not sync ADS accounts to local DB" option should be used when each authentication is validated with the ADS server.
Fixed system instability issue with Photos II image import.
Fixed ReadyNAS 4220 power supply unit alarm.
Compatibility improvements for Windows 8.1 Internet Explorer 11.
Fixed smart snapshot automated data pruning issue which could cause devices to not shutdown properly.
Fixed anti-virus engine to address out of memory error and issue preventing successful Windows backup.
FTP permissions update. When new files or sub-folders are created over FTP, file or sub-folder permissions are set to the same settings as the share-folder permission.
Fixed drag and drop file compatibility with Chrome.
SMB security patches applied.
Kernel patches applied.
Improved performance with large volumes (Most likely seen on the ReadyNAS 104). A factory default is required to make the changes. Copy all data off the ReadyNAS, upgrade the firmware, factory default the unit, and copy all data back onto the device

Deployment Notes / Limitations:

After deleting a volume and creating a new one the old volume may still show up until after a reboot.
WOL will not be supported on 3220/4220 at this time for 10GbE. Use 1GbE port for WOL.
Disk failure on the 3220 and 4220 will not show LED failure for the exact drive that has failed, use local web admin page for disk failure information.
Deleting volume with ReadyNAS Vault enabled will show error. User must turn off vault first.
Can't set up bond on interfaces that are not already connected.
If the USB key is missing from the system for Encryption, there is no error message presented.
If USB key is missing for encryption, the user has to wait on a 10 minute timeout. After that, the encrypted volume is displayed as inactive.
If a Flex-RAID volume has been expanded, the volume cannot be switched back to X-RAID mode.
If you wish to remove a USB storage device, you should follow the safe removal procedure of first unmounting before removing the USB device. If these steps are not followed then you may develop errors on the file system on the USB device.
UPS may report incorrect status after reboot, it may send out a warning during this time. After sometime, the UPS will start reporting the correct information.
ReadyNAS 102, 104, and 2120 only support creating iSCSI LUNs 8TB and smaller.