ATA OVER ETHERNET
ATA over Ethernet (AoE) is a network protocol developed by the Brantley Coile Company, designed for simple, high-performance access of SATA storage devices over Ethernet networks. It gives the possibility to build SANs with low-cost, standard technologies.
AoE does not rely on network layers above Ethernet, such as the IP and TCP that iSCSI requires. While this makes AoE potentially faster than iSCSI, with less load on the host to handle the additional protocols, it also means that AoE is not routable outside a LAN. AoE is intended for SANs only. In this regard it is more comparable to Fibre Channel over Ethernet than iSCSI. An alternative to iSCSI, the AoE specification is 8 pages compared with iSCSI's 257 pages.
There are four targets ( servers ) available which serves aoe initiator ( clients ) to export the block devices over network.
1 ) QAOED
Qaoed is a multithreaded ATA over Ethernet storage target that is easy to use and yet higly configurable.
How to:
Unmount your block device and do the corresponding entry into qaoed.conf file and run following command to export the corresponding block device over network.
./qaoed -c qaoed.conf
sample configuration file : qaoed.conf
default
{
shelf = 0; /* Shelf */
slot = 0; /* Autoincremented slot numbers */
interface = eth0;
}
device
{
target = /dev/sda2;
}
Available configurable options:
The configuration of the aoe server are grouped into sections.
1. The global directives sections. This is where global configuration options for the aoe-server are set, for example default-log level.
2. The logging section defines the logging targets configurable in the device and interface sections.
3. The interface section configures values for the different interfaces.
4. The default section defines default values for block-devices. Options defined in the default-section can be omited in device configuration.
5. Devices, one section for each exported device.
6. Access-lists.
2) GGAOED
ggaoed is an AoE target implementation for Linux, distributed under the terms
of the GNU GPL, version 2 or later. ggaoed has the following features:
- A single process can handle any number of devices and any number of
network interfaces
- Uses kernel AIO to avoid blocking on I/O
- Uses eventfd for receiving notifications about I/O completion
- Uses epoll for handling event notifications
- Uses memory mapped packets to avoid syscall overhead when receiving data
from the network
- Can identify devices either by path or UUID using the libblkid library
- Can handle dynamic appearance/disappearance of network interfaces
- Can use direct I/O
how to :
./ggaoed -c ggaoed.conf -d
If the device is mounted at client side then server side it can't be mounted.
Available configurable option:
1)network interface configuration
2)acl definition
3)disk device configuration
example file : ggaoed.conf
[sdc]
path = /dev/sda2
shelf = 0
slot = 0
broadcast = true
read-only = true
queue-length=64
direct-io=true
read-only=false
3) KVBLADE
Kvblade is a kernel module implementing the target side of the AoE protocol. Users can command the
module through sysfs to export block devices on specified network interfaces. The loopback device
should be used as an intermediary for exporting regular files with kvblade. Three shell scripts have been created to facilitate interfacing with kvblade through sysfs: kvstat, kvadd, and kvdel. Kvstat
prints the list of currently exported vblades. Kvadd and kvdel are used to manage the exported vblades.
how to : run following command to export your block device which is /dev/sda5 in this case :
modprobe kvblade
./kvadd 0 1 eth0 /dev/sda5
There are bugs in kvblade. Unnecessary error message comes on the screen while establishing the connection. Further it doesn't give the correct size of corresponding exported device. On the client side:
[root@localhost kvblade-alpha-3]# modprobe aoe
[root@localhost kvblade-alpha-3]# aoe-stat
e0.1 80.026GB eth0 1024 up
[root@localhost kvblade-alpha-3]#
[root@localhost kvblade-alpha-3]# mount /dev/etherd/e0.1 /mnt/
[root@localhost kvblade-alpha-3]# df /mnt
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/etherd/e0.1 3026640 172848 2697564 7% /mnt
[root@localhost kvblade-alpha-3]#
Here the exported device has its size 3GB, but it shows 80 GB. Further, there is no configuration file available. So, lots of manual work has to do or we have to make it configurable by our own. Its faster than vblade.
4) VBLADE
The vblade is the virtual EtherDrive (R) blade, a program that makes a seekable file available over an ethernet local area network (LAN) via the ATA over Ethernet (AoE) protocol.
The seekable file is typically a block device like /dev/md0 but even regular files will work. Sparse files can be especially convenient. When vblade exports the block storage over AoE it becomes a storage
target. Another host on the same LAN can access the storage if it has a compatible aoe kernel driver.
How to:
./vblade 0 1 eth0 /dev/sda5
There is no configurable file available to configure the disk. So, the exported disk can't be configured easily.
OVERALL CONCLUSION:
Experiments has done on one client and one server. We can go for ggaoed or qaoed.
Tuesday, February 24, 2009
Wednesday, March 19, 2008
The const phenomenon
These are some basic and quite interesting things about const where a programmer can does mistakes. Although I have tried to make all the concepts correct , but if anybody find any incorrect information in it , then please let me know.
1.
most fundamental things about const :
a) const fred* const ptr : neither ptr nor *ptr can changed
b) fred * const ptr : ptr can't be changed but *ptr can't be changed
c) const fred * ptr : ptr can change but *ptr can't be changed
d)const fred & kk : const fred& is a reference to a fred that can't be changed via that reference ( here kk )
for ex:
calss fred { public: int i; fred(){i=0;} }
int main()
{
fred kk1,kk2;
const fred & kk=kk1;
kk1.i=5;
//kk.i=10;
return 0;
}
here kk.i will prompt for an error.
fred & const : doesn't make sense, because we can never rebind the reference so that it refers to a different object.
2.
Const Correctness :
If we have to avoid making unexpected changes to objects , then it can be done by proper using of keyword const. The c++ compiler detects many unexpected changes to objects and it flags these violations with error messages at compile time.
for ex:
void f( const string& s)
throw(); // parameter is received by reference to const
3.
Const correctness : It should be done sooner rather than later ( to avoid the ripple effect in function calling, where one function contain oth rs )
4.
Inspector & Mutator class:
fred {
public:
int kk() ; // mutator
int kk1() const ; // inspector
}
An inspector is a member function that returns information about an object's state without changing the object's abstract state. A mutator changes the object's abstract state.Whenever the member function wants to guarntee that it won't make any observable changes to its "this" object , then we make this member function constant.
5.
Const, formal parameter and pass by value :
We should not use const for formal parameter types, that are passed by value, because a const on a pass by value parameters affects only the code inside the function, it doesn't affect the caller. For ex,
replace f(const fred x) with either f(const fred &x ) or f(fred x)
replace f(fred * const p) with f(fred * p).
6.
If we want to change the data member inside const member function, the we have to make that data member mutable or if it can't be done then we should use const_cast.
1.
most fundamental things about const :
a) const fred* const ptr : neither ptr nor *ptr can changed
b) fred * const ptr : ptr can't be changed but *ptr can't be changed
c) const fred * ptr : ptr can change but *ptr can't be changed
d)const fred & kk : const fred& is a reference to a fred that can't be changed via that reference ( here kk )
for ex:
calss fred { public: int i; fred(){i=0;} }
int main()
{
fred kk1,kk2;
const fred & kk=kk1;
kk1.i=5;
//kk.i=10;
return 0;
}
here kk.i will prompt for an error.
fred & const : doesn't make sense, because we can never rebind the reference so that it refers to a different object.
2.
Const Correctness :
If we have to avoid making unexpected changes to objects , then it can be done by proper using of keyword const. The c++ compiler detects many unexpected changes to objects and it flags these violations with error messages at compile time.
for ex:
void f( const string& s)
throw(); // parameter is received by reference to const
3.
Const correctness : It should be done sooner rather than later ( to avoid the ripple effect in function calling, where one function contain oth rs )
4.
Inspector & Mutator class:
fred {
public:
int kk() ; // mutator
int kk1() const ; // inspector
}
An inspector is a member function that returns information about an object's state without changing the object's abstract state. A mutator changes the object's abstract state.Whenever the member function wants to guarntee that it won't make any observable changes to its "this" object , then we make this member function constant.
5.
Const, formal parameter and pass by value :
We should not use const for formal parameter types, that are passed by value, because a const on a pass by value parameters affects only the code inside the function, it doesn't affect the caller. For ex,
replace f(const fred x) with either f(const fred &x ) or f(fred x)
replace f(fred * const p) with f(fred * p).
6.
If we want to change the data member inside const member function, the we have to make that data member mutable or if it can't be done then we should use const_cast.
Tuesday, March 18, 2008
FACTS ABOUT STATIC VARIABLES IN C++
1.
Most fundamental:
Static data member and static member function:
Static data members are often referred to as class data, and static member functions are often referred to as class services or class methods. Static data members are like data located in the factory rather than in the objects produced by the factory. Just as a factory exists before it produces its first object, class (static) data can be accessed before the first object is instantiated as well as after the last object has been destroyed. Static data member is like a global variable with a funny name that doesn't need to be public. Static member functions and top level friend functions are similar in that neither has an implicit this parameter, and both have direct access to the class's private: and protected: parts.
Syntax for accessing static data member and member function:
int fred:: x_=3;
classname::staticmember()
If we want to acess static member function classname::f() from another member function of class classname then there is a exception.
For example,
when classname::f() is a protected: static memeber function of the class ,
simply write f() rather than classname::f().
.2.
Static data member and static member function:
Static data members are often referred to as class data, and static member functions are often referred to as class services or class methods. Static data members are like data located in the factory rather than in the objects produced by the factory. Just as a factory exists before it produces its first object, class (static) data can be accessed before the first object is instantiated as well as after the last object has been destroyed. Static data member is like a global variable with a funny name that doesn't need to be public. Static member functions and top level friend functions are similar in that neither has an implicit this parameter, and both have direct access to the class's private: and protected: parts.
Syntax for accessing static data member and member function:
int fred:: x_=3;
classname::staticmember()
If we want to acess static member function classname::f() from another member function of class classname then there is a exception.
For example,
when classname::f() is a protected: static memeber function of the class ,
simply write f() rather than classname::f().
.2.
Inline fuctions and static data members:
It is not safe to use static data member through inline functions. The static data member might not be initialize before using it in inline fuction. So, it can create a problem in code. Try to avoid accessing static data member through inline function. Some, but not all compilers initialize static data member before the main begin. Therefore the success or failure of the code might even depend on the order that object files are passed to the linker, and some visual environment hide the linker so well, that many programmers don't even know the order in which object files are passed to the linker.
3.
Class with static data member and linker error:
For the safe hand, Static data member must be explicitly defined in exactly one source file. Ignorance of the static initialization order problem can result in application crashes.
4.
const static data member and its initialization:
A const data member is described in the class and is normally defined ( and initialized ) in a source file. But in some cases it can be initialized in the class body proper. For ex: int, unsigned long, char, and so on, are special: they can be initialized where they are declared in the class body proper.
Sample file, fred.hpp
#includeusing namespace std;
class barney { };
class fred {
public : ..........
private:
static const int i_ =42;
static const char c_= 'z';
static const float x_;
static const string s_;
static const barney b_;
}
source file
fred.cpp
#include "fred.hpp"
const float fred::x_=3.14;
const string fred::s_"hello";
const barney fred::b_;
5.
Implementing a function that maintains its state between the class:
To maintain a function that maintains its state between the call, we should not use the function which contain static variable, rather we should use functionaid or we should use functor. Because the static variable create subtle error in case of shared memory, and multi threading environment.
It is not safe to use static data member through inline functions. The static data member might not be initialize before using it in inline fuction. So, it can create a problem in code. Try to avoid accessing static data member through inline function. Some, but not all compilers initialize static data member before the main begin. Therefore the success or failure of the code might even depend on the order that object files are passed to the linker, and some visual environment hide the linker so well, that many programmers don't even know the order in which object files are passed to the linker.
3.
Class with static data member and linker error:
For the safe hand, Static data member must be explicitly defined in exactly one source file. Ignorance of the static initialization order problem can result in application crashes.
4.
const static data member and its initialization:
A const data member is described in the class and is normally defined ( and initialized ) in a source file. But in some cases it can be initialized in the class body proper. For ex: int, unsigned long, char, and so on, are special: they can be initialized where they are declared in the class body proper.
Sample file, fred.hpp
#include
class barney { };
class fred {
public : ..........
private:
static const int i_ =42;
static const char c_= 'z';
static const float x_;
static const string s_;
static const barney b_;
}
source file
fred.cpp
#include "fred.hpp"
const float fred::x_=3.14;
const string fred::s_"hello";
const barney fred::b_;
5.
Implementing a function that maintains its state between the class:
To maintain a function that maintains its state between the call, we should not use the function which contain static variable, rather we should use functionaid or we should use functor. Because the static variable create subtle error in case of shared memory, and multi threading environment.
Subscribe to:
Comments (Atom)
