Discussion stats
  • 5 replies
  • 405 views
  • 0 kudos
  • 3 in conversation
Announcements

Top Contributors
Reply
Highlighted
Master

A few bugs I have found while puttering around with a test system

The following are some bugs I have discovered in my various experiments.  Since there is no specified place to post them, here they are.  Each one has been observed more than once and during a process that should not be considered obscure or reckless, though some may be atypical (and, thus, not showing up often).

These have all been found in OS6.9.5. I thought I was ready to upgrade to 6.10.x when the disaster of the bad repository was found, making me question it's "stable" status.

 

Warning regarding mixed drive types in single-drive JBOD volume.

 

Observed multiple times.

 

Here is one example: Created 3 one-drive JBOD volumes. Disks are of mixed RPM (3 & 4 different from 1, with 2 empty in this test). Received these messages in the banner and log:

  • Volume: It is not recommended to mix different disk types. Current volume is using Unknown drives. Please replace the disk in channel 3 (Internal) to match the rest of the disks on volume vol2 for best performance.
  • Volume: It is not recommended to mix different disk types. Current volume is using Unknown drives. Please replace the disk in channel 4 (Internal) to match the rest of the disks on volume vol3 for best performance.

Not observed if all drives are of similar RPM. Not observed if all volumes are at least two drives of same speed class in RAID 1 or 5 (0 and 6 not tested).

 

This appears to be a recurring warning. Since these are single drive volumes, there is no "rest of the disks on volume." If it is a recurring warning, it will get old in a hurry.

 

I suspect this is related to a JBOD being created as a single drive RAID1. It's looking for the "other drive" in the RAID, which it finds to be "unknown".

 

Reference to backup button job when button not pressed -- test unit does not even have a backup button.

 

Observed at least twice.

 

"Backup button job is in progress" in banner on a rack mount system with no backup button (and no backup button option shown in backup menu, as expected). Backup job was manually started and was not the first in a series of jobs manually started.

 

Not really a seriously problematic bug; but a bug, nonetheless.

 

Home folders not properly moved when primary volume is deleted.

 

Observed twice, but does not appear to always occur. Difference in circumstanses unknown, but may be due to the presence of a third volume.

 

Home share created and mounted to /home, with /homes also created as a reflink to /home.


Stems from /etc/systemd/system/multi-user.target.wants/home.mountr not updated with new volume name and can be fixed via SSH by correcting it.

 

I believe this one to be significant.


Inability to create share on newly created volume without reboot.

 

When a second (or third, etc.) volume is created, creation of share on that volume fails, with error code 1013060008 "Specified volume (volume_name) is not valid." It does not matter if the RAID sync is complete or ongoing. Only a re-boot fixes the problem.

 

The share is created and mounted to the proper mount point, so it seems to be within the GUI iteslf -- the share is actually valid.

 

I don't believe this is expected behavior. It is certainly contrary to the ability to create shares and even copy files to that share when the primary volume has just been created and even when it is still doing a RAID sync.

 

I have a few others I have not verified.  Some may simply be "don't do that" kinds iof errors since I do sometimes try some odd things just to see what happens and try to figure out the internals of ReadyNASOS more.

Message 1 of 6
Highlighted
Master

Re: A few bugs I have found while puttering around with a test system

I found a partial reason for the backup button issue on the rack-mount system.  Apparently, though I don't remember doing it, before I moved the volume form a desktop to a rack-mount system, I did have a backup button job configured.  25 minutes after start-up, the backup button job gets performed on the rack-mount system.  I removed it from the <backupButtonJobs> section of  /etc/frontview/backup_jobs.conf and it no longer happens.

 

Still odd that a backup button job gets done at all on a unit with no backup button.

Message 2 of 6
Highlighted
Master

Re: A few bugs I have found while puttering around with a test system

I discovered yet another piece of information regarding the backup button issue today, this time on a ReadyNAS VM.  This time, it was about 6 minutes after the VM was booted that it said it started the backup button job.  While the OS does seem to believe the VM has a backup button (it;'s an option for backups), there were absolutely no backups ever created on this VM before this event.  Something inappropriate is definately triggering backup button backups.

Message 3 of 6
Highlighted
Guru

Re: A few bugs I have found while puttering around with a test system

@OOM-9 (or @JohnCM_S , @Marc_V ):  Looks like there is some stuff here that you all need to put into your bug tracking system for followup.

Message 4 of 6
Highlighted
NETGEAR Moderator

Re: A few bugs I have found while puttering around with a test system

Warning regarding mixed drive types in single-drive JBOD volume.

Yes, this comes up because md0 is across all disks, including single volume JBODs. it's a warning because we do actually create a RAID that spans all disks. Your OS could be impacted.

Inability to create share on newly created volume without reboot. 

This could be setup specific. I haven't been able to reproduce this. 

Reference to backup button job when button not pressed -- test unit does not even have a backup button.

Minor inconvenience. 

Home folders not properly moved when primary volume is deleted.

Not a bug. We put the apps and home folders on what we call 'default volume'. We have been looking into migration options for apps and home folders.

 

Message 5 of 6
Highlighted
Master

Re: A few bugs I have found while puttering around with a test system


@kohdee wrote:

 

Home folders not properly moved when primary volume is deleted.

Not a bug. We put the apps and home folders on what we call 'default volume'. We have been looking into migration options for apps and home folders.

 


It's not a bug if one deletes the "default volume" and a new (empty) home folders share is not created?  It would be great if you did implement a way to actually migrate the content of them and apps, but that's not what I'm pointing to here.

Message 6 of 6