fig1 a and 1b , illustrate legacy approach to storage area network design and implementation . such san controller supports multiple virtual volumes ( luns ) creating an illusion that there are many independent disks . both front - end and back - end code run on the same san controller providing as much bandwidth as such implementation ( hardware , firmware , or embedded software ) allows . in addition , unusually , there is only one instance of code and data structures that handles particular virtual disk . therefore , all i / o traffic associated with that particular virtual disk is handled by that code instance which could become a bottleneck in heavy i / o traffic conditions . some solutions utilize shared memory architecture to improve i / o bandwidth . however , again , one single instance of the data structures has to be accessed creating opportunity for a bottleneck to occur . as motioned in the preceding paragraphs , this solution does not scale well since there is no option of scaling the processing power by adding more controllers . fig3 , the present invention , illustrates the hardware architecture that enables parallel execution of the front - end and back - end code on the fe_san and be_san controllers respectively . there are multiple instances of the front - end code , preferably one or more per host or cluster node . likewise , one or more be san controllers at the back - end execute back - end code in parallel . fe_san and be_san controllers are connected via interconnecting network , preferably via rearrangeably non - blocking clos network utilizing but not limited to inexpensive as or myrinet switches . nevertheless , any network topology is allowed since the architecture is network ( transport ) neutral . however , if the underlying network provides lower latency and higher bandwidth the whole architecture will deliver better performance . this approach yields to the higher data rate and i / o performance compared to previously described legacy san system . preferably the present invention is implemented in firmware running over a multitasking pre - emptive real time operating system ( rtos ) on hardware platform comprised of one or more embedded central processing units ( cpus ), possibly application - specific integrated circuits ( asic ), or field - programmable gate arrays ( fpga ), a random access memory ( ram ), and programmable input / output ( i / o ) interfaces . it is to be appreciated that the various processes and functions described herein may be either part of the hardware , embedded microinstructions running on the hardware , or firmware ( embedded software ) executed by the rtos . however , it should be further understood that the present invention might be implemented in various other forms of hardware , software , firmware , or a combination thereof . fig5 a and 5b are high - level block diagrams that illustrate software layers inside the system software on the host side and front - end and back - end layers specific for legacy raid and storage area network controller . certainly , there are more than just front - end and back - end layers in a san software architecture however ; this is not relevant for understanding of the concepts used in this invention . scsi standard defines the device model and scsi command set for all scsi devices ( please see fig7 a ). the scsi command set is designed to provide efficient peer - to - peer operation of scsi devices ( disks , tapes , printers , etc .) by an operating system . the scsi command set provides multiple operating systems concurrent control over one or more scsi devices . however , proper coordination of activities between the multiple operating systems is critical to avoid data corruption . commands that assist with coordination between multiple operating systems are described in the scsi standard . fig6 , is a high - level block diagram that illustrates how front - end and back - end code are executed in parallel and independently on fe_san and be_san controllers . even though , scsi standard provides methods for a number of hosts ( operating systems ) concurrently accessing and asserting control over scsi devices , in a complex system such as the one shown on the fig6 that may not be sufficient . if there was no mechanism to internally enforce atomic execution for read , write , and some other commands , the data integrity could be jeopardized . consequently , such locking mechanism that provides atomicity has to be built in to the system . the issue is that some kind of the actions ( requests or commands ) that have to be atomic must not be executed until it is safe to do so . atomic execution for some commands in the system from fig6 is essential part of the invention since it protects the data integrity . front - end code , generally , performs command processing and virtual block address ( vba ) translation to logical block address ( lba ) and sends them to the appropriate be_san controllers . the back - end code , then , checks whether the command could be executed immediately or not . the command may have to be queued for later execution , or yet busy signal could be returned to the front - end code . since , the front - end and back - end codes execute asynchronously before a command that requires atomic execution , such as writing to device media , could be started all the requirements for successful command completion have to be met . for example , to ensure correct execution of a write command , lbas that data have to written to have to be locked and off limit to other write or read commands . that means that write command has to be executed atomically . the front - end code will examine the command ; determine that a write command had been received . then it will send a lock request to the appropriate be_san controllers to acquire distributed lock . back - end code will respond acknowledging successful locking of the requested lbas . at this point , it is safe to write to the locked lbas , lbas usually spread across multiple disk drives . upon the successful completion of the write command , the lock is removed by the front - end code . there are some other commands that might require atomic execution ; however the same locking mechanism could be used for those commands . previously described method would not permit concurrent writes to occur to the same lbas which would limit the write performance to a single file . indeed , it is not possible to actually write data to a disk media simultaneously from two different and independent sources without having a risk of actually corrupting the data . however , if sufficient buffer space is available at be - san controllers the data that have to be written from number of different hosts ( initiators ) could be concurrently spooled into pre - allocated independent memory buffers without risking data corruption . to achieve this kind of parallelism on a write request fe_san controller will request a lock for all lbas that have to be written to . if currently there are no other writers , the lock will be granted . however , if there is another writer holding a lock , every be_san controller has to be written to will check if there is sufficient buffer space to satisfy the request . if the request could be satisfied a tagged - lock will be issued and the data transfer from the host to the allocated buffer would be initiated . the actual writes to the disks would be done in the order that tagged - locks are granted . if the front - end code for some reason was unable to acquire a lock on all the lbas it needs it will release all already locked lbas and start the process all over again . in case that default number of attempts is exceeded upper management software layers will resolve the issue by verifying the reason for the unsuccessful locking . an additional advantage is that the locks are associated with luns using specific id ( identifiers ). therefore , back - end code would not have to search through long lock tables to discover whether a command ( request ) could be executed or not . another advantage is that only lbas that are locked out might be inaccessible during that time . all other lbas are accessible allowing greater level for parallelism . the actual implementation may vary due to use of some specific hardware or of the shelf software . however , the principal architecture would not change . it would be relatively straight forward to use of the shelf inexpensive but not limited to x86 hardware platform with embedded rt os or embedded linux os on it for the be_san controllers since great deal of functionality is already available . for the fe_san controllers the same platform could be used as for the be_san controllers . however , if as or myrinet network is the interconnect of choice between fe_san and be_san controllers it would be natural to use of the shelf or modified pcie single board computer or myrinet interface cards to execute front - end code on them . for entry - level systems , where the cost is more important than performance , the front - end code could be embedded in the device driver . in an embodiment , individual storage units such as hard disk drives 902 , 904 , 906 , 908 , 910 are coupled to back - end storage controller ( be_san ) 912 . further , individual storage units such as hard disk drives 922 , 924 , 926 , 928 , 930 are coupled to at least a second back - end storage controller ( be_san ) 932 . both be_sans 912 , 932 are coupled to be accessed through network 940 from at least one or more fe_san controller 942 , 944 . further , each fe_san is coupled to at least one host computer 950 , 952 . fig9 illustrates virtual disks that span multiple disk drives , such as virtual disks 954 , 956 , 958 . in an embodiment , virtual disk 954 uses hard disks 902 , 904 , 906 , virtual disk 956 uses hard disks 908 , 910 , 922 — spanning two be_sans , and virtual disk 958 uses hard disks 924 , 926 , and 928 . hard disk 930 is initially a hot spare storage device . virtual disk 954 is configured as a raid ( redundant array of independent disk drives ) storage system . in normal operation , storage references to virtual disk 954 are processed in part by be_san 912 executing raid code 970 on a processor , such as a cpu of be_san 912 . raid code 970 includes code for writing physical drives , such as drives 902 , 904 , 906 , recognizing failed disk drives , for reconstructing data read from functioning drives and transmitting that data through network 940 to an accessing fe_san , all as per specifications for one or more of raid modes 1 , 10 , 2 , 3 , 4 , 5 and 6 as known in the art of raid storage systems . in a particular embodiment , virtual disk 954 is configured to operate as a raid - 5 mode virtual disk , with block - level striping and distributed parity , such that redundancy is minimized but data is recoverable even if one drive used by virtual disk 954 has failed . in an alternative embodiment , virtual disk 954 is configured to operate as a raid - 6 mode virtual disk system . in an embodiment , virtual disk 958 , operating with drives 924 — 926 , 928 , on the second be_san 932 , is also configurable as a raid , in an embodiment a raid - 5 mode virtual disk , and in an alternative embodiment a raid - 6 mode virtual disk . some existing raid controllers , including some operable in raid - 5 or raid - 6 modes , have the ability to reconstruct data onto a replacement hard disk from remaining disks used by a raid dataset or virtual disk ; in these systems , once a failed disk has been replaced with a spare disk , data is reconstructed onto the spare disk . once data is reconstructed onto the spare disk - which becomes a formerly - spare disk , redundancy is restored and , should a second disk used by the raid virtual disk fail in turn , data can once again be reconstructed from still - functioning disks ( which may include the formerly - spare disk ) and provided to host systems . a “ hot spare ” is a disk that is attached to a raid controller , and unused by existing configured virtual disks . when a disk containing part of data of a raid virtual disk fails , the “ hot spare ” may be substituted for the failed disk without requiring that a technician physically replace the failed disk . in some systems this replacement may require operator intervention , and in other systems a hot - spare may be substituted for a failed disk automatically . once a hot - spare is substituted into a raid dataset or virtual disk , data may be reconstructed onto the hot - spare — which becomes a formerly - spare disk and redundancy may be restored . typically , however , the hot - spare must be attached to the same raid controller as the failed drive . in an embodiment of the invention , a hot - spare 930 is provided on be_san 832 . should a physical disk drive associated with a raid virtual disk , such as disk 926 of raid virtual disk 958 , that is attached to the same be_san 932 , the hot - spare may be substituted for disk 926 of raid virtual disk 932 . consider a situation where a physical disk drive , such as drive 904 , attached to a different be_san , such as be_san 912 , is the physical hard disk that fails . in traditional raid systems , a hot - spare attached to a different raid controller than a failed drive is not accessible to replace that failed drive , and redundancy can not be restored until a technician replaces the failed drive . in the embodiment of the invention , as illustrated in fig9 and 10 , if no hot - spare is located on the same be_san 912 as the failed drive , such as drive 904 , forwarding code within raid code 970 intercepts communications typical of those addressed to a hot spare , including those required for reconstruction of data on the hot - spare as required to restore redundancy , and relays those communications through network 940 , and through a be_san , such as be_san 932 , that has a hot - spare , and to that hot - spare , such as hot spare 930 . while such operation may in some embodiments be slower than those where all physical drives associated with a raid mode 5 or 6 virtual disk are attached to the same be_san , this forwarding is sufficient to allow redundancy to be restored and permit reliable system operation until the system can be repaired . further , this forwarding permits operation of both non - raid and raid virtual disks , such as raid virtual disk 956 , that span physical hard drives associated with more than one be_san . in this embodiment of the invention , one hot - spare may be provided for two or more be_sans , and that hot - spare may be used to restore redundancy and reliable operation regardless of which single physical hard disk attached to any of the two or more be_sans has failed . further , the system may be configured to implement be_san - spanning virtual volumes , such that one or more physical disks drive associated with a virtual volume hosted by a first be_san , such as be_san 912 may be coupled instead to a second be_san , such as be_san 932 ; the first be_san 912 recognizes that a particular disk access to a particular logical block is to a physical sector on a drive on the second be_san 932 and relays communications over the network 940 and through the second be_san 932 , in a manner similar to that required for use of a drive on the second be_san as a hot - spare for a raid set hosted primarily by the first be_san . the foregoing description should not be taken as limiting the scope of the disclosure . it should thus be noted that the matter contained in the above description or shown in the accompanying drawings should be interpreted as illustrative and not in a limiting sense . the following claims are intended to cover generic and specific features described herein , as well as all statements of the scope of the present method and system .