If you are looking for something like NAStySAN today, perhaps have a look here:
NBD, the Network
Block Device (TCP version), is already is in the Linux Kernel distribution
since 1.1.x in /usr/src/linux/drivers/block/nbd.c
It is quite simple but functional, however it is not safe against networking
errors of any kind.
To use it you need some user level programs. For your convenience I
have a local copy for the tools I found were working (it seems to be version
NBD has a Sourceforge Page, too.
The Enhanced Network Block Device
Linux Kernel Module (I never tested it)
This is an improvement over nbd. It is better suited against networking errors
and allows SSL to be used.
The interesting part for me is that it is multithreaded.
There is Drbd is a block device
which is designed to build high availability clusters which allows you to
mirror a block device over the network.
These projects seem sufficient to me, so why another project?
NBD is very small and easy if you look at the Linux kernel driver, I regard
this as very beautiful. However look at the differences of ext2 and ReiserFS,
only look at the journalling code and you will see: Sometimes small and beautiful
is not enough, you need more features. The enhanced version added such features,
however I think this is not the way I want to go.
I want to be able to use an NBD type blockdevice like any blockdevice at boot
time without any helper applications in initrd etc. NAStySAN shall acomplish
this the easy way if you think of an Ethernet card like a SCSI adapter. And
nobody talks about using SSL to your hard drive (at least today). Additionally
it might be feasible to port NAStySAN to another platform than Linux as well.
You need networking to be set up before you can use IP like in NBD. This is
troublesome if you want to boot directly into single user mode.
I want some real type of autoconfiguration which is easy to remember. Something
like mount /dev/nastysan2 /mnt should be enough for NAStySAN to grab
/dev/eth2 and mount the default volume from the hardwired server.
Don't confuse this with NFS, as NFS is a filesystem and not a block
device. This way it shall be sufficient to give root=/dev/nastysan2
on your LILO commandline to boot from your NAStySAN.
I dislike any complicated options to remember, so everything more "advanced"
than last example must rely completely on DevFS. If you want to mount a particuliar
device on a particuliar server this must be as easy as mount /dev/nastysan/eth2/volume2
/mnt2 to mount volume2 over eth2. Perhaps this even can be
integrated into the kernel at boot time but I already think this is too much
To mount a device redundantly over two ethernet cards with load sharing 'n
stuff, this shall look like mount /dev/nastysan/eth2+eth3/volume2 /mnt2.
Yes, I really like such easy thingies, such that you even can use md
style software RAID over NAStySAN as you like.
There must be options to NAStySAN, like timeouts and the like, however I want
the client side (where the NAStySAN kernel driver is used) to get the defaults
from the server such that you can alter the parameters from the server side.
The idea behind this is that you can do a reboot one of the NAStySAN servers
while the clients are not stopped and accesses do not break. Therefor can change
the options of timeout and retry accordingly and then shutdown the server, fix
it and restart it again, without interfering with the client. This way the client
can be free of any configuration besides the knowledge which ethernet card to
use for NAStySAN.
- Who owns NAStySAN?
- Valentin Hilbig
- When was it registered?
- The Domains nastysan.com nastysan.net
were registered 2001-06-01 after a check that neither "NastySAN"
nor "Nasty SAN" were used anywhere in Internet prior art.
The name is not public domain but hereby I grant the irrevocable rigth that
it may be used freely for any free software product according to the GPL.
Except for nastysan.com I am be willing to hand over these domains to other
people, where nastysan.net should be reserved for all languages in TLDs where
some cybersquatters tried to make some money. Don't even think about it, nobody
will ever pay any cent for your domain, just hand it over to the Open Source
community and we are friends again.
nastysan.com shall be the top level "binding" portal which I want
to hand over to any company best suited to contribute to NAStySAN and Free
Software. However this can be revoked at any time.
In the meanwhile everything will be handled by my own server platform.
- May I use the name NAStySAN or "NAStySAN compatible" or something like it
in my propriatary commercial product?
- This depends, best you contact me. Note that I cannot prohibit if you use
it without permission, but this would be really bad manners.
- If your product is Open Source (not neccessary GPL) then the answer
is probably yes.
But be aware that I really really really dislike any companies
utilizing only the nice wording Open Source without contributing to the
Open Source community for real.
Read what rms
says about this.
- If you really contribute to Open Source Community for example by funding
NAStySAN developement the answer is pobably yes, as long as you continue
- If you only want to attach your prorietary product to a NAStySAN server
but don't want to help the community, then probably no.
- If you are Microsoft, as long as you don't apologize for Ballmer's
"Cancer" quote publicly, then definitively no.
- What is NAStySAN?
- It does not exist yet.
- Why NAStySAN?
- Because we need a cool name for such a thing.
If you want to know why I want to invent NAStySAN then I can only tell you
that it is the first step for another long term project (don't try to follow
that link, it is not yet there) which is called de-serf
and perhaps sometimes will come into the real planning phase.
- So when it does not exist and has only has a cool name, what NAStySAN stands
- NAS is Network Attached Storage and SAN is Storage Area Network,
ty stands for "type" and is only a linker betrween because
I thought it is a cool name.
- OK, I know what NAS and SAN are, do you plan some Network Attached SAN or
- No, I thought the opposit, a NAS type SAN would be nice. Therefor the name.
This would be a SAN on a Network layer, but it is not directly network attached.
- Now, what kind of problem do you have?
- I have several problems:
- RAID5 only allows ONE hard drive to fail. A combination of RAID1 and
RAID5 allowes TWO Harddrives to fail, but DOUBLES the number of Harddrives
- If you buy one Harddrive, you cannot easily add it to a RAID to extend
the Volume. This is because the Parity of RAID5 is distributed about all
- It yould be feasible to add a Harddrive to a RAID4, but then you have
a hot spot on the Parity Drive.
- All RAID Harddrives need to be the same size but it's best to always
buy Harddrives with the best money/storage ratio.
- SAN is expensive but would be the right idea.
- NAS is nice, but it's more easy to to think in terms of huge Fileservers.
But if you change the configuration of a Fileserver this usually brings
- Usually I don't have room to put the Harddrives in the casing. I even
don't have any room in the same Rack to add external storage containers.
- Backup. The size of harddrives of the same price doubles each year.
The backup systems only have a linear degression. In 2 years or so harddrives
will be cheaper than backup medias!
Even that DLTs are relatively cheap today compared to the backup size,
for the price of one DLT drive I can buy me arround TWICE the storage
I have today which is arround 200 GB.
So something is definitively wrong if you expect that BACKUPs will be
MORE EXPENSIVE than NEW STORAGE.
- No, I wanted to know what kind of personal problem you have!
- Sigh, no comment, it would be far too long. Perhaps have a look into my
homepage and find out yourself.
- What do you want?
- I need a NAS type SAN, I need NAStySAN. Following should all be easy
- to access the SAN over Ethernet from anywhere
- to add new harddrives
- to take harddrives offline permanently
- to replace harddrives
- to put harddrives anywhere in the network you want
- to make internal snapshots instead of backups
- to archive old snapshots away
- to have an online backup like a transaction log
- to mount a volume directly from GNU/Linux
- to run a computer while something is unavailable in the network
- What do you want NOT?
- Of course you have some drawbacks with such a thing, so I don't want
- highest speed
- boot directly from NAStySAN
- particuliar hardware needs
- to depend on proprietary hardware or software
- access this from Windows directly
- closed source
- to re-invent the wheel
- to be let alone
- Doesn't look like a piece of cake. How do you think it can be done?
- Here is the layout:
Here are some basic things I want:
- Incorporate a block driver into Linux which accesses NAStySAN over an
- Write the NAStySAN Daemon to attach to an Ethernet card to map the NAStySAN
block device to any registered Harddrives.
- Extend the NAStySAN Daemon such, that remote Harddrives from other NAStySAN
Daemons can be registered, too.
- Extend the NAStySAN Daemon such, that it can run in a failover environment,
such that one Daemon takes over if one fails.
- Base this all on GPL. I thought over making it with the lesser licence,
but as Ballmer calls Linux a Cancer I don't want that Win2000 is infected
Some more notes on the first NAStySAN version:
- NAStySAN will only run on a dedicated Ethernet directly on the MAC layer.
It doesn't need the IP layer, but you will need a dedicated NAStySAN ethernet
- NAStySAN thinks of security in terms of physical separation of the NAStySAN
connection from all other network traffic. So there will be no security
in the protocol.
- NAStySAN thinks in terms of a direct physical connection of the block
driver to the Deamon. However both sides should be able to deal with more
than one virtual connection over one ethernet card.
- AFAICS you will be able to use the NetLink driver to communicate from
Linux directly to NAStySAN. However this is not recommended as this might
trigger some Henn-Egg-Problems, for example if you place the Swapfile
on a NAStySAN volume. Perhaps some kernel threads can be written for some
- It will only run on 2.2.x kernels with x>=18 (or perhaps 2.4.x with
- It will only allow a 1:1 connection.
- It will not have any idea of redundancy. This you have to do with MD,
either on the Linux side or you directly register a MD as a NAStySAN volume.
- It will not contain any Logical Volumen Management of any kind. So you
have to use the LVM of Linux or to register a LVM as a NAStySAN volume.
- It will not have any transaction log or snapshot options
- It is very likely that it is not compatible to the second version. However
there will be an option to register Harddrives the old way.
- It will be dead slow as there is no kernel thread
- However it will be safe against networking or transaction errors. So
you can change the wiring while it is in action without any fear or shutdown
the server while in the middle of operation.
- Who knows?
Currently I wait to build my test platform.
- Can I help?
- Of course! See Souceforge.
But be aware that the project is in the "pre-planning-phase" and
might stay there till 2010. OOPS.
If you want to support me, I have a wishlist
Sunday, 2001-06-17 0:40 tino