Please try to update the module. http://www.fusionstor.com/...If this does not help, please contact our support team to get the module replaced.
In your Web Browser enter: https://IP_ADDRES_OF_THE_SERVER/check_sys/.
You will have possibility of entering system performance statistics. Also you can get this information using SNMP protocol. On our server is implementation of snmp in version 3.
It is caused by greater than 30 minutes differences, between local and remote computer.
This is not caused by our software, probably it is done by RAID controller.
For more information please follow the instructions on RAID controller Release
Notes:
here
Our software has no problems while working with multi-processor.
In Console Tools we have implemented function which allows choosing type of running configuration:
Single processor
Multi processor
The FusionStor Atomic system is compiled for 32 - bits, and in this moment you will not see any improvements using 64-bit processor.
In the next year (at the end of it) we plan a release of version of FusionStor Atomic and Cosmic for 64-bit architecture.
Please make an update to the newest version of FusionStor Atomic (v. 1.76 b1268 ). It should solve the problem.
Try to use such notation:
In order to mount NFS exclusive storage space, please use following syntax:
mount -t nfs IP_addr:/nfs /local_mount_point
In order to mount the space belongs to a share created in resources menu, please use following syntax:
mount -t nfs IP_addr:/share/share_name /local_mount_point
Please make sure that IP address from which you are trying to mount has such rights. If you have entered any address to "Allow access IP"
("NFS share access" function) please make sure if it is correct.
Check if share which you are trying to mount exists, and has NFS access enabled.
If you have checked everything, and still same error appears please send us the system logs.
Antivirus protection is available in all our products – FusionStor Atomic, Cosmic & Infinit.
Linux file systems are constructed in such a way that defragmentation is not needed (the kernel takes care about it).
The fragmentation is on the level of about 1-2 %. Preparing an defragmentation algorithm is possible but not needed - the gain of performance will rather not be visible.
We do support data replication between two or more than two NAS servers, also bi-directional, but we do not support data mirror in current NAS product. Please let me describe how data synchronization works:
The minimum delay of data synchronization is 1 minute. User can choose the synchronization delay between 1 minute till 12 hours, or schedule a day (days) and time. This is very stabile and field proven solution. User can use it as disaster recovery solution, if set to frequent data synchronization or as backup if set for daily or weekly synchronization. It can be used for both (disaster recovery and backup) if you schedule first task for every minute synchronization and second task for every day synchronization. In such case you have two replicated data set. First one, very recent data set and second data set, as last day backup.
Delayed data synchronization will have advantage over data mirror in many cases like: accidental date erase, corrupted file system, sabotage etc.
Not delayed data mirroring is a must only in case when application can not stand even few minutes interruption.
There is no configuration necessary.
Please use a SNMP-Client of your choice and connect it to the IP of your NAS device.
List of MIBS:

mib-2.host

mib-2.ip

mib-2.tcp

mib-2.udp

mib-2.interfaces

mib-2.at

