Yes, you can use the "losetup" command to access the data.
Here's an example:
losetup -o 3072 /dev/loop0 /dev/sdb mount /dev/loop0 /mnt ls /mnt
A LUN is grown by adding whole RAIDs, not single devices. You can create a trivial raid0 or raidl from a single device, but the whole LUN then becomes vulnerable to the failure of that device.
Most of the time, you grow an LUN by adding another RAID, as shown in the documentation for the "grow" command in the "EtherDrive SATA/RAID (SR) Appliance Storage Software User Manual".
The low-level settings for the serial connection are documented in the "EtherDrive Storage Installation Guide".
Here is a simple example. You can put a null-modem cable with female db9 connectors between the RAIDBlade and a Linux host's serial port. Then you can run kermit on the Linux host and, at kermit's prompt, do something like this:
set line /dev/ttyS0 set carrier-watch off log session connect
To save time, you can put those lines in a file and run kermit with the name of the file as the argument to kermit.
Yes, but keep in mind that RAID initialization creates the redundancy that protects you from disk failure. Before initialization is complete, your LUN will fail if one disk fails.
Also, performance will not be as great during RAID initialization, compared to operation after initialization is complete.
Yes, a device from the spare pool can be used to replace any failed device. The spare will be recruited to replace the failed device, and then it will be "recovered", after which time the RAID will be fully redundant once again.
Yes, a LUN is just an AoE device as far as other hosts on the LAN are concerned. A Linux host could, for example, use Linux Software RAID 1 to mirror two LUNs.
You can use the "halt" or "reboot" commands to cleanly shutdown the system, including the RAIDs.
The appliance sends syslog messages out from the first network interface. On another host on the LAN, you can configure the syslog daemon to receive messages from other hosts.
These are some of the types of messages the appliance sends:
The AoE appliances do not, in general, perform IP networking. The source IP in the syslog datagrams from any appliance is always the same: 205.185.197.30. You can send test messages from the appliance by using the syslog command after configuring it with "syslog -c".
Some Linux hosts will not pass incoming packets to userspace if the source IP conflicts with the kernel's expectations. Those expectations are built from the receiving NIC's IP address and the Linux host's routing table, so you can prepare the kernel to receive the syslog messages from the appliance by setting the Linux host's AoE-side NIC to 205.185.197.1, or some similar IP (besides 205.185.197.30, of course.) The IP you choose should be unique for your network.
No, you can use any combination of disks you like. However, you will maximize the amount of usable space by using disks of approximately the same size in each raid0, raid1, raid10, or raid5.
The SR Disk Compatibility Table lists the known good and bad drives used by Coraid and our users. This table should be used as a guide when selecting drives.
In general any enterprise- or RAID-class SATA drive should work, whether 150 or 300. Since the rear of the SATA drive plugs directly into the backplane of the chassis, there's no power connector to be concerned about.
Yes. If you just want to move a LUN from one SR to another, you can use the eject and restore commands. They are documented in the SR Software User Manual, found on the SR Support Page.
For a spare shelf, however, you will probably want to pre-configure the spare so that it matches the active shelf. The rest of this answer provides the details that will help you to configure your spare shelf so that it matches the active one.
The configuration of an SR is stored in two places, on the flash disk and on the SATA disk(s).
The configuration stored on the flash includes:
The configuration of the actual LUN/RAID is stored on the component disks. When an SR boots, the startup script reads this configuration from each disk and assembles the LUN/RAID elements belonging to the SR's assigned shelf address.
If the standby and primary SR units have matching configuration stored on their flash disks, then the standby is ready to take the place of the primary unit. The above list may be followed to prepare the standby by setting the shelf address, etc.
When the standby SR is needed, shutdown the primary cleanly (if possible), move the disks to the standby shelf and power it on. On boot the LUN/RAID elements will be started and the standby will behave just like the primary.
Yes, please see SR Performance Analysis for a performance comparison of all the RAID types.
Yes, jumbo frames are enabled in the 20060316 firmware release. An aoe6-25 or newer linux driver is necessary to take advantage of this feature. No configuration is necessary on the SR Appliance to enable jumbo frames.
The linux client will need to have the mtu of the interface increased and any switches between the linux client and the SR Appliance will need jumbo frames enabled. Switches supporting jumbo frames do not usually come with jumbo frames enabled by default.
The SR Appliance does not currently support bonding. Any redundancy achieved by making both interfaces accessible from a client must be provided by the aoe initiator driver.
The aoe6-33 and later aoe drivers contain a feature called multipathing that performs load balancing over multiple targets with the same shelf and slot. For more information on this feature and its implications for the SR1520, please see SR Redundancy and Throughput in Linux
The aoe6-32 and earlier aoe drivers handled aoe targets on multiple paths differently. The aoe driver broadcasts a discovery beacon once a minute. In these earlier drivers, if multiple mac addresses respond for a particular shelf.slot address, the last one to respond becomes the new access destination. When a network path fails, it will be on average 30s before the other path is switched to. This approach has the side effect that the access path can change every minute. For the SR1520 this can be undesirable as the second port does not perform as well as the first port due to its position on the PCI bus.
When doing initial performance testing it is important to start with the simplest configuration possible, then add components. Begin by plugging the client linux system directly into the SR to determine a baseline, then introduce any desired switches to see how it affects throughput.
There are a few things to check to ensure optimal performance.
ddt -t 6g /mnt/foo
If all things appear normal and you still can't get throughput numbers analagous to what we've provided in our analysis papers, you might have packet loss causing excessive retransmissions. To check for this you can run:
cat /dev/etherd/err
... while running ddt to watch for any retransmits that occur. Occasional retransmission is OK, but a steady stream indicates a problem.
Many new drives have the capability to force the drive to perform a certain uplink speed instead of autonegotiating. We've never found this setting to help a disk be more compatibile with the SR Appliance. Barring any bugs internal to the drive firmware, there is no speed advantage to using 3.0 Gbps.
This is because the disk is only capable of reading data off the drive at around 60-80MB/s in the fastest zone. Changing the uplink speed from the drive to the system doesn't have any effect because it's not the bottleneck. The "faster" 3.0 Gpbs drive is largely marketing hype.
The SR can be configured with the syslog command to send out syslog messages to any host that is listening for syslog messages.
Many of the more recent versions of syslog daemon software can be configured to email you on receiving specific kinds of log messages.
Using CEC, the Coraid Ethernet Console, you can run the "halt" command on the SR.
Here is an example expect script that shows how CEC can be used in this way.
Windows support is supplied by StarWind Software's StarPort driver. We have received the following instructions from StarWind on how to access a raw device in Windows:
dd.exe if=<firmware_update> of=<disk>
For further assistance, please contact StarWind Software support.
If a disk is a spare, you should run "rmspare" to remove it from the spare pool before physically removing it.
If a disk is in a RAID in the role of a "failed" component, then there is no need to run a command before physically removing it.
If a disk is a "normal" or "clean" component in a RAID, then in order to preserve the RAID data, the "eject" or "halt" command should be used before the disk is physically removed.
If a disk is not in a RAID and is not a spare, then no command needs to be run before physically removing the disk.
We have hints that will help you get the fastest and best support we can provide at this page: http://support.coraid.com/support/howto.html.