NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
rn2120 - freezes! help!!!
hello.
Need help.
I do not understand rn2120, constant freezes if read/write speed than 30-40 MBps.
On the shelves have to wheel 4 VM, but I can not run and three.
is the last version 6.1.8
room temperature is 18 degrees.
connection: 2 channels 1Gb used 2 ISCsi
drives - WD VelociRaptor WD1000DHTZ, 1TB, HDD, SATA
off all the extra features (antivirus, backups, etc.)
Need help.
I do not understand rn2120, constant freezes if read/write speed than 30-40 MBps.
On the shelves have to wheel 4 VM, but I can not run and three.
is the last version 6.1.8
room temperature is 18 degrees.
connection: 2 channels 1Gb used 2 ISCsi
drives - WD VelociRaptor WD1000DHTZ, 1TB, HDD, SATA
off all the extra features (antivirus, backups, etc.)
9 Replies
Replies have been turned off for this discussion
- Your best option is to contact support for proper debug of the issue
http://support.netgear.com/product/RN2120#wrapper - Try 6.1.9-RC5.
-- source: viewtopic.php?f=154&t=75795Skywalker wrote: 6.1.9-RC5 gives you the ability to configure the sync write policy on iSCSI LUNs. This allows you to switch sync writes to disabled, to match the behavior of our earlier products and competitors' offerings. Our default is to flush the disk write caches when the initiator asks for a sync write, which is probably what is causing your slowness, since some initiators/workloads ask for sync writes *a lot*. Skywalker wrote: 6.1.9-RC5 gives you the ability to configure the sync write policy on iSCSI LUNs. This allows you to switch sync writes to disabled, to match the behavior of our earlier products and competitors' offerings. Our default is to flush the disk write caches when the initiator asks for a sync write, which is probably what is causing your slowness, since some initiators/workloads ask for sync writes *a lot*.
Installed the beta version of the firmware, unfortunately it did not solve my problems.
Just noticed that whenever the device is reset, it starts to rebuild the raid.- Empirically, we found out that the system freezes if the machine starts to Exchange 2013 SP1 (DAG). Moreover, the peak load is not.
If there are developers that can send all the logs.
Just started contacting support. - [quote="doctorcat"Installed the beta version of the firmware, unfortunately it did not solve my problems.[/quote]
Did you change the LUN setting for "Sync Writes" to "Disabled"? Skywalker wrote: [quote="doctorcat"Installed the beta version of the firmware, unfortunately it did not solve my problems.
Did you change the LUN setting for "Sync Writes" to "Disabled"?[/quote]
no standing to allow.
Now rearranged.
Could not explain the details on this feature LUN?Skywalker wrote: 6.1.9-RC5 gives you the ability to configure the sync write policy on iSCSI LUNs. This allows you to switch sync writes to disabled, to match the behavior of our earlier products and competitors' offerings. Our default is to flush the disk write caches when the initiator asks for a sync write, which is probably what is causing your slowness, since some initiators/workloads ask for sync writes *a lot*. Skywalker wrote: Skywalker wrote: 6.1.9-RC5 gives you the ability to configure the sync write policy on iSCSI LUNs. This allows you to switch sync writes to disabled, to match the behavior of our earlier products and competitors' offerings. Our default is to flush the disk write caches when the initiator asks for a sync write, which is probably what is causing your slowness, since some initiators/workloads ask for sync writes *a lot*.
OK, thanks, I will unsubscribe later on the results.- After 3 hours the device responds again.
At 1 to 2 Target LUN.
4 VMs running
---------------
Fears were confirmed.
To fall a device causes the database to work with Exchange 2013.
Once the database has been moved to another device, operation of the device to be normalized.
Most likely it is connected with the work of the file system device. For this reason, developers need to fix this bug. device shipped in various ways, but none of them had brought him out of action. Running 20 VMs resulted long delay intervals, but the unit continued to work and was manageable.
But one machine with the role of DAG killing device after the start quickly enough.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