system
FusionStor Atomic is a Storage solution. There is no option to share a printer over a NAS device. Please use a printer-server for this purpose.
We are working on the option to hide snapshot share and also printer share. It will be available in future versions on FusionStor Atomic products.
FusionStor systems supports SMB/CIFS, NFS, AFP(AppleTalk), FTP and HTTP Browser
IPfrag Tuning - it is a packet fragmentation section. You can set arrange of it in this option
Jumbo Frames Config also called MTU (Maximum Transmission Unit) - refers to the size (in bytes) of the largest packet that a given layer of a communications protocol can pass onwards.
NFS Daemon tuning - you can set how many NFS daemons you want to have run in the system. On some system NFS causes NFS timeouts and changing this value then helps. It also can improve NFS performance.
Read ahead disk tuning - with this option you can increase for better performance size of cache. In some cases it is required to decrease it for better compatibility.
iSCSI daemon option - in this option you can set values of iSCSI target:
a) MaxRecvDataSegmentLength - Sets the maximum data segment length that can be received. This value should be set to multiples of PAGE_SIZE. Currently the maximum supported value is 64 * PAGE_SIZE, e.g. 262144 if PAGE_SIZE is 4kB. Configuring too large values may lead to problems allocating sufficient memory, which in turn may lead to SCSI commands timing out at the initiator host. The default value is 8192.
b) MaxBurstLength - Sets the maximum amount of either unsolicited or solicited data the initiator may send in a single burst. Any amount of data exceeding this value must be explicitly solicited by the target. This value should be set to multiples of PAGE_SIZE. Configuring too large values may lead to problems allocating sufficient memory, which in turn may lead to SCSI commands timing out at the initiator host. The default value is 262144.
c) MaxXmitDataSegmentLength - Sets the maximum data segment length that can be sent. This value actually used is the minimum of MaxXmitDataSegmentLength and the MaxRecvDataSegmentLength announced by the initiator. It should be set to multiples of PAGE_SIZE. Currently the maximum supported value is 64 * PAGE_SIZE, e.g. 262144 if PAGE_SIZE is 4kB. Configuring too large values may lead to problems allocating sufficient memory, which in turn may lead to SCSI commands timing out at the initiator host. The default value is 8192.
d) DataDigest - If set to "CRC32C" and the initiator is configured accordingly, the integrity of an iSCSI PDU's data segment will be protected by a CRC32C checksum. The default is "None". Note that data digests are not supported during discovery sessions.
e) MaxOutstandingR2T - Controls the maximum number of data transfers the target may request at once, each of up to MaxBurstLength bytes. The default is 1.
f) InitialR2T - If set to "Yes" (default), the initiator has to wait for the target to solicit SCSI data before sending it. Setting it to "No" allows the initiator to send a burst of FirstBurstLength bytes unsolicited right after and/or (depending on the setting of ImmediateData together with the command. Thus setting it to "No" may improve performance.
g) ImmediateData - This allows the initiator to append unsolicited data to a command. To achieve better performance, this should be set to "Yes". The default is "No".
h) DataPDUInOrder - It tells initiator if data has to be sent in order. Defualt is "Yes", which is also recommended.
i) DataSequencerInOrder - It tells initiator if data has to be sent in order. Defualt is "Yes", which is also recommended.
j) HeaderDigest - If set to "CRC32C" and the initiator is configured accordingly, the integrity of an iSCSI PDU's header segments will be protected by a CRC32C checksum. The default is "None". Note that header digests are not supported during discovery sessions.
k) Wthreads - The iSCSI target employs several threads to perform the actual block I/O to the device. Depending on your hardware and your (expected) workload, the number of these threads may be carefully adjusted. The default value of 8 should be sufficient for most purposes.
You must enter to Console Tools (ALT+CTRL+T) -> Boot Options -> Select system architecture and choose desired kernel.
Yes, the FusionStor Atomic, Cosmic and Infinit support Logical Volumes greater than 2TB and physical size of up to 16TB.
It is possible under Console Tools (ALT+CTRL+N) , selcting desired NIC and editing DHCP and checking box DHCP.
IPfrag Tuning - it si apcket fragmentation section. You can set arnage of it in this option
Jumbo Frames Config also called MTU (Maximum Transmission Unit) - refers to the size (in bytes) of the largest packet that a given layer of a communications protocol can pass onwards
. NFS Daemon tuning - you can set how many NFS daemons you want to have run in the system. On some system NFS causes NFS timeouts and chnging this value then helps. It also can improve NFS performance.
Read ahead disk tuning - with this option you can increase for better performance size of cache. In some cases it is rquierd to decrese it for better compatiblity.
iSCSI daemon option - in this option you can set values of iSCSI target:
1. MaxRecvDataSegmentLength - Sets the maximum data segment length that can be received. This value should be set to multiples of PAGE_SIZE. Currently the maximum supported value is 64 * PAGE_SIZE, e.g. 262144 if PAGE_SIZE is 4kB. Configuring too large values may lead to problems allocating sufficient memory, which in turn may lead to SCSI commands timing out at the initiator host. The default value is 8192.
2. MaxBurstLength - Sets the maximum amount of either unsolicited or solicited data the initiator may send in a single burst. Any amount of data exceeding explicitly solicited by the target. This value should be set to multiples of PAGE_SIZE. Configuring too large values may lead to problems allocating sufficient memory, which in turn may lead to SCSI commands timing out at the initiator host. The default value is 262144.
3. MaxXmitDataSegmentLength - Sets the maximum data segment length that can be sent. This value actually used is the minimum of MaxXmitDataSegmentLength and the MaxRecvDataSegmentLength announced by the initiator. It should be set to multiples of PAGE_SIZE. Currently the maximum supported value is 64 * PAGE_SIZE, e.g. 262144 if PAGE_SIZE is 4kB. Configuring too large values may lead to problems allocating sufficient memory, which in turn may lead to SCSI commands timing out at the initiator host. The default value is 8192.
4. DataDigest - If set to "CRC32C" and the initiator is configured accordingly, the integrity of an iSCSI PDU's data segment will be protected by a CRC32C checksum. The default is "None". Note that data digests are not supported during discovery sessions.
5. MaxOutstandingR2T - Controls the maximum number of data transfers the target may request at once, each of up to MaxBurstLength bytes. The default is 1.
6. InitialR2T - If set to "Yes" (default), the initiator has to wait for the target to solicit SCSI data before sending it. Setting it to "No" allows the initiator to send a burst of FirstBurstLength bytes unsolicited right after and/or (depending on the setting of ImmediateData together with the command. Thus setting it to "No" may improve performance.
7. ImmediateData - This allows the initiator to append unsolicited data to a command. To achieve better performance, this should be set to "Yes". The default is "No".
8. DataPDUInOrder - It tells initiator if data has to be sent in order. Defualt is "Yes", which is also recommended.
9. DataSequencerInOrder - It tells initiator if data has to be sent in order. Defualt is "Yes", which is also recommended.
10. HeaderDigest - If set to "CRC32C" and the initiator is configured accordingly, the integrity of an iSCSI PDU's header segments will be protected by a CRC32C checksum. The default is "None". Note that header digests are not supported during discovery sessions.
11. Wthreads - The iSCSI target employs several threads to perform the actual block I/O to the device. Depending on your hardware and your (expected) workload, the number of these threads may be carefully adjusted. The default value of 8 should be sufficient for most purposes.