US20090043971A1 - Data integrity for data storage devices shared by multiple hosts via a network - Google Patents
Data integrity for data storage devices shared by multiple hosts via a network Download PDFInfo
- Publication number
- US20090043971A1 US20090043971A1 US12/255,433 US25543308A US2009043971A1 US 20090043971 A1 US20090043971 A1 US 20090043971A1 US 25543308 A US25543308 A US 25543308A US 2009043971 A1 US2009043971 A1 US 2009043971A1
- Authority
- US
- United States
- Prior art keywords
- data
- storage device
- hosts
- file
- data storage
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
- G06F3/0659—Command handling arrangements, e.g. command buffers, queues, command scheduling
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/17—Details of further file system functions
- G06F16/176—Support for shared access to files; File sharing support
- G06F16/1767—Concurrency control, e.g. optimistic or pessimistic approaches
- G06F16/1774—Locking methods, e.g. locking methods for file systems allowing shared and concurrent access to files
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
- G06F3/0614—Improving the reliability of storage systems
- G06F3/0619—Improving the reliability of storage systems in relation to data integrity, e.g. data losses, bit errors
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0629—Configuration or reconfiguration of storage systems
- G06F3/0635—Configuration or reconfiguration of storage systems by changing the path, e.g. traffic rerouting, path reconfiguration
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
- G06F3/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
Definitions
- the invention relates generally to a data storage device shared by multiple hosts by way of a network. More specifically, the invention relates to efficient access by multiple hosts of a data storage device over a network while maintaining the data integrity of the storage device.
- hosts are electronic devices that employ data storage devices to store digital data for later retrieval and processing by the host.
- Hosts include, but are not limited to, computers (including desktop personal computers, laptop personal computers and workstations), personal digital assistants (PDAs), digital audio systems, digital television sets, television set-top boxes, digital game devices, smart phones, hand-held computers and other digital data processing devices.
- Data storage devices include, but are not limited to, hard disk drives, tape drives, flash memory units, and compact disc (CD) and digital versatile disc (DVD) drives.
- CD compact disc
- DVD digital versatile disc
- the data written to or read from a storage device may take any of a variety of forms, including, for example, numerical, textual, audio and video data.
- FIG. 1 depicts a typical hardware configuration for a computer system.
- a device controller 11 attached to a system bus 9 of a computer system enables data transfers between data devices 12 , 13 , and a CPU 3 and logic memory 4 .
- the device controller 11 may control one or more data storage devices.
- a data storage device is not shared among the hosts directly at device level. Instead, the storage device often resides within one of the hosts involved, while the remaining hosts communicate with the data storage device by way of the host containing the data device.
- communication between the hosts occurs via a network file system.
- a file system for example, the NT File System (NTFS) employed by Microsoft Windows®
- NTFS NT File System
- a network file system is the portion of an operating system responsible for the storage and tracking of files
- maintaining a stable state in such a system requires that all file write operations by one host, including the writing of any file directory information and other file “meta-data,” be allowed to complete prior to allowing access by another host.
- Sharing a storage device directly at the device level through a network provides certain advantages over indirect sharing of the storage device via network file systems.
- Direct sharing tends to be more efficient in terms of latency and access times.
- Direct sharing is more cost effective because less expensive hardware, in the form of a network device controller may be used instead of an entire computer system, which allows direct connection of each storage device via a network. No additional operating system or file system software is required, which also eliminates the file system dependency problems and limitations identified above.
- sharing a data storage device over a network presents unique challenges compared to, for example, those involved with sharing a network printer.
- a network printer is often shared by more than two host computers, but the nature of the data being transferred over the network necessitates the two situations be treated differently.
- Print commands from computers to network printers apply only to complete files. As a result, all commands issued to a network printer are guaranteed to be serialized at the file level so that no overlapped or interleaved files may be printed. In other words, a file in the shared network printer environment cannot be divided into smaller portions to be interleaved with portions of other files to be printed.
- files intended for a data storage device such as a hard disk drive
- files intended for a data storage device are ultimately translated into one or more physical sectors of the data device by way of file system software.
- file system software no guarantee exists that the file will not occupy several discontinuous series of sectors on the data storage device. Therefore, different files from various hosts sharing the storage device may possibly be mapped onto overlapping sectors unless the file systems of the hosts cooperate in some manner.
- embodiments of the present invention allow read and/or write access by multiple hosts, such as computers or other information appliances, to a data storage device by way of a network while maintaining the data integrity of the data storage device.
- a method for accessing the data storage device provides, in part, acquiring a resource lock, which provides exclusive access to one of the multiple hosts at a time. The host holding the lock may then directly access the storage device without interference from the other hosts. After accessing the storage device, the accessing host releases the lock on that storage device so that other hosts may then be allowed to access the storage device.
- the lock may be implemented entirely in software, hardware, or a combination thereof. In one embodiment, the lock is implemented within the data storage device, and the data storage device accepts and executes lock access commands issued by the multiple hosts.
- a networked system which includes a data storage device and a plurality of hosts coupled to the storage device by way of a digital network.
- a resource lock is included which provides exclusive access to the data storage device to one of the plurality of hosts at a time.
- Digital networks employable for coupling the data storage device with the multiple hosts include, but are not restricted to, a local area network such as Ethernet (LAN), a wide area network (WAN), the Internet, a virtual private network (VPN), and any other digital network.
- a networked system with a data storage device shared by a plurality of hosts over a network utilizes a file system providing a “check out” attribute for each cluster of free blocks available for file storage.
- a host attempting to claim a cluster of free blocks analyzes the associated check out attribute to determine if another host has already claimed the cluster. If not, the host sets the check out attribute with a value indicating that it has claimed the cluster, thereby providing the host exclusive access to the cluster.
- a resource lock may be employed to protect the access to the check out attribute.
- Mutually exclusive access to other file system data structures may be provided in a similar fashion.
- a first host has exclusive direct access to a data storage device, which is accessed by way of the host's local file system over a digital network.
- a second host requiring access to the data storage device communicates with the first host by way of the digital network.
- File access requests generated by the second host are redirected away from its own local file system to the first host by a redirection filter driver.
- the first host maintains direct access to the storage device while the second host communicates with the device through the first host's file system.
- the first and second hosts each include a file network system for transferring file access requests from the second to the first host.
- each of the first and second hosts employ a network connection (such as a socket connection program) to allow the second host to issue file access requests through the first host.
- FIG. 1 depicts a block diagram of a typical data storage device connection within a computer system.
- FIG. 2 depicts a block diagram of a computer network connecting multiple host computers with a data storage device at the device level.
- FIG. 3 depicts a block diagram of a typical data abstraction hierarchy of a computer system wherein each layer of the hierarchy provides a different view of a file.
- FIG. 4 depicts a block diagram describing a file access process of a typical computer system employing the data abstraction hierarchy of FIG. 3 .
- FIG. 5 depicts a flow diagram describing a typical file read or write operation.
- FIG. 6 depicts a flow diagram of a file write operation according to an embodiment of the invention employing a network of multiple hosts sharing a data storage device and a resource lock.
- FIG. 7 depicts a flow diagram of a file read operation according to the embodiment of the invention associated with FIG. 6 .
- FIG. 8 depicts a typical logical view of a conventional file system on a data storage device.
- FIG. 9 depicts a logical view of a Microsoft Windows® NTFS partition.
- FIG. 10 depicts a typical network of hosts that share a data storage device directly at the device level.
- FIG. 11 depicts a free block list of a file system according to an embodiment of the invention.
- FIG. 12 depicts a process of accessing a root directory in a conventional file system.
- FIG. 13 depicts a process of accessing multiple root directories of a file system according to an embodiment of the invention.
- FIG. 14A depicts an example of a first partial directory structure of a file system according to an embodiment of the invention.
- FIG. 14B depicts an example of a second partial directory structure of a file system according to an embodiment of the invention.
- FIG. 14C depicts an example of a third partial directory structure of a file system according to an embodiment of the invention.
- FIG. 15 depicts the entire directory structure of the examples in FIGS. 14A , 14 B and 14 C.
- FIG. 16 depicts a system employing multiple data storage devices using a file system according to an embodiment of the invention.
- FIG. 17 depicts a block diagram of a networked system according to an embodiment of the invention maintaining the data integrity of a data storage device shared by multiple hosts by way of network file systems.
- FIG. 18 depicts a block diagram of a networked system according to an embodiment of the invention maintaining the data integrity of a data storage device shared by multiple hosts by way of network connection programs.
- One embodiment of the invention allows direct connection of one or more hosts to one or more data storage devices, as illustrated in FIG. 2 .
- a direct connection between a first host 10 and a data storage device (or subsystem) 20 over a network, such as a LAN 50 , (and also between a second host 30 and a third host 40 , and the data storage device 20 ) may permit the hosts 10 , 30 , 40 to access the storage device without requiring a server to manage such access.
- a direct connection allows the hosts to circumvent the use of a network file system, as described above, and access the data storage device at a lower, more efficient level of abstraction.
- each host 10 , 30 , 40 normally includes a system bus 21 , 22 , 23 , respectively, with a central processing unit (CPU) 51 , 52 , 53 and logical memory 54 , 55 , 56 , coupled with the network device controller 31 , 32 , 33 , to communicate with the storage device 20 .
- CPU central processing unit
- FIG. 3 provides a graphical representation of the various levels of abstraction by which data stored on a data storage device may be viewed.
- a user process 100 e.g., a user application, an assembly language program, an operating system daemon, or the like
- a host computer accessing the storage device 103 , which refers to a file 201 by a file name (such as “MyFile” in FIG. 3 ), the file 201 being viewed as a sequence of bytes of arbitrary length.
- a file system 101 of the computer system views that same data as a collection of data sectors 204 within a linear array of “logical sectors” or “blocks” 202 , the blocks 202 of the array typically being numbered from zero up to some maximum sector number.
- a software device driver (usually including a computer program having instructions to operate or control the storage device 103 ), in conjunction with an input/output system 102 may view the data of the file in a fashion closer to its actual physical configuration 203 , or layout, within the data storage device 103 .
- an input/output system such as the Basic Input/Output System, or “BIOS,” of a personal computer, translates operating system calls for access to a data storage device into a form understandable by that device.
- BIOS Basic Input/Output System
- the input/output system 102 may recognize the file as a set of data sectors arranged across one or more disk surfaces, or “platters.” Further, each platter is then normally divided into several tracks, or “cylinders,” which in turn are typically divided into multiple physical sectors. In many hard disk drives, each logical block 202 corresponds to a physical sector of the drive.
- Most host computer systems also utilize a data buffer, or “cache,” normally implemented inside the main logical memory of the computer system and logically residing within the data hierarchy between the file system 101 and the input/output system 102 .
- the buffer is usually employed to increase system performance by saving a copy of a portion of often-used (or recently used) data stored on the data storage device 103 for future computer CPU or main memory accesses to shorten the time required to access that data. Due to the limited size of the buffer compared to the data storage device 103 , the buffer typically is able to hold only a small percentage of the total amount of data residing in the data storage device 103 at any given time.
- FIG. 4 depicts a buffer system 105 placed within the data access hierarchy of FIG. 3 .
- Shown within the buffer 105 is a copy 106 of a portion of user data 108 residing in the data storage device 103 .
- the copy 106 is valid (e.g., the copy 106 exactly matches the contents of the corresponding data 108 in the data storage device 103 )
- all requests to access the corresponding data 108 of the data storage device 103 will instead access the copy 106 in the buffer 105 without directly accessing the data 108 resident on the device 103 .
- user data 106 is read from the buffer 105 instead of the data storage device 103 if the user data 106 in the buffer 105 is valid.
- all user data to be written to the data storage device 103 will be copied into either a free space of the buffer 105 , or into an area of the buffer 105 holding a copy of that data.
- the physical sectors holding the user data 108 of the data storage device 103 are written from the copy 106 in the buffer 105 at a later time, depending on the particular buffer flushing strategy employed.
- the details of various caching and flushing strategies are well-known in the art, and are not critical to the various embodiments of the invention described herein.
- the buffer 105 also normally maintains a cache of meta-data 107 corresponding to and describing the copy 106 of user data.
- Meta-data such as file descriptors, are data necessary for mapping portions of files 201 to blocks 202 for proper storage and retrieval of file data.
- Meta-data may include, for example, a file's length and physical location on a data storage device 103 . This information is stored on physical sectors of the data storage device 103 as meta-data 109 associated with the data storage device 103 .
- additional mapping information 110 such as certain file directories found in the data storage device 103 , may also be cached as meta-data in various data structures of the file system 101 itself.
- FIG. 5 shows a generalized method of reading or writing data files (or portions thereof normally employed by a single host directly connected to a single data storage device, using the data hierarchy of FIG. 4 .
- the file system 101 receives a file read or write request from a user process 100 .
- the file system 101 attempts to access a copy 107 of the meta-data in the buffer 105 that contains the mapping information describing the translation from the file 201 to the corresponding blocks 202 .
- the system determines whether the copy 107 of the meta-data stored in the buffer 105 is valid. If the meta-data 107 is valid, operation 305 is executed.
- the input/output system 102 executes operation 304 and converts the location of the blocks 202 of the required meta-data into the corresponding location of physical sectors 203 of the data storage device 103 , reads the corresponding meta-data 109 from the physical sectors 203 of the data storage device 103 , and copies the meta-data 109 into the buffer 105 , resulting in a valid copy 107 of the meta-data in the buffer 105 .
- the file system 101 may perform operation 303 once again to ensure the meta-data 107 in buffer 105 is valid.
- the file system 101 In operation 305 , with a valid copy 107 of the meta-data now available in the buffer 105 , the file system 101 reads the copy 107 . Continuing with operation 306 , the file system 101 determines whether the requested data access requires a read or write of file data. In the case of a read operation, operation 307 is executed, in which the file system 101 determines the proper blocks 202 of the actual user data desired and attempts to access a valid copy 106 of the user data in the buffer 105 . In operation 308 , the file system 101 determines if the copy 106 of user data is not valid or is nonexistent in the buffer 105 .
- operation 309 is performed, in which the input/output system 102 converts the location of the blocks 202 holding that data into the corresponding location of physical sectors 203 of the data storage device 103 , reads the user data 108 from the physical sectors 203 of the data storage device 103 , and copies the user data 108 into the buffer 105 , resulting in a valid copy 106 of the user data in the buffer 105 .
- Operation 308 then may be executed once again to ensure the copy 106 of the user data in the buffer 105 is valid.
- the file system 101 then reads the copy 106 of the user data from the buffer 105 , thus completing the read request from the user process 100 .
- operation 311 is executed, in which the file system 101 uses the copy 107 of meta-data previously read from the buffer 105 in operation 305 and transfers the user data 106 and associated meta-data 107 to be written to an appropriate location in the buffer 105 , thus making those portions of the buffer 105 valid.
- operation 312 is performed, in which the user data 106 and associated meta-data 107 in the buffer 105 are written to the data storage device 103 as user data 108 and meta-data 109 by way of the input/output system 102 , thereby completing the write operation.
- allowing multiple hosts concurrent direct access to the data storage device 103 may cause data integrity problems in both the meta-data 109 and the file data 108 located on the data storage device 103 , as well as any copies 106 , 107 of that data in a buffer 105 of each host.
- one host 10 might be in the process of updating a preexisting file resident on a storage device 20 by way of multiple write operations.
- a second host 30 may read the same file from the data storage device 103 , thus receiving an intermediate and incorrect copy of the file.
- each host may accessing copies 106 , 107 of meta-data and file data from its own buffer 105 , updates to those copies 106 , 107 will not be seen by other hosts until that information is flushed from the buffer 105 and written to the data storage device 103 . Accordingly, each host may be attempting to update the same data file in different ways, completely unaware that multiple, dissimilar copies of the same file exist, thus destroying the data integrity of that file.
- one embodiment of the invention involves the use of a resource “lock” to prevent access to the data storage device 103 at the device level by more than one host at any particular time.
- the lock is acquired by a host attempting access the storage device, including any reading or writing of a data file to the device 103 , and is released after the access operation has been completed.
- completion of a write command would include the host in possession of the lock flushing the contents of its buffer 105 , thus ensuring the meta-data and file data of the data storage device 103 has been updated. Only one host may possess the lock at any one time, thereby prohibiting access to the data storage device by any other host.
- the lock may also be implemented as a “semaphore” or similar construct known in the art.
- a semaphore is a flag or similar indicator that is writable and readable by one or more hosts, and is used to relay a simple message between those hosts.
- the lock itself may be implemented in several different ways.
- the lock may be implemented entirely in software (such as device driver or network protocol), although hardware implementations are possible as well, as are hybrid hardware/software implementations.
- the data storage device 103 itself may internally store the value of the lock for access by each of the hosts using the device 103 . All access and manipulation of the lock by the host would then be controlled, for example, by a device-level controller within or operably connected to the data storage device 103 .
- the device-level controller may process standard device-level commands normally targeted for a data storage device, such as the commands associated with the Small Computer Systems Interface (SCSI) or Integrated Drive Electronics (IDE) interfaces known in the art.
- SCSI Small Computer Systems Interface
- IDE Integrated Drive Electronics
- a device-level controller is implemented by way of an embedded microcontroller system designed and employed to perform tasks specific to the control and maintenance of the associated data storage device, including the processing of device-level commands, as described above.
- an embedded microcontroller system designed and employed to perform tasks specific to the control and maintenance of the associated data storage device, including the processing of device-level commands, as described above.
- such a system employs resources, in terms of algorithmic capability, speed and logical memory, minimally sufficient to perform its assigned duties in terms of data storage device control, but not to implement commands beyond device control. (For example, the microcontroller may respond to device-level command, but would not implement and run an operating system.)
- the term “computer,” as is generally employed in the art does not embrace a device-level controller of the embodiments of the present invention.
- the data storage device 103 may provide lock control and access for the hosts by way of lock-specific commands that facilitate the checking and setting of the lock.
- the data storage device 103 may provide an “acquire lock” command that provides both a checking and setting of the lock in one operation.
- the data storage device 103 will return a failure indication to the requesting host. Otherwise, a success indication can be returned, indicating to the requesting host that the lock acquisition was successful, in which case the requesting host may proceed with accessing data on the data storage device 103 .
- the requesting host may be able to specify a timeout period as a parameter of the acquire lock command so that the data storage device 103 attempts to acquire the lock for the requesting host for the timeout period if the lock is held by another host before returning a failure indication.
- the data storage device 103 would also support a “release lock” command to allow the host holding the lock to allow access by the other hosts.
- a network device controller 34 as shown in FIG. 2 , may implement the locking mechanism instead of the data storage device 103 of FIGS. 3 and 4 .
- the lock may be implemented by one of the hosts accessing the data storage device 103 . Other hosts would then access the lock by making requests via the network to the host implementing the lock.
- responsibility for maintaining the lock may be distributed among all or some subset of the hosts involved, with each host possessing a local copy of the state of the lock, including the identity of the host currently in possession of the lock. In that particular case, care must be taken to ensure that each of the hosts maintains a current copy of the state of the lock.
- FIG. 6 generally shows the steps of a write operation of a file according to an embodiment of the invention employing a resource lock to enhance the data integrity of the file being written.
- operation 401 is first executed, in which the user process 100 issues a file write request to the file system 101 .
- the file system 101 first acquires the lock before initiating the actual write operation.
- acquisition of the lock may be delayed if another host is already in possession of the lock.
- the requesting host may “time out” if the lock has not been acquired within a predetermined period of time, thus allowing the host to complete other tasks before attempting to acquire the lock once again.
- the file system 101 may intermittently check for the lock explicitly, or such an intermittent check may be performed automatically by another software routine. Alternately, the file system may place a request for the lock, and then be interrupted by another software routine when the lock becomes available.
- operation 403 is performed, in which the file system 101 checks for a valid copy 107 of the meta-data in the buffer 105 .
- the file system 101 may assume beforehand that the meta-data 107 in the buffer 105 is invalid if the previous lock holder was another host, thereby circumventing an exhaustive check of the buffer 105 .
- an identification of the last host to hold the lock may also be implemented in conjunction with the lock itself. For example, a host may write a specific file system data structure on the data storage device 103 after acquiring a lock indicating it is the most recent holder of the lock.
- operation 404 is executed, in which the corresponding meta-data 109 is read from the data storage device 103 (i.e., the data storage device 103 ) using the input/output system 102 . Otherwise, the file system 101 may proceed to operation 405 . Once operation 404 is complete, the file system 101 may again check if validity of the meta-data in the buffer 105 is valid in operation 403 .
- operation 405 is performed, in which the file system 101 reads that copy 107 of the meta-data, translates the information for the file 201 into a set of blocks 202 containing the desired user data, and then writes the new data into the proper location in the buffer 105 .
- the meta-data is updated based on any changes necessary due to the new user data to be written.
- the file system 101 determines in operation 406 if the host will hold the lock after the write operation. If not, in operation 408 the host flushes all file data and meta-data in the buffer 105 to the data storage device 103 using the input/output system 102 to perform the logical-to-physical sector translation before it releases the lock in operation 409 . If the host holds the lock, the host then determines in operation 407 if another write request is pending. If so, the write procedure resumes by returning to operation 403 . If there is no pending write request, the host determines if it will still hold the lock in operation 406 based on other criteria, such as anticipated near-term data storage device access requirements.
- the lock mechanism prevents multiple hosts from simultaneously or concurrently writing to the data storage device 103 by allowing only one host at any time to hold the lock for writing operations. Accordingly, the writing by any host holding a lock is likely valid, because all previous write operations to the shared data storage device 103 by other hosts are fully recorded by flushing all user data 106 and meta-data 107 from the buffer 105 to the data storage device 103 before another host can acquire a lock.
- all hosts connected to the data storage device 103 may cooperate to time-share access to the data storage device 103 by allocating a limited lock hold time to each host, thus preventing monopolization of the lock by any single host.
- the limited hold time may be invariant (for example, ten seconds per host), prioritized by host (for example, host A has a ten second lock while host B has a five second lock), or varying with some other parameter (for example, larger files may permit longer locks, lock duration may be determined by data throughput speed of the storage device and the host, and so forth).
- FIG. 7 illustrates the process flow of a read operation, according to another embodiment of the invention, utilizing a lock to guarantee the file data read is consistent with the data resident on the data storage device 103 .
- the file system receives a read request from a user process 100 .
- the file system 101 acquires a lock before initiating a read operation.
- operation 503 is executed, in which the file system 101 determines if the copy 107 of meta-data and other mapping information is present and valid in the buffer 105 . If not, in operation 504 the file system 101 reads the corresponding meta-data 109 from the data storage device 103 by way of the input/output system 102 into the buffer 105 .
- the file system 101 may then return to operation 503 to ensure the validity of the meta-data 107 in the buffer 105 .
- the file system 101 reads the copy 107 of the valid meta-data from the buffer 105 , performs a translation from the name of the file 201 to a set of blocks 202 , and searches the buffer 105 for a valid copy 106 of the file data corresponding to the blocks 202 . If a copy 106 of the file data is not in the buffer 105 , or such a copy is not valid, the file system 101 performs operation 506 , in which the file data 108 is read from the data storage device 103 .
- the file system 101 may return to operation 505 to ensure the validity of the file data 106 in the buffer 105 .
- the file system 101 executes operation 507 and completes the read request by obtaining the data copy 106 from the buffer 105 , before releasing the lock in operation 508 . Since the file system 101 has not written any meta-data or file data to the buffer 105 , flushing the buffer prior to releasing the lock is not required, as was the case during the write operation described in FIG. 6 .
- the file system 101 may retain the lock to execute further read or write operations prior to releasing the lock.
- the reading procedures of FIG. 7 may be performed while bypassing the procedures of acquiring and releasing the lock (steps 502 , 508 ) if the meta-data 109 and file data 108 are read directly from the data storage device 103 instead of the buffer 105 . If so, any problems with the contents of the buffer 105 remaining consistent with the data storage device 103 are eliminated.
- the data read by a host that has not acquired a lock may be in a partially-modified state if another host holding the lock is in the process of writing the same file to the data storage device 103 .
- the adequacy of reading data without performing the locking and unlocking operations may be determined by whether data that has been partially-modified is acceptable for host use.
- a time-share lock scheme may be implement for the read operation of FIG. 7 , as presented above in the discussion of FIG. 6 .
- the write and read operations shown in FIG. 6 and FIG. 7 can be implemented by adding filter driver software atop the existing file system 101 without modifying the existing file system or adding an extra file system.
- the filter driver may be layered into or atop the file and/or operating systems.
- the filter driver software intercepts the read and write requests to the existing file system software 101 before it acquires the lock.
- the filter driver software may verify the validity of the meta-data 107 and user data 106 in the buffer system 105 before it notifies the file system 101 about the validity, as well as perform the locking and unlocking procedure.
- the data integrity of a data storage device shared among multiple hosts over a network at the device level is maintained by a set of features or data structures provided by the file systems of the hosts. These structures provide a mechanism by which free blocks (i.e., blocks not currently written with valid user data or meta-data) of the data storage device are allocated to each host in a mutually exclusive manner. Considering this particular embodiment of the invention involves enhancements to the typical file system currently available, a more detailed discussion of file systems and their operation is provided.
- a file system which typically is the largest unit of data structure identified with a persistent data storage device, normally includes a collection of files, file descriptors, directories and other file-system-related information.
- the file system is stored on a “logical disk,” which can be a physical disk (e.g., a hard disk drive), a disk partition (i.e., some identified portion of a physical disk), several physical disks, or some other physical manifestation of a data storage device. From the file system's standpoint, a logical disk is composed of a large, one-dimensional array of logical blocks, as described above.
- FIG. 8 presents an example disk block layout of a file system.
- the first block is reserved for a boot block 601 , which is the first disk block read by a computer system to determine where on the disk to retrieve the operating system and other necessary information to initialize the computer after a reset has occurred.
- a file system descriptor 602 (often called a “super block” in the UNIX operating system) contains information about the file system as a whole, since the file system is viewed as an object or entity in and of itself, and thus requires a data structure to represent it.
- the file system descriptor 602 defines the total size of the file system in blocks, the size of the file descriptor area, the location of the root directory (i.e., the top directory in a hierarchically-arranged file structure), and other file system meta-data.
- One other important item of information defined in the file system descriptor 602 is the first block of the free block list.
- File descriptors 603 (often called “inodes” in UNIX) contain all meta-data associated with a particular file, including the actual block addresses on the data storage device where the file data is located. Other meta-data in the file descriptors 603 normally include the owner of the file, file protection information, time of creation, time of last modification, time of last use, and other information related to the specific file.
- directories which essentially are logical collections of files and other directories, are actually implemented as files, so each directory will have a file descriptor in the file descriptor area and occupy some data blocks in the data block area 604 . In other words, no special areas of the storage device are reserved within the file system for directories.
- some plurality of the data blocks on a data storage device are allocated or occupied by file data and file descriptors, while some blocks remain unallocated, or “free.” All allocated blocks are linked to a file descriptor so that file data can be traced by starting with the corresponding file descriptor. As files grow, more free blocks are allocated to the files as necessary. Accordingly, file systems typically maintain a list of free blocks for quick allocation of those blocks to files.
- FIG. 8 shows a logical view of a typical file system.
- the actual locations of each entity depicted may be allocated across the entire allotment of disk blocks.
- the file descriptors may be located in any of a number of areas on the disk, as they may be positioned with the file names in the directories, in a special area of the disk reserved for file descriptors, or among the disk blocks containing the actual file data.
- FIG. 9 depicts a logical view of a partition of the Microsoft Windows® NT File System (NTFS), in which information on the file system itself and the starting block number of the Master File Table (MFT) 606 is stored in a boot sector 605 .
- NTFS Microsoft Windows® NT File System
- MFT Master File Table
- the Master File Table 606 holds meta-data concerning every other file and directory contained in the file data blocks 607 of the NTFS partition.
- the Master File Table 606 also contains sixteen entries, or records, reserved for various special meta-data files, including a free block list.
- FIG. 10 shows an exemplary system of multiple host computers 610 , 611 , 612 sharing a single shared data storage device 630 over a network 620 directly at the device level, while relying solely on the local file systems of the hosts 610 , 611 , 612 to manage the storage device 630 .
- Sharing a hard disk drive or other data storage device directly at the device level is distinguished from sharing a storage device by multiple hosts indirectly via a separate server through a distributed file system by way of the data integrity support provided by a distributed file system. Direct accessing of a remote hard disk drive by one or more computing devices is discussed in U.S. Provisional Application Ser. No. 60/592,722, entitled “Low-Level Communication Layers and Device Employing Same,” incorporated by reference herein in its entirety.
- some distributed file systems such as xFS (“x” File System) and GFS (Global File System) utilize a server for managing the meta-data of the file system, including the free block list.
- Each client host consults the server before the client acquires free blocks for writing a file.
- the server allocates free blocks, but does not control actual data written to the storage device.
- This mechanism allows the clients to write and read data blocks onto and from the data storage device directly without relaying the user data to and from the server.
- this mechanism does not allow the hosts to share the storage device directly at the device level without server intervention.
- the server since only the server controls the allocation of free blocks, and each client host must consult the server to obtain free blocks, the file system cannot be corrupted on the basis of allocating free blocks to multiple clients.
- the total number of free blocks may be divided into multiple, mutually exclusive sets of free blocks, with each set being accessible to only one particular host at a time.
- FIG. 11 shows a logical view of a list of free blocks according to various embodiments of the invention.
- entries of free blocks are maintained as a form of “bitmap,” wherein each bit represents a cluster on the physical disk, thus identifying whether the cluster is free or has been allocated to a file.
- each free block cluster is associated with a “check out” attribute 624 , 625 , 626 , 627 .
- Each host computer can check out the mutually exclusive free block clusters only when the clusters are not currently checked out by another host.
- the host is responsible for setting the check out attribute 624 , 625 , 626 , 627 for each claimed cluster using its host ID.
- some embodiments may employ a resource lock (as described above) in the course of setting the check out attribute 624 , 625 , 626 , 627 to prevent a race condition among hosts contending for the same free blocks.
- the host may allocate to a file any of the free blocks from the free block clusters that have been checked out since those blocks are reserved exclusively for the use of the host by way of the check out process, thus preventing any other host from checking out those same blocks.
- Any checked out blocks not ultimately allocated to a file are subsequently returned by the accessing host to the free block list.
- the host inserts new nodes of free block clusters into the free block list and leaves the check out attribute 624 , 625 , 626 , 627 of the newly inserted cluster nodes blank.
- the accessing host In addition to setting the check out attribute, the accessing host also sets a timestamp attribute 628 , 629 , 630 , 631 with a value indicating when the free blocks were checked out.
- the timestamp 628 , 629 , 630 , 631 is employed to prevent a host from holding unallocated free blocks indefinitely. This situation can occur, for example, when a host has checked out one or more clusters of free blocks and then becomes inoperative, or “crashes,” before the host has the opportunity to return the unallocated blocks to the free block list. If the timestamp 628 , 629 , 630 , 631 is older than some predetermined value, other hosts may then claim the unallocated blocks from the outdated cluster of free blocks using the standard check out procedure.
- the first cluster of free blocks denoted by entry 620 is checked out to a host i with a timestamp value 628 of t 1
- the second cluster indicated by entry 621 is checked out to a host j with a timestamp value 629 of t 2 .
- the other clusters denoted by the entries 622 , 623 shown are not checked out, and thus remain available to any host.
- the file system stores within its file system descriptor the location of the file descriptor of the root directory. As the root directory and subdirectories accumulate files and other directories, links are provided within each directory pointing to block locations in the file data block area where the files and file descriptors associated with the directory are stored. Therefore, the file system can trace the entirety of the directory structure starting from the root directory.
- FIG. 12 illustrates how a directory structure is implemented in an exemplary conventional local file system.
- the file system may follow a link 642 from its file system descriptor 640 to the location of the file descriptor 644 of the root directory, which in turn contains another link 646 indicating the location of additional data 648 associated with the root directory.
- a separate set of file descriptors for the root directory are provided for each host that shares the device, in contrast to the single set of file descriptors normally employed.
- FIG. 13 illustrates one possible implementation of multiple file descriptors for the root directory, one for each host that shares a data storage device.
- the file system descriptor 650 contains a link 652 to a set of root directory file descriptors 654 , 656 , 658 , each of which is the file descriptor of the root directory for each of three hosts sharing the device.
- the host When a host accesses the file system to view the directory structure, the host peruses the entire directory structure by following the links to the corresponding file descriptors and data starting from the complete set of root directory file descriptors 654 , 656 , 658 allocated to the hosts.
- the links 652 in the file system descriptor 650 point to three root directory file descriptors 654 , 656 , 658 , each of which corresponds to one of the three hosts.
- each of the root directory file descriptors 654 , 656 , 658 points to the corresponding data blocks 660 , 662 , 664 for storing directory information for each of the three hosts, respectively.
- Host 1 creates a directory “dir A” under the root directory, and creates a file “file A 1 ” under the “dir A” directory, as depicted in FIG. 14A .
- Host 1 stores information necessary for the directory structure it created in the blocks allocated for its root directory file descriptor 654 and associated data blocks 660 , as shown in FIG. 13 .
- Host 2 creates its own directory “dir B” under the root directory, and creates a file “file B 1 ” under “dir B,” using its root directory file descriptor 656 and data blocks 662 .
- Host 2 then creates another file “file B 2 ” under “dir A” originally created by Host 1 , employing information in the root directory file descriptor 654 and data blocks 660 created by Host 1 .
- Host 3 creates its own directories “dir C 1 ” and “dir C 2 ” under the root directory and “dir A” by employing its root directory file descriptor 658 and data blocks 664 .
- Host 3 then creates files, “file C 1 ” and “file C 2 ” under “dir A” and “dir C 1 ”, respectively.
- any host can read directory structures created by other hosts in order to obtain a complete view of the entire directory structure by following the links starting from the root directory file descriptors allocated for the hosts involved.
- any host can create its own files under directories created by other hosts.
- each of the directory structures created by each host can be retrieved by following the links starting from the root directory file descriptor allocated for the corresponding host.
- the directory structure created by each host constitutes a portion of the total directory structure of the entire file system.
- the total directory structure may thus be obtained by superimposing the partial directory structures created by each of the hosts.
- FIG. 15 depicts the total directory structure of the data storage device by superimposing the three partial directory structures created by the three hosts, as shown in FIGS. 14A , 14 B and 14 C.
- the file system maintains attributes of a file, as well as the file data itself, to represent related information necessary for management of the file.
- One such attribute in one embodiment indicates ownership of the file.
- the file system may maintain an “ownership” attribute within the meta-data of each file to distinguish which host maintains ownership of the file. This host identification prevents a host from exercising impertinent access rights to files owned by other hosts.
- Another file attribute in another embodiment of the invention is a “check out” attribute of a file, which is distinguished from the “check out” attribute associated with each free block cluster, described in detail above.
- the file system marks the check out attribute of the file with an identification of the accessing host. At that point, other hosts may not check out the file with write permission. This mechanism prevents more than one host from writing the same file at the same time, which would likely corrupt the data in the file. However, in some embodiments hosts may read a file that is currently checked out by another host holding write permission.
- the file system may require a host to acquire a resource lock before it can check out the file in order to prevent race conditions created by multiple hosts vying to check out the same file.
- a host may require a host to acquire a resource lock before it can check out the file in order to prevent race conditions created by multiple hosts vying to check out the same file.
- use of a resource lock can be avoided. For example, some video and audio data files may remain viable even if the data integrity of the files has been compromised to a degree.
- a file system generally maintains files containing information for effective handling of the blocks of the storage device on which the file system is implemented. These files are termed “file system files.” Typically, two of these files are the free block file and the bad block file.
- the free block file contains a list of blocks that are free, and possibly a complementary list of blocks that are written.
- the bad block file contains a list of “bad,” or defective, blocks on which no data can be written to or read from correctly, generally due to defective portions of the recordable medium within the data storage device.
- Conventional file systems have a single host manage those particular file system files.
- each host of a multiple-host system accesses the free block file in a mutually exclusive manner by way of the cluster check out attribute, as described in detail earlier.
- resource lock acquisition may be required prior to setting the check out attribute in some embodiments, thereby providing additional data integrity for the free block file.
- Access to the bad block file may be regulated in a similar fashion so that hosts may add bad blocks to the bad block list in a secure manner as they are encountered in the course of disk operation. Further, the same control mechanism may be applied to maintain the data integrity of any file system files.
- the use of multiple hosts sharing a single data storage device would produce the possibility of file name conflicts among files created by the multiple hosts. For example, if the hosts run the same operating system and use default swap files set automatically by the operating system, two or more swap files associated with different hosts could have the same file name under the same directory. However, in embodiments of the invention, the host ownership attribute (described above) may be utilized to distinguish such files.
- FIG. 16 presents a data storage system 670 containing multiple data storage devices 671 , 672 , 673 (such as hard disk drives) with controller logic 674 .
- the controller logic 674 oversees all three data storage devices 671 , 672 , 673 and collectively treats the devices 671 , 672 , 673 as an array of disk blocks of a larger data storage device, thus providing a view of a single data storage device to the hosts that share the system 670 .
- multiple data storage device partitions of one or more physical storage devices may be presented in a similar manner.
- the controller logic 674 may be implemented as hardware, software, or some combination thereof. In one embodiment, a combination of hardware and software could be employed to process device-level commands for each of the data storage devices 671 , 672 , 673 , such as the device-level controller discussed earlier. (For example, the aforementioned device-level controller may implement, or serve as an example of, the controller logic 674 .) Alternatively, the controller logic 674 may be a software driver executed by a microcontroller system capable of transforming and/or relaying device-level commands received from a host to one of the data storage devices 671 , 672 , 673 .
- the driver may determine which of the three storage devices 671 , 672 , 673 is the target of the command received and performs any block location translation necessary from the addressing scheme utilized by the host to the scheme employed by the particular storage device 671 , 672 , 673 . The driver would then relay the modified command to the appropriate target storage device 671 , 672 , 673 , which is capable of processing the modified command itself.
- data integrity of a system of multiple hosts sharing a data storage device can be maintained by utilizing file systems already existing in current hosts. More specifically, instead of allowing all hosts to share a data storage device directly at the device level over a network, one host may have access to the data storage device at device level over a network, while all other hosts are allowed indirect access to the data storage device via their network file systems.
- FIG. 17 shows an alternative embodiment where only a first host 701 is allowed to mount a networked data storage device 742 (such as a hard disk drive) by way of a network device controller 741 with full read/write privileges onto one of its local file systems 706 . All other hosts requiring access to the data storage device 742 , such as a second host 702 , are not permitted to mount the networked data storage device 742 onto their own local file systems.
- a networked data storage device 742 such as a hard disk drive
- a redirection filter driver 700 resides at the interface between the user process and the file system of the second host 702 .
- the redirection filter driver 700 redirects all file access requests from a user process intended for the data storage device 742 toward a network file system 707 of the second host 702 .
- the redirection filter driver 700 presents the appearance of a local file system (shown as a functional local file system 705 in FIG. 17 ) to the user process as if the data storage device 742 were mounted onto the second host 702 .
- the network file system 707 of the second host 702 is connected by way of the LAN 750 with a network file system 708 of the first host 701 so that the file access requests directed toward the data storage device 742 generated in the second host 702 are routed to a local file system 706 of the first host 701 , onto which the data storage device 742 is actually mounted.
- Sharing the data storage device 742 between the first and second hosts 701 , 702 in this manner provides advantages over a system which employs indirect sharing of a data storage device strictly at the network file system level, as described earlier.
- the embodiment of FIG. 17 exploits features of the network file systems 707 , 708 in order to transmit file access requests and replies between the second host 702 and the data storage device 742 while maintaining data integrity, an additional network file system for the data storage device 742 is not required. Instead, the embodiment of FIG. 17 provides hosts a functional view of a local file system onto which the data storage device 742 appears to be directly mounted.
- the term “functional” refers to a duplication of the view that would be shown if the file were accessible on a local storage device, rather than across a network.
- the data storage device 742 and its files are handled in exactly the same fashion as actual local data storage devices and files. Due to the operation of the redirection filter driver 700 , the hosts exhibiting a functional local file system view cannot distinguish the data storage device 742 shared over the network from the devices actually mounted on their own conventional local file systems. Accordingly, since the files on the data storage device 742 are not viewed as shared through conventional network file systems, but are instead viewed as stored by way of a local file system, file usage limits that would otherwise exist if the files were shared through conventional network file systems are eliminated.
- the network file system 708 of the first host 701 later receives a reply from the local file system 706 to be transferred to the network file system 707 of the second host 702
- the network file system 707 of the second host 702 directs the reply to the requesting user process through the redirection filter driver software 700 as though the reply were received from the functional local file system 705 .
- a network connection program may be utilized instead of a network file system to transfer requests and replies for file accesses involving a data storage device.
- FIG. 18 illustrates an alternative embodiment wherein only a first host 703 possesses direct access to a data storage device 742 , such as a hard disk drive, while other hosts, such as a second host 704 , may only access the data storage device 742 via the first host 703 .
- Each of the first and second hosts 703 , 704 employ a network connection program 710 , 709 for communication between the hosts 703 , 704 , respectively. No network file systems are required.
- a redirection filter driver 711 residing between a user process and the file system of the second host 704 , intercepts data storage device access requests from the user process and redirects the requests to the network connection 709 of the second host 704 .
- This network connection 709 then relays these requests to its counterpart network connection 710 of the first host 703 , which in turn directs the request to a local file system 706 of the first host 703 , onto which the networked data storage device 742 is mounted through a network device controller 741 .
- the redirection filter driver 711 operates to present a functional local file system 712 to a user process of the second host 704 , making the fact that the data storage device 742 is not mounted locally to the second host 704 transparent to the user process.
- the network connection 710 of the first host 703 When the network connection 710 of the first host 703 then receives a reply from the local file system 706 to be transferred to its counterpart network connection 709 of the second host 704 , the network connection 709 of the second host 704 directs the reply to the requesting user process through the redirection filter driver software 711 as if the reply were received from the functional local file system 712 .
- the network connections 709 , 710 can be any program that transfers requests and replies therebetween, such as a conventional socket program.
- Certain features of the invention described herein may be implemented as an additional layer in or atop the file and/or operating systems.
- the aforementioned filter driver software may be added to an existing file system without requiring modification of the file system.
- certain features of the invention may be implemented as an additional attribute of a storage device, storage device controller, or storage device file system/structure.
- the aforementioned check out attribute may augment a file system or structure to provide added functionality.
- the basic file system/structure may remain relatively unchanged. In other words, the basic functionality and features of the core file system, structure, operating system, and so forth remain unchanged by the invention, which provides added functionality.
Abstract
Description
- This application is a divisional patent application of U.S. patent application Ser. No. 10/951,474, filed Sep. 27, 2004 and entitled “Data Integrity for Data Storage Devices Shared by Multiple Hosts Via a Network;” which claims the benefit under 35 U.S.C. § 119(e) to U.S. Provisional Application No. 60/506,829, filed Sep. 26, 2003 and entitled “Device-Level Data Integrity Scheme for Data Devices Shared by Multiple Hosts through LAN;” and which claims the benefit under 35 U.S.C. § 119(e) to U.S. Provisional Application No. 60/590,722, filed Jul. 22, 2004 and entitled “Low-Level Communication Layers and Device Employing Same;” and which claims the benefit under 35 U.S.C. § 119(e) to U.S. Provisional Application No. 60/581,691, filed Jun. 21, 2004 and entitled “File System Features That Enable a Storage Device to Be Shared Directly by Multiple Hosts at Device Level;” the disclosures of which are hereby incorporated herein by reference in their entireties.
- a. Field of the Invention
- The invention relates generally to a data storage device shared by multiple hosts by way of a network. More specifically, the invention relates to efficient access by multiple hosts of a data storage device over a network while maintaining the data integrity of the storage device.
- b. Background of the Invention
- Generally, hosts, as referred to herein, are electronic devices that employ data storage devices to store digital data for later retrieval and processing by the host. Hosts include, but are not limited to, computers (including desktop personal computers, laptop personal computers and workstations), personal digital assistants (PDAs), digital audio systems, digital television sets, television set-top boxes, digital game devices, smart phones, hand-held computers and other digital data processing devices. Data storage devices include, but are not limited to, hard disk drives, tape drives, flash memory units, and compact disc (CD) and digital versatile disc (DVD) drives. Further, the data written to or read from a storage device may take any of a variety of forms, including, for example, numerical, textual, audio and video data.
- Often, data storage devices are not connected directly with a host, but instead communicate with the host via an intermediate electronic device called a device controller, which couples a data storage device with a central processing unit (CPU) and/or logic memory of the host, thus providing a mechanism for transferring data therebetween. Generally, the host also employs its operating system (i.e., the software resident on a host that controls the overall operation of the host) to facilitate communication between the CPU and/or logic memory and the device controller. For example,
FIG. 1 depicts a typical hardware configuration for a computer system. Adevice controller 11 attached to asystem bus 9 of a computer system enables data transfers betweendata devices CPU 3 andlogic memory 4. As shown inFIG. 1 , thedevice controller 11 may control one or more data storage devices. - Generally, in situations in which a data storage device is to be shared between two or more hosts, the storage device is not shared among the hosts directly at device level. Instead, the storage device often resides within one of the hosts involved, while the remaining hosts communicate with the data storage device by way of the host containing the data device. Typically, communication between the hosts occurs via a network file system. In general, a file system (for example, the NT File System (NTFS) employed by Microsoft Windows®) is the portion of an operating system responsible for the storage and tracking of files, and a file system that cooperates with other file systems over a network is termed a network file system. Typically, maintaining a stable state in such a system requires that all file write operations by one host, including the writing of any file directory information and other file “meta-data,” be allowed to complete prior to allowing access by another host.
- However, in such a network a complete computer system or host providing a network file system is required for each data storage device added to the network, thus significantly increasing the cost of the system. More importantly, the multiple hosts possess a file system dependency when sharing data at the file system level, as all of the hosts involved must agree on a particular network file system protocol. Further, when a change in the network file system is required, that change must be implemented in all hosts involved. In addition, the usage of files remotely accessible through network file systems typically is limited compared to what is possible by way of direct access of the files from a data storage device, such as a hard disc drive.
- Sharing a storage device directly at the device level through a network provides certain advantages over indirect sharing of the storage device via network file systems. Direct sharing tends to be more efficient in terms of latency and access times. Direct sharing is more cost effective because less expensive hardware, in the form of a network device controller may be used instead of an entire computer system, which allows direct connection of each storage device via a network. No additional operating system or file system software is required, which also eliminates the file system dependency problems and limitations identified above.
- However, given that such a system provides no centralized control of data transfers between the hosts and the storage device, data integrity is a potential problem. For example, with each host of the system writing and reading various portions of the storage device, one host may easily overwrite portions of files previously written by another host, thus possibly causing partial or total loss of the data contained in the files.
- To further explain, sharing a data storage device over a network presents unique challenges compared to, for example, those involved with sharing a network printer. A network printer is often shared by more than two host computers, but the nature of the data being transferred over the network necessitates the two situations be treated differently.
- Print commands from computers to network printers apply only to complete files. As a result, all commands issued to a network printer are guaranteed to be serialized at the file level so that no overlapped or interleaved files may be printed. In other words, a file in the shared network printer environment cannot be divided into smaller portions to be interleaved with portions of other files to be printed.
- However, files intended for a data storage device, such as a hard disk drive, are ultimately translated into one or more physical sectors of the data device by way of file system software. Further, no guarantee exists that the file will not occupy several discontinuous series of sectors on the data storage device. Therefore, different files from various hosts sharing the storage device may possibly be mapped onto overlapping sectors unless the file systems of the hosts cooperate in some manner.
- Given the foregoing, systems and methods that allow multiple hosts to access a shared data storage device in an efficient manner without loss of data integrity would be advantageous.
- Generally, embodiments of the present invention allow read and/or write access by multiple hosts, such as computers or other information appliances, to a data storage device by way of a network while maintaining the data integrity of the data storage device. In one particular embodiment, a method for accessing the data storage device provides, in part, acquiring a resource lock, which provides exclusive access to one of the multiple hosts at a time. The host holding the lock may then directly access the storage device without interference from the other hosts. After accessing the storage device, the accessing host releases the lock on that storage device so that other hosts may then be allowed to access the storage device. The lock may be implemented entirely in software, hardware, or a combination thereof. In one embodiment, the lock is implemented within the data storage device, and the data storage device accepts and executes lock access commands issued by the multiple hosts.
- In another embodiment, a networked system is provided which includes a data storage device and a plurality of hosts coupled to the storage device by way of a digital network. In addition, a resource lock is included which provides exclusive access to the data storage device to one of the plurality of hosts at a time. Digital networks employable for coupling the data storage device with the multiple hosts include, but are not restricted to, a local area network such as Ethernet (LAN), a wide area network (WAN), the Internet, a virtual private network (VPN), and any other digital network.
- In another embodiment of the invention, a networked system with a data storage device shared by a plurality of hosts over a network utilizes a file system providing a “check out” attribute for each cluster of free blocks available for file storage. A host attempting to claim a cluster of free blocks analyzes the associated check out attribute to determine if another host has already claimed the cluster. If not, the host sets the check out attribute with a value indicating that it has claimed the cluster, thereby providing the host exclusive access to the cluster. In a further embodiment, a resource lock may be employed to protect the access to the check out attribute. Mutually exclusive access to other file system data structures may be provided in a similar fashion.
- In a further embodiment, a first host has exclusive direct access to a data storage device, which is accessed by way of the host's local file system over a digital network. A second host requiring access to the data storage device communicates with the first host by way of the digital network. File access requests generated by the second host are redirected away from its own local file system to the first host by a redirection filter driver. The first host maintains direct access to the storage device while the second host communicates with the device through the first host's file system. In one embodiment, the first and second hosts each include a file network system for transferring file access requests from the second to the first host. In another embodiment, each of the first and second hosts employ a network connection (such as a socket connection program) to allow the second host to issue file access requests through the first host.
- Additional embodiments and advantages of the invention will be realized by those skilled in the art upon reading the detailed description of the invention.
-
FIG. 1 depicts a block diagram of a typical data storage device connection within a computer system. -
FIG. 2 depicts a block diagram of a computer network connecting multiple host computers with a data storage device at the device level. -
FIG. 3 depicts a block diagram of a typical data abstraction hierarchy of a computer system wherein each layer of the hierarchy provides a different view of a file. -
FIG. 4 depicts a block diagram describing a file access process of a typical computer system employing the data abstraction hierarchy ofFIG. 3 . -
FIG. 5 depicts a flow diagram describing a typical file read or write operation. -
FIG. 6 depicts a flow diagram of a file write operation according to an embodiment of the invention employing a network of multiple hosts sharing a data storage device and a resource lock. -
FIG. 7 depicts a flow diagram of a file read operation according to the embodiment of the invention associated withFIG. 6 . -
FIG. 8 depicts a typical logical view of a conventional file system on a data storage device. -
FIG. 9 depicts a logical view of a Microsoft Windows® NTFS partition. -
FIG. 10 depicts a typical network of hosts that share a data storage device directly at the device level. -
FIG. 11 depicts a free block list of a file system according to an embodiment of the invention. -
FIG. 12 depicts a process of accessing a root directory in a conventional file system. -
FIG. 13 depicts a process of accessing multiple root directories of a file system according to an embodiment of the invention. -
FIG. 14A depicts an example of a first partial directory structure of a file system according to an embodiment of the invention. -
FIG. 14B depicts an example of a second partial directory structure of a file system according to an embodiment of the invention. -
FIG. 14C depicts an example of a third partial directory structure of a file system according to an embodiment of the invention. -
FIG. 15 depicts the entire directory structure of the examples inFIGS. 14A , 14B and 14C. -
FIG. 16 depicts a system employing multiple data storage devices using a file system according to an embodiment of the invention. -
FIG. 17 depicts a block diagram of a networked system according to an embodiment of the invention maintaining the data integrity of a data storage device shared by multiple hosts by way of network file systems. -
FIG. 18 depicts a block diagram of a networked system according to an embodiment of the invention maintaining the data integrity of a data storage device shared by multiple hosts by way of network connection programs. - One embodiment of the invention allows direct connection of one or more hosts to one or more data storage devices, as illustrated in
FIG. 2 . A direct connection between afirst host 10 and a data storage device (or subsystem) 20 over a network, such as aLAN 50, (and also between asecond host 30 and a third host 40, and the data storage device 20) may permit thehosts hosts data storage device 20 is facilitated by way of anetwork device controller host data storage device 20, respectively. In addition, eachhost system bus logical memory network device controller storage device 20. -
FIG. 3 provides a graphical representation of the various levels of abstraction by which data stored on a data storage device may be viewed. At the top of the abstraction hierarchy is a user process 100 (e.g., a user application, an assembly language program, an operating system daemon, or the like) executed on a host computer accessing thestorage device 103, which refers to afile 201 by a file name (such as “MyFile” inFIG. 3 ), thefile 201 being viewed as a sequence of bytes of arbitrary length. At a lower level of abstraction, afile system 101 of the computer system views that same data as a collection ofdata sectors 204 within a linear array of “logical sectors” or “blocks” 202, theblocks 202 of the array typically being numbered from zero up to some maximum sector number. Below that, a software device driver (usually including a computer program having instructions to operate or control the storage device 103), in conjunction with an input/output system 102 may view the data of the file in a fashion closer to its actualphysical configuration 203, or layout, within thedata storage device 103. Generally, an input/output system, such as the Basic Input/Output System, or “BIOS,” of a personal computer, translates operating system calls for access to a data storage device into a form understandable by that device. For example, assuming the use of a hard disk drive as a data storage device, the input/output system 102 may recognize the file as a set of data sectors arranged across one or more disk surfaces, or “platters.” Further, each platter is then normally divided into several tracks, or “cylinders,” which in turn are typically divided into multiple physical sectors. In many hard disk drives, eachlogical block 202 corresponds to a physical sector of the drive. Other physical media, such as tape drives, CDs or DVDs, exhibit other physical data sector layouts, all of which are compatible with and embraced by the present invention. Data abstraction hierarchies other than that shown inFIG. 3 are also possible. In fact, any data abstraction hierarchy and/or any data layout currently known or otherwise compatible with digital data storage is encompassed by the present invention. - Most host computer systems also utilize a data buffer, or “cache,” normally implemented inside the main logical memory of the computer system and logically residing within the data hierarchy between the
file system 101 and the input/output system 102. The buffer is usually employed to increase system performance by saving a copy of a portion of often-used (or recently used) data stored on thedata storage device 103 for future computer CPU or main memory accesses to shorten the time required to access that data. Due to the limited size of the buffer compared to thedata storage device 103, the buffer typically is able to hold only a small percentage of the total amount of data residing in thedata storage device 103 at any given time. -
FIG. 4 depicts abuffer system 105 placed within the data access hierarchy ofFIG. 3 . Shown within thebuffer 105 is acopy 106 of a portion ofuser data 108 residing in thedata storage device 103. However, when thecopy 106 is valid (e.g., thecopy 106 exactly matches the contents of the correspondingdata 108 in the data storage device 103), all requests to access the correspondingdata 108 of thedata storage device 103 will instead access thecopy 106 in thebuffer 105 without directly accessing thedata 108 resident on thedevice 103. - In the example of
FIG. 4 ,user data 106 is read from thebuffer 105 instead of thedata storage device 103 if theuser data 106 in thebuffer 105 is valid. During write operations, all user data to be written to thedata storage device 103 will be copied into either a free space of thebuffer 105, or into an area of thebuffer 105 holding a copy of that data. The physical sectors holding theuser data 108 of thedata storage device 103 are written from thecopy 106 in thebuffer 105 at a later time, depending on the particular buffer flushing strategy employed. The details of various caching and flushing strategies are well-known in the art, and are not critical to the various embodiments of the invention described herein. - As illustrated in
FIG. 4 , thebuffer 105 also normally maintains a cache of meta-data 107 corresponding to and describing thecopy 106 of user data. Meta-data, such as file descriptors, are data necessary for mapping portions offiles 201 toblocks 202 for proper storage and retrieval of file data. Meta-data may include, for example, a file's length and physical location on adata storage device 103. This information is stored on physical sectors of thedata storage device 103 as meta-data 109 associated with thedata storage device 103. Depending on the implementation of theparticular file system 101 employed,additional mapping information 110, such as certain file directories found in thedata storage device 103, may also be cached as meta-data in various data structures of thefile system 101 itself. -
FIG. 5 shows a generalized method of reading or writing data files (or portions thereof normally employed by a single host directly connected to a single data storage device, using the data hierarchy ofFIG. 4 . Inoperation 301, thefile system 101 receives a file read or write request from auser process 100. Following receipt, inoperation 302 thefile system 101 attempts to access acopy 107 of the meta-data in thebuffer 105 that contains the mapping information describing the translation from thefile 201 to the corresponding blocks 202. Inoperation 303, the system determines whether thecopy 107 of the meta-data stored in thebuffer 105 is valid. If the meta-data 107 is valid,operation 305 is executed. If, however, the meta-data 107 is invalid or not present in thebuffer 105, the input/output system 102 executesoperation 304 and converts the location of theblocks 202 of the required meta-data into the corresponding location ofphysical sectors 203 of thedata storage device 103, reads the corresponding meta-data 109 from thephysical sectors 203 of thedata storage device 103, and copies the meta-data 109 into thebuffer 105, resulting in avalid copy 107 of the meta-data in thebuffer 105. Optionally, thefile system 101 may performoperation 303 once again to ensure the meta-data 107 inbuffer 105 is valid. - In
operation 305, with avalid copy 107 of the meta-data now available in thebuffer 105, thefile system 101 reads thecopy 107. Continuing withoperation 306, thefile system 101 determines whether the requested data access requires a read or write of file data. In the case of a read operation,operation 307 is executed, in which thefile system 101 determines theproper blocks 202 of the actual user data desired and attempts to access avalid copy 106 of the user data in thebuffer 105. Inoperation 308, thefile system 101 determines if thecopy 106 of user data is not valid or is nonexistent in thebuffer 105. If thecopy 106 of user data is invalid or not present,operation 309 is performed, in which the input/output system 102 converts the location of theblocks 202 holding that data into the corresponding location ofphysical sectors 203 of thedata storage device 103, reads theuser data 108 from thephysical sectors 203 of thedata storage device 103, and copies theuser data 108 into thebuffer 105, resulting in avalid copy 106 of the user data in thebuffer 105.Operation 308 then may be executed once again to ensure thecopy 106 of the user data in thebuffer 105 is valid. Inoperation 310, thefile system 101 then reads thecopy 106 of the user data from thebuffer 105, thus completing the read request from theuser process 100. - If, instead, the
file system 101 determined inoperation 306 that a write operation is involved,operation 311 is executed, in which thefile system 101 uses thecopy 107 of meta-data previously read from thebuffer 105 inoperation 305 and transfers theuser data 106 and associated meta-data 107 to be written to an appropriate location in thebuffer 105, thus making those portions of thebuffer 105 valid. At some later time, when thebuffer 105 is to be “flushed” (i.e., data in thebuffer 105 is to be written to the data storage device 103),operation 312 is performed, in which theuser data 106 and associated meta-data 107 in thebuffer 105 are written to thedata storage device 103 asuser data 108 and meta-data 109 by way of the input/output system 102, thereby completing the write operation. - As mentioned earlier, allowing multiple hosts concurrent direct access to the
data storage device 103 may cause data integrity problems in both the meta-data 109 and thefile data 108 located on thedata storage device 103, as well as anycopies buffer 105 of each host. For example, referring toFIG. 2 , onehost 10 might be in the process of updating a preexisting file resident on astorage device 20 by way of multiple write operations. Before completion of the update, asecond host 30 may read the same file from thedata storage device 103, thus receiving an intermediate and incorrect copy of the file. - In addition, the use of a
buffer 105 within each of the hosts exacerbates any potential data integrity problems. For example, if each host is accessingcopies own buffer 105, updates to thosecopies buffer 105 and written to thedata storage device 103. Accordingly, each host may be attempting to update the same data file in different ways, completely unaware that multiple, dissimilar copies of the same file exist, thus destroying the data integrity of that file. - To address this problem, one embodiment of the invention involves the use of a resource “lock” to prevent access to the
data storage device 103 at the device level by more than one host at any particular time. Generally speaking, the lock is acquired by a host attempting access the storage device, including any reading or writing of a data file to thedevice 103, and is released after the access operation has been completed. In most embodiments, completion of a write command would include the host in possession of the lock flushing the contents of itsbuffer 105, thus ensuring the meta-data and file data of thedata storage device 103 has been updated. Only one host may possess the lock at any one time, thereby prohibiting access to the data storage device by any other host. The lock may also be implemented as a “semaphore” or similar construct known in the art. Generally, a semaphore is a flag or similar indicator that is writable and readable by one or more hosts, and is used to relay a simple message between those hosts. - The lock itself may be implemented in several different ways. The lock may be implemented entirely in software (such as device driver or network protocol), although hardware implementations are possible as well, as are hybrid hardware/software implementations. In one embodiment, the
data storage device 103 itself may internally store the value of the lock for access by each of the hosts using thedevice 103. All access and manipulation of the lock by the host would then be controlled, for example, by a device-level controller within or operably connected to thedata storage device 103. In addition to lock control, the device-level controller may process standard device-level commands normally targeted for a data storage device, such as the commands associated with the Small Computer Systems Interface (SCSI) or Integrated Drive Electronics (IDE) interfaces known in the art. - Generally, a device-level controller is implemented by way of an embedded microcontroller system designed and employed to perform tasks specific to the control and maintenance of the associated data storage device, including the processing of device-level commands, as described above. Typically, such a system employs resources, in terms of algorithmic capability, speed and logical memory, minimally sufficient to perform its assigned duties in terms of data storage device control, but not to implement commands beyond device control. (For example, the microcontroller may respond to device-level command, but would not implement and run an operating system.) Accordingly, the term “computer,” as is generally employed in the art, does not embrace a device-level controller of the embodiments of the present invention.
- In some embodiments, the data storage device 103 (or associated controller) may provide lock control and access for the hosts by way of lock-specific commands that facilitate the checking and setting of the lock. For example, the
data storage device 103 may provide an “acquire lock” command that provides both a checking and setting of the lock in one operation. In other words, if the lock is already held by another host, thedata storage device 103 will return a failure indication to the requesting host. Otherwise, a success indication can be returned, indicating to the requesting host that the lock acquisition was successful, in which case the requesting host may proceed with accessing data on thedata storage device 103. In another implementation, the requesting host may be able to specify a timeout period as a parameter of the acquire lock command so that thedata storage device 103 attempts to acquire the lock for the requesting host for the timeout period if the lock is held by another host before returning a failure indication. In addition, thedata storage device 103 would also support a “release lock” command to allow the host holding the lock to allow access by the other hosts. In another embodiment, anetwork device controller 34, as shown inFIG. 2 , may implement the locking mechanism instead of thedata storage device 103 ofFIGS. 3 and 4 . - In yet another implementation, the lock may be implemented by one of the hosts accessing the
data storage device 103. Other hosts would then access the lock by making requests via the network to the host implementing the lock. In another embodiment, responsibility for maintaining the lock may be distributed among all or some subset of the hosts involved, with each host possessing a local copy of the state of the lock, including the identity of the host currently in possession of the lock. In that particular case, care must be taken to ensure that each of the hosts maintains a current copy of the state of the lock. -
FIG. 6 generally shows the steps of a write operation of a file according to an embodiment of the invention employing a resource lock to enhance the data integrity of the file being written. Using the system ofFIG. 4 as a template for a host and a data storage device,operation 401 is first executed, in which theuser process 100 issues a file write request to thefile system 101. Inoperation 402, thefile system 101 first acquires the lock before initiating the actual write operation. As stated above, acquisition of the lock may be delayed if another host is already in possession of the lock. In one embodiment, the requesting host may “time out” if the lock has not been acquired within a predetermined period of time, thus allowing the host to complete other tasks before attempting to acquire the lock once again. Duringoperation 402, thefile system 101 may intermittently check for the lock explicitly, or such an intermittent check may be performed automatically by another software routine. Alternately, the file system may place a request for the lock, and then be interrupted by another software routine when the lock becomes available. - Once the lock is acquired,
operation 403 is performed, in which thefile system 101 checks for avalid copy 107 of the meta-data in thebuffer 105. In some cases, thefile system 101 may assume beforehand that the meta-data 107 in thebuffer 105 is invalid if the previous lock holder was another host, thereby circumventing an exhaustive check of thebuffer 105. In such a case, an identification of the last host to hold the lock may also be implemented in conjunction with the lock itself. For example, a host may write a specific file system data structure on thedata storage device 103 after acquiring a lock indicating it is the most recent holder of the lock. - If the meta-data in the
buffer 105 is not present or valid,operation 404 is executed, in which the corresponding meta-data 109 is read from the data storage device 103 (i.e., the data storage device 103) using the input/output system 102. Otherwise, thefile system 101 may proceed tooperation 405. Onceoperation 404 is complete, thefile system 101 may again check if validity of the meta-data in thebuffer 105 is valid inoperation 403. With avalid copy 107 of the meta-data now in thebuffer 105,operation 405 is performed, in which thefile system 101 reads that copy 107 of the meta-data, translates the information for thefile 201 into a set ofblocks 202 containing the desired user data, and then writes the new data into the proper location in thebuffer 105. In addition, the meta-data is updated based on any changes necessary due to the new user data to be written. - The
file system 101 then determines inoperation 406 if the host will hold the lock after the write operation. If not, inoperation 408 the host flushes all file data and meta-data in thebuffer 105 to thedata storage device 103 using the input/output system 102 to perform the logical-to-physical sector translation before it releases the lock inoperation 409. If the host holds the lock, the host then determines inoperation 407 if another write request is pending. If so, the write procedure resumes by returning tooperation 403. If there is no pending write request, the host determines if it will still hold the lock inoperation 406 based on other criteria, such as anticipated near-term data storage device access requirements. - As a result, the lock mechanism prevents multiple hosts from simultaneously or concurrently writing to the
data storage device 103 by allowing only one host at any time to hold the lock for writing operations. Accordingly, the writing by any host holding a lock is likely valid, because all previous write operations to the shareddata storage device 103 by other hosts are fully recorded by flushing alluser data 106 and meta-data 107 from thebuffer 105 to thedata storage device 103 before another host can acquire a lock. - In an alternative embodiment, all hosts connected to the
data storage device 103 may cooperate to time-share access to thedata storage device 103 by allocating a limited lock hold time to each host, thus preventing monopolization of the lock by any single host. The limited hold time may be invariant (for example, ten seconds per host), prioritized by host (for example, host A has a ten second lock while host B has a five second lock), or varying with some other parameter (for example, larger files may permit longer locks, lock duration may be determined by data throughput speed of the storage device and the host, and so forth). -
FIG. 7 illustrates the process flow of a read operation, according to another embodiment of the invention, utilizing a lock to guarantee the file data read is consistent with the data resident on thedata storage device 103. Inoperation 501, the file system receives a read request from auser process 100. Thus, inoperation 502, thefile system 101 acquires a lock before initiating a read operation. Once thefile system 101 acquires the lock,operation 503 is executed, in which thefile system 101 determines if thecopy 107 of meta-data and other mapping information is present and valid in thebuffer 105. If not, inoperation 504 thefile system 101 reads the corresponding meta-data 109 from thedata storage device 103 by way of the input/output system 102 into thebuffer 105. Thefile system 101 may then return tooperation 503 to ensure the validity of the meta-data 107 in thebuffer 105. Inoperation 505, thefile system 101 reads thecopy 107 of the valid meta-data from thebuffer 105, performs a translation from the name of thefile 201 to a set ofblocks 202, and searches thebuffer 105 for avalid copy 106 of the file data corresponding to theblocks 202. If acopy 106 of the file data is not in thebuffer 105, or such a copy is not valid, thefile system 101 performsoperation 506, in which thefile data 108 is read from thedata storage device 103. Again, at this point thefile system 101 may return tooperation 505 to ensure the validity of thefile data 106 in thebuffer 105. With avalid copy 106 of the file data in thebuffer 105, thefile system 101 executesoperation 507 and completes the read request by obtaining the data copy 106 from thebuffer 105, before releasing the lock inoperation 508. Since thefile system 101 has not written any meta-data or file data to thebuffer 105, flushing the buffer prior to releasing the lock is not required, as was the case during the write operation described inFIG. 6 . In alternative embodiments, thefile system 101 may retain the lock to execute further read or write operations prior to releasing the lock. - In one implementation, the reading procedures of
FIG. 7 may be performed while bypassing the procedures of acquiring and releasing the lock (steps 502, 508) if the meta-data 109 and filedata 108 are read directly from thedata storage device 103 instead of thebuffer 105. If so, any problems with the contents of thebuffer 105 remaining consistent with thedata storage device 103 are eliminated. However, in some cases, the data read by a host that has not acquired a lock may be in a partially-modified state if another host holding the lock is in the process of writing the same file to thedata storage device 103. As a result, the adequacy of reading data without performing the locking and unlocking operations may be determined by whether data that has been partially-modified is acceptable for host use. In addition, a time-share lock scheme may be implement for the read operation ofFIG. 7 , as presented above in the discussion ofFIG. 6 . - The write and read operations shown in
FIG. 6 andFIG. 7 , respectively, can be implemented by adding filter driver software atop the existingfile system 101 without modifying the existing file system or adding an extra file system. Effectively, the filter driver may be layered into or atop the file and/or operating systems. In one embodiment, the filter driver software intercepts the read and write requests to the existingfile system software 101 before it acquires the lock. For example, the filter driver software may verify the validity of the meta-data 107 anduser data 106 in thebuffer system 105 before it notifies thefile system 101 about the validity, as well as perform the locking and unlocking procedure. - In another embodiment of the invention, the data integrity of a data storage device shared among multiple hosts over a network at the device level is maintained by a set of features or data structures provided by the file systems of the hosts. These structures provide a mechanism by which free blocks (i.e., blocks not currently written with valid user data or meta-data) of the data storage device are allocated to each host in a mutually exclusive manner. Considering this particular embodiment of the invention involves enhancements to the typical file system currently available, a more detailed discussion of file systems and their operation is provided.
- A file system, which typically is the largest unit of data structure identified with a persistent data storage device, normally includes a collection of files, file descriptors, directories and other file-system-related information. The file system is stored on a “logical disk,” which can be a physical disk (e.g., a hard disk drive), a disk partition (i.e., some identified portion of a physical disk), several physical disks, or some other physical manifestation of a data storage device. From the file system's standpoint, a logical disk is composed of a large, one-dimensional array of logical blocks, as described above.
-
FIG. 8 presents an example disk block layout of a file system. Typically, the first block is reserved for aboot block 601, which is the first disk block read by a computer system to determine where on the disk to retrieve the operating system and other necessary information to initialize the computer after a reset has occurred. A file system descriptor 602 (often called a “super block” in the UNIX operating system) contains information about the file system as a whole, since the file system is viewed as an object or entity in and of itself, and thus requires a data structure to represent it. Thefile system descriptor 602 defines the total size of the file system in blocks, the size of the file descriptor area, the location of the root directory (i.e., the top directory in a hierarchically-arranged file structure), and other file system meta-data. One other important item of information defined in thefile system descriptor 602 is the first block of the free block list. - File descriptors 603 (often called “inodes” in UNIX) contain all meta-data associated with a particular file, including the actual block addresses on the data storage device where the file data is located. Other meta-data in the
file descriptors 603 normally include the owner of the file, file protection information, time of creation, time of last modification, time of last use, and other information related to the specific file. - In most file system implementations, directories, which essentially are logical collections of files and other directories, are actually implemented as files, so each directory will have a file descriptor in the file descriptor area and occupy some data blocks in the
data block area 604. In other words, no special areas of the storage device are reserved within the file system for directories. - Generally, at some point in time, some plurality of the data blocks on a data storage device are allocated or occupied by file data and file descriptors, while some blocks remain unallocated, or “free.” All allocated blocks are linked to a file descriptor so that file data can be traced by starting with the corresponding file descriptor. As files grow, more free blocks are allocated to the files as necessary. Accordingly, file systems typically maintain a list of free blocks for quick allocation of those blocks to files.
-
FIG. 8 shows a logical view of a typical file system. The actual locations of each entity depicted may be allocated across the entire allotment of disk blocks. For example, the file descriptors may be located in any of a number of areas on the disk, as they may be positioned with the file names in the directories, in a special area of the disk reserved for file descriptors, or among the disk blocks containing the actual file data. - Different file systems may also define varying structures containing the information required to implement the file system. For example,
FIG. 9 depicts a logical view of a partition of the Microsoft Windows® NT File System (NTFS), in which information on the file system itself and the starting block number of the Master File Table (MFT) 606 is stored in aboot sector 605. The Master File Table 606 holds meta-data concerning every other file and directory contained in the file data blocks 607 of the NTFS partition. The Master File Table 606 also contains sixteen entries, or records, reserved for various special meta-data files, including a free block list. - Traditional file systems are designed such that all free blocks are managed by a single host because the data storage device is normally attached to the inner system bus of the host. As a result, only the single host may directly access the device. However, if two different hosts are able to access the device directly at the device level, as would be the case when a storage device is coupled with the hosts directly via a network, each host may allocate logical blocks from the same free block list independently, thus potentially allocating identical blocks to different files. This, in turn, would corrupt the consistency and integrity of the entire file system.
-
FIG. 10 shows an exemplary system ofmultiple host computers data storage device 630 over anetwork 620 directly at the device level, while relying solely on the local file systems of thehosts storage device 630. Sharing a hard disk drive or other data storage device directly at the device level is distinguished from sharing a storage device by multiple hosts indirectly via a separate server through a distributed file system by way of the data integrity support provided by a distributed file system. Direct accessing of a remote hard disk drive by one or more computing devices is discussed in U.S. Provisional Application Ser. No. 60/592,722, entitled “Low-Level Communication Layers and Device Employing Same,” incorporated by reference herein in its entirety. - For example, some distributed file systems, such as xFS (“x” File System) and GFS (Global File System) utilize a server for managing the meta-data of the file system, including the free block list. Each client host consults the server before the client acquires free blocks for writing a file. The server allocates free blocks, but does not control actual data written to the storage device. This mechanism allows the clients to write and read data blocks onto and from the data storage device directly without relaying the user data to and from the server. However, this mechanism does not allow the hosts to share the storage device directly at the device level without server intervention. Thus, since only the server controls the allocation of free blocks, and each client host must consult the server to obtain free blocks, the file system cannot be corrupted on the basis of allocating free blocks to multiple clients. However, such a mechanism suffers from scalability and performance overhead limitations since a single server intervenes in all free block allocation to provide proper meta-data management and cache coherency. Thus, computer networks employing a distributed file system generally lack the performance associated with a network in which multiple computers access a shared data storage device directly at the device level without the assistance of a file server.
- In order for multiple hosts sharing the same storage device to maintain free blocks of the storage device in a manner such that no block is allocated to more than one particular file at a time, the total number of free blocks may be divided into multiple, mutually exclusive sets of free blocks, with each set being accessible to only one particular host at a time. For example,
FIG. 11 shows a logical view of a list of free blocks according to various embodiments of the invention. Each of a first, second, third andfourth entry FIG. 11 depicts the logical view of the entries denoting the free blocks in the form of a list, alternative embodiments of the invention are not limited to a specific data structure, such as a list structure. For example, in many file system implementations entries of free blocks are maintained as a form of “bitmap,” wherein each bit represents a cluster on the physical disk, thus identifying whether the cluster is free or has been allocated to a file. - In further reference to
FIG. 11 , each free block cluster is associated with a “check out”attribute attribute attribute - Any checked out blocks not ultimately allocated to a file are subsequently returned by the accessing host to the free block list. To return the unallocated free blocks, the host inserts new nodes of free block clusters into the free block list and leaves the check out
attribute - In addition to setting the check out attribute, the accessing host also sets a
timestamp attribute timestamp timestamp - In the specific example of
FIG. 11 , the first cluster of free blocks denoted byentry 620 is checked out to a host i with a timestamp value 628 of t1, and the second cluster indicated byentry 621 is checked out to a host j with atimestamp value 629 of t2. The other clusters denoted by theentries - The file system stores within its file system descriptor the location of the file descriptor of the root directory. As the root directory and subdirectories accumulate files and other directories, links are provided within each directory pointing to block locations in the file data block area where the files and file descriptors associated with the directory are stored. Therefore, the file system can trace the entirety of the directory structure starting from the root directory.
FIG. 12 illustrates how a directory structure is implemented in an exemplary conventional local file system. The file system may follow alink 642 from itsfile system descriptor 640 to the location of thefile descriptor 644 of the root directory, which in turn contains anotherlink 646 indicating the location ofadditional data 648 associated with the root directory. - In one embodiment of the invention, a separate set of file descriptors for the root directory are provided for each host that shares the device, in contrast to the single set of file descriptors normally employed.
FIG. 13 illustrates one possible implementation of multiple file descriptors for the root directory, one for each host that shares a data storage device. In this example, thefile system descriptor 650 contains alink 652 to a set of rootdirectory file descriptors 654, 656, 658, each of which is the file descriptor of the root directory for each of three hosts sharing the device. - When a host accesses the file system to view the directory structure, the host peruses the entire directory structure by following the links to the corresponding file descriptors and data starting from the complete set of root
directory file descriptors 654, 656, 658 allocated to the hosts. In the particular example ofFIG. 13 , thelinks 652 in thefile system descriptor 650 point to three rootdirectory file descriptors 654, 656, 658, each of which corresponds to one of the three hosts. Also, each of the rootdirectory file descriptors 654, 656, 658, in turn, points to the corresponding data blocks 660, 662, 664 for storing directory information for each of the three hosts, respectively. - In further reference to the exemplary file directory structure depicted in
FIG. 13 , presumeHost 1 creates a directory “dir A” under the root directory, and creates a file “file A1” under the “dir A” directory, as depicted inFIG. 14A .Host 1 stores information necessary for the directory structure it created in the blocks allocated for its root directory file descriptor 654 and associated data blocks 660, as shown inFIG. 13 . Similarly, as shown inFIG. 14B ,Host 2 creates its own directory “dir B” under the root directory, and creates a file “file B1” under “dir B,” using its root directory file descriptor 656 and data blocks 662.Host 2 then creates another file “file B2” under “dir A” originally created byHost 1, employing information in the root directory file descriptor 654 and data blocks 660 created byHost 1. Further, as shown inFIG. 14C ,Host 3 creates its own directories “dir C1” and “dir C2” under the root directory and “dir A” by employing its rootdirectory file descriptor 658 and data blocks 664.Host 3 then creates files, “file C1” and “file C2” under “dir A” and “dir C1”, respectively. - As is evident from the foregoing discussion, any host can read directory structures created by other hosts in order to obtain a complete view of the entire directory structure by following the links starting from the root directory file descriptors allocated for the hosts involved. As a result, any host can create its own files under directories created by other hosts.
- Further, if the links starting from one of the root directory file descriptors identified with a particular host (for example, the root directory file descriptor for Host 1) are followed, the directory structure created by that host may be retrieved. In other words, each of the directory structures created by each host can be retrieved by following the links starting from the root directory file descriptor allocated for the corresponding host.
- Based on the foregoing, the directory structure created by each host constitutes a portion of the total directory structure of the entire file system. The total directory structure may thus be obtained by superimposing the partial directory structures created by each of the hosts. For example,
FIG. 15 depicts the total directory structure of the data storage device by superimposing the three partial directory structures created by the three hosts, as shown inFIGS. 14A , 14B and 14C. - The file system maintains attributes of a file, as well as the file data itself, to represent related information necessary for management of the file. One such attribute in one embodiment indicates ownership of the file. Because embodiments of the invention allow multiple independent hosts to share the same device directly at the device level, the file system may maintain an “ownership” attribute within the meta-data of each file to distinguish which host maintains ownership of the file. This host identification prevents a host from exercising impertinent access rights to files owned by other hosts.
- Another file attribute in another embodiment of the invention is a “check out” attribute of a file, which is distinguished from the “check out” attribute associated with each free block cluster, described in detail above. When a host having write permission for a particular file accesses that file, the file system marks the check out attribute of the file with an identification of the accessing host. At that point, other hosts may not check out the file with write permission. This mechanism prevents more than one host from writing the same file at the same time, which would likely corrupt the data in the file. However, in some embodiments hosts may read a file that is currently checked out by another host holding write permission.
- In one embodiment, the file system may require a host to acquire a resource lock before it can check out the file in order to prevent race conditions created by multiple hosts vying to check out the same file. Alternatively, if the data integrity level of a file is relaxed, use of a resource lock can be avoided. For example, some video and audio data files may remain viable even if the data integrity of the files has been compromised to a degree.
- Conventional file systems typically maintain in-memory data structures, instead of on-disk data structures (such as the file check out attribute described above), for managing the consistency of files opened by system processes of the host. Storing such data structures in volatile memory, like many forms of random access memory (RAM) (or other non-persistent storage devices), may be appropriate in an environment in which a single host possesses exclusive control of the storage device. In the embodiments described herein, however, multiple hosts may share control of the data storage device. Therefore, data structures relevant to file consistency management that are maintained only within the volatile memories of each host may have limited utility where multiple hosts share the same storage device directly at the device level unless the hosts share the in-memory data structures spread over multiple hosts.
- A file system generally maintains files containing information for effective handling of the blocks of the storage device on which the file system is implemented. These files are termed “file system files.” Typically, two of these files are the free block file and the bad block file. The free block file contains a list of blocks that are free, and possibly a complementary list of blocks that are written. The bad block file contains a list of “bad,” or defective, blocks on which no data can be written to or read from correctly, generally due to defective portions of the recordable medium within the data storage device. Conventional file systems have a single host manage those particular file system files.
- In various embodiments of the present invention, each host of a multiple-host system accesses the free block file in a mutually exclusive manner by way of the cluster check out attribute, as described in detail earlier. In addition, resource lock acquisition may be required prior to setting the check out attribute in some embodiments, thereby providing additional data integrity for the free block file. Access to the bad block file may be regulated in a similar fashion so that hosts may add bad blocks to the bad block list in a secure manner as they are encountered in the course of disk operation. Further, the same control mechanism may be applied to maintain the data integrity of any file system files.
- Ordinarily, the use of multiple hosts sharing a single data storage device would produce the possibility of file name conflicts among files created by the multiple hosts. For example, if the hosts run the same operating system and use default swap files set automatically by the operating system, two or more swap files associated with different hosts could have the same file name under the same directory. However, in embodiments of the invention, the host ownership attribute (described above) may be utilized to distinguish such files.
- The file system features presented herein may also be implemented in a system employing multiple shared storage devices.
FIG. 16 presents adata storage system 670 containing multipledata storage devices controller logic 674. Thecontroller logic 674 oversees all threedata storage devices devices system 670. Alternatively, multiple data storage device partitions of one or more physical storage devices may be presented in a similar manner. - The
controller logic 674 may be implemented as hardware, software, or some combination thereof. In one embodiment, a combination of hardware and software could be employed to process device-level commands for each of thedata storage devices controller logic 674.) Alternatively, thecontroller logic 674 may be a software driver executed by a microcontroller system capable of transforming and/or relaying device-level commands received from a host to one of thedata storage devices storage devices particular storage device target storage device - In alternative embodiments of the invention, data integrity of a system of multiple hosts sharing a data storage device can be maintained by utilizing file systems already existing in current hosts. More specifically, instead of allowing all hosts to share a data storage device directly at the device level over a network, one host may have access to the data storage device at device level over a network, while all other hosts are allowed indirect access to the data storage device via their network file systems.
-
FIG. 17 shows an alternative embodiment where only afirst host 701 is allowed to mount a networked data storage device 742 (such as a hard disk drive) by way of anetwork device controller 741 with full read/write privileges onto one of itslocal file systems 706. All other hosts requiring access to thedata storage device 742, such as asecond host 702, are not permitted to mount the networkeddata storage device 742 onto their own local file systems. - In one embodiment using the structure described in
FIG. 17 , aredirection filter driver 700, a software component, resides at the interface between the user process and the file system of thesecond host 702. Although thesecond host 702 has no privilege of directly mounting thedata storage device 742, theredirection filter driver 700 redirects all file access requests from a user process intended for thedata storage device 742 toward anetwork file system 707 of thesecond host 702. As a result, theredirection filter driver 700 presents the appearance of a local file system (shown as a functionallocal file system 705 inFIG. 17 ) to the user process as if thedata storage device 742 were mounted onto thesecond host 702. Thenetwork file system 707 of thesecond host 702 is connected by way of theLAN 750 with anetwork file system 708 of thefirst host 701 so that the file access requests directed toward thedata storage device 742 generated in thesecond host 702 are routed to alocal file system 706 of thefirst host 701, onto which thedata storage device 742 is actually mounted. - Sharing the
data storage device 742 between the first andsecond hosts FIG. 17 exploits features of thenetwork file systems second host 702 and thedata storage device 742 while maintaining data integrity, an additional network file system for thedata storage device 742 is not required. Instead, the embodiment ofFIG. 17 provides hosts a functional view of a local file system onto which thedata storage device 742 appears to be directly mounted. As used herein, the term “functional” refers to a duplication of the view that would be shown if the file were accessible on a local storage device, rather than across a network. Thedata storage device 742 and its files are handled in exactly the same fashion as actual local data storage devices and files. Due to the operation of theredirection filter driver 700, the hosts exhibiting a functional local file system view cannot distinguish thedata storage device 742 shared over the network from the devices actually mounted on their own conventional local file systems. Accordingly, since the files on thedata storage device 742 are not viewed as shared through conventional network file systems, but are instead viewed as stored by way of a local file system, file usage limits that would otherwise exist if the files were shared through conventional network file systems are eliminated. - Similarly, when the
network file system 708 of thefirst host 701 later receives a reply from thelocal file system 706 to be transferred to thenetwork file system 707 of thesecond host 702, thenetwork file system 707 of thesecond host 702 directs the reply to the requesting user process through the redirectionfilter driver software 700 as though the reply were received from the functionallocal file system 705. - If no network file system is available or desirable between a host that physically mounts a data storage device (e.g., the
first host 701 ofFIG. 17 ) and other hosts that do not have direct access to the data storage device (e.g., thesecond host 702 ofFIG. 17 ), a network connection program may be utilized instead of a network file system to transfer requests and replies for file accesses involving a data storage device. -
FIG. 18 illustrates an alternative embodiment wherein only afirst host 703 possesses direct access to adata storage device 742, such as a hard disk drive, while other hosts, such as asecond host 704, may only access thedata storage device 742 via thefirst host 703. Each of the first andsecond hosts network connection program hosts FIG. 17 , a redirection filter driver 711, residing between a user process and the file system of thesecond host 704, intercepts data storage device access requests from the user process and redirects the requests to thenetwork connection 709 of thesecond host 704. Thisnetwork connection 709 then relays these requests to itscounterpart network connection 710 of thefirst host 703, which in turn directs the request to alocal file system 706 of thefirst host 703, onto which the networkeddata storage device 742 is mounted through anetwork device controller 741. As was the case with the embodiment outlined inFIG. 17 , the redirection filter driver 711 operates to present a functionallocal file system 712 to a user process of thesecond host 704, making the fact that thedata storage device 742 is not mounted locally to thesecond host 704 transparent to the user process. - When the
network connection 710 of thefirst host 703 then receives a reply from thelocal file system 706 to be transferred to itscounterpart network connection 709 of thesecond host 704, thenetwork connection 709 of thesecond host 704 directs the reply to the requesting user process through the redirection filter driver software 711 as if the reply were received from the functionallocal file system 712. Thenetwork connections - Certain features of the invention described herein may be implemented as an additional layer in or atop the file and/or operating systems. For example, the aforementioned filter driver software may be added to an existing file system without requiring modification of the file system. Similarly, certain features of the invention may be implemented as an additional attribute of a storage device, storage device controller, or storage device file system/structure. For example, the aforementioned check out attribute may augment a file system or structure to provide added functionality. The basic file system/structure may remain relatively unchanged. In other words, the basic functionality and features of the core file system, structure, operating system, and so forth remain unchanged by the invention, which provides added functionality.
- Disclosed herein are several embodiments of systems and methods for ensuring the data integrity of a networked data storage device that is shared among a plurality of hosts. While these embodiments are described in specific terms, other embodiments encompassing principles of the invention are also possible. For example, various features of one embodiment may be combined with features of other embodiments to create a new embodiment not specifically discussed herein. Thus, the scope of the invention is not to be limited to the disclosed embodiments, but is determined by the following claims.
Claims (52)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/255,433 US20090043971A1 (en) | 2003-09-26 | 2008-10-21 | Data integrity for data storage devices shared by multiple hosts via a network |
Applications Claiming Priority (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US50682903P | 2003-09-26 | 2003-09-26 | |
US58169104P | 2004-06-21 | 2004-06-21 | |
US59072204P | 2004-07-22 | 2004-07-22 | |
US10/951,474 US7457880B1 (en) | 2003-09-26 | 2004-09-27 | System using a single host to receive and redirect all file access commands for shared data storage device from other hosts on a network |
US12/255,433 US20090043971A1 (en) | 2003-09-26 | 2008-10-21 | Data integrity for data storage devices shared by multiple hosts via a network |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/951,474 Division US7457880B1 (en) | 2003-09-26 | 2004-09-27 | System using a single host to receive and redirect all file access commands for shared data storage device from other hosts on a network |
Publications (1)
Publication Number | Publication Date |
---|---|
US20090043971A1 true US20090043971A1 (en) | 2009-02-12 |
Family
ID=40029569
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/951,474 Active 2025-04-15 US7457880B1 (en) | 2003-09-26 | 2004-09-27 | System using a single host to receive and redirect all file access commands for shared data storage device from other hosts on a network |
US12/255,433 Abandoned US20090043971A1 (en) | 2003-09-26 | 2008-10-21 | Data integrity for data storage devices shared by multiple hosts via a network |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/951,474 Active 2025-04-15 US7457880B1 (en) | 2003-09-26 | 2004-09-27 | System using a single host to receive and redirect all file access commands for shared data storage device from other hosts on a network |
Country Status (1)
Country | Link |
---|---|
US (2) | US7457880B1 (en) |
Cited By (30)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20070219685A1 (en) * | 2006-03-16 | 2007-09-20 | James Plante | Vehicle event recorders with integrated web server |
US20080040478A1 (en) * | 2006-08-09 | 2008-02-14 | Neocleus Ltd. | System for extranet security |
US20080111666A1 (en) * | 2006-11-09 | 2008-05-15 | Smartdrive Systems Inc. | Vehicle exception event management systems |
US20080235779A1 (en) * | 2007-03-22 | 2008-09-25 | Neocleus Ltd. | Trusted local single sign-on |
US20080235794A1 (en) * | 2007-03-21 | 2008-09-25 | Neocleus Ltd. | Protection against impersonation attacks |
US20090049259A1 (en) * | 2007-08-13 | 2009-02-19 | Sudhakar Gosukonda Naga Venkat | Clustered snapshots in networks |
US20090157255A1 (en) * | 2005-12-08 | 2009-06-18 | Smart Drive Systems, Inc. | Vehicle Event Recorder Systems |
US20090178138A1 (en) * | 2008-01-07 | 2009-07-09 | Neocleus Israel Ltd. | Stateless attestation system |
US20090222163A1 (en) * | 2005-12-08 | 2009-09-03 | Smart Drive Systems, Inc. | Memory Management In Event Recording Systems |
US20090307705A1 (en) * | 2008-06-05 | 2009-12-10 | Neocleus Israel Ltd | Secure multi-purpose computing client |
US20110231613A1 (en) * | 2010-03-19 | 2011-09-22 | Ober Robert E | Remote storage caching |
US20120137091A1 (en) * | 2010-11-29 | 2012-05-31 | Cleversafe, Inc. | Selecting a memory for storage of an encoded data slice in a dispersed storage network |
US20130061015A1 (en) * | 2011-09-07 | 2013-03-07 | Kabushiki Kaisha Toshiba | Access control apparatus and access control system |
US20130227225A1 (en) * | 2012-02-27 | 2013-08-29 | Nokia Corporation | Method and apparatus for determining user characteristics based on use |
US8892310B1 (en) | 2014-02-21 | 2014-11-18 | Smartdrive Systems, Inc. | System and method to detect execution of driving maneuvers |
US20140365445A1 (en) * | 2013-06-11 | 2014-12-11 | Hon Hai Precision Industry Co., Ltd. | Server with file managing function and file managing method |
US8989959B2 (en) | 2006-11-07 | 2015-03-24 | Smartdrive Systems, Inc. | Vehicle operator performance history recording, scoring and reporting systems |
US9135116B1 (en) * | 2011-09-29 | 2015-09-15 | Emc Corporation | Cloud enabled filesystems provided by an agent which interfaces with a file system on a data source device |
US9183679B2 (en) | 2007-05-08 | 2015-11-10 | Smartdrive Systems, Inc. | Distributed vehicle event recorder systems having a portable memory data transfer system |
US9201842B2 (en) | 2006-03-16 | 2015-12-01 | Smartdrive Systems, Inc. | Vehicle event recorder systems and networks having integrated cellular wireless communications systems |
US20160179872A1 (en) * | 2006-03-31 | 2016-06-23 | Amazon Technologies, Inc. | System and Method for Providing High Availability Data |
US9501878B2 (en) | 2013-10-16 | 2016-11-22 | Smartdrive Systems, Inc. | Vehicle event playback apparatus and methods |
US9554080B2 (en) | 2006-11-07 | 2017-01-24 | Smartdrive Systems, Inc. | Power management systems for automotive video event recorders |
US9610955B2 (en) | 2013-11-11 | 2017-04-04 | Smartdrive Systems, Inc. | Vehicle fuel consumption monitor and feedback systems |
US9663127B2 (en) | 2014-10-28 | 2017-05-30 | Smartdrive Systems, Inc. | Rail vehicle event detection and recording system |
US20170195283A1 (en) * | 2011-08-30 | 2017-07-06 | Amazon Technologies, Inc. | Allocating identifiers with minimal fragmentation |
US9728228B2 (en) | 2012-08-10 | 2017-08-08 | Smartdrive Systems, Inc. | Vehicle event playback apparatus and methods |
US10649856B2 (en) * | 2017-09-01 | 2020-05-12 | International Business Machines Corporation | Concurrent writing to a file during backup of the file |
US10930093B2 (en) | 2015-04-01 | 2021-02-23 | Smartdrive Systems, Inc. | Vehicle event recording system and method |
US11069257B2 (en) | 2014-11-13 | 2021-07-20 | Smartdrive Systems, Inc. | System and method for detecting a vehicle event and generating review criteria |
Families Citing this family (37)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8266241B1 (en) * | 2004-06-22 | 2012-09-11 | Apple Inc. | Image sharing |
US20080155050A1 (en) * | 2006-12-23 | 2008-06-26 | Simpletech, Inc. | Direct file transfer host processor |
US20080155051A1 (en) * | 2006-12-23 | 2008-06-26 | Simpletech, Inc. | Direct file transfer system and method for a computer network |
JP5008392B2 (en) * | 2006-12-27 | 2012-08-22 | 富士通株式会社 | Firmware revision method and revision program |
US7933991B2 (en) * | 2007-10-25 | 2011-04-26 | International Business Machines Corporation | Preservation of file locks during checkpoint and restart of a mobile software partition |
WO2010098772A1 (en) * | 2009-02-27 | 2010-09-02 | Hewlett-Packard Development Company, L.P. | System and method for supporting a remote isochronous device |
US8171337B2 (en) * | 2009-03-30 | 2012-05-01 | The Boeing Company | Computer architectures using shared storage |
US20110282850A1 (en) * | 2010-05-11 | 2011-11-17 | Microsoft Corporation | Concurrently Accessing Data |
US8655847B2 (en) | 2010-08-16 | 2014-02-18 | Microsoft Corporation | Mirroring data changes in a database system |
US9411517B2 (en) * | 2010-08-30 | 2016-08-09 | Vmware, Inc. | System software interfaces for space-optimized block devices |
US9098462B1 (en) | 2010-09-14 | 2015-08-04 | The Boeing Company | Communications via shared memory |
US9571576B2 (en) | 2010-11-30 | 2017-02-14 | International Business Machines Corporation | Storage appliance, application server and method thereof |
US8639971B1 (en) | 2011-02-17 | 2014-01-28 | Scale Computing | Condition detection and reporting in complex systems |
JP2012203475A (en) | 2011-03-23 | 2012-10-22 | Toshiba Corp | Communication device and control method therefor |
US9342254B2 (en) * | 2011-06-04 | 2016-05-17 | Microsoft Technology Licensing, Llc | Sector-based write filtering with selective file and registry exclusions |
US9104651B1 (en) | 2011-07-15 | 2015-08-11 | Scale Computing, Inc. | Techniques for distributing tests and test suites across a network |
US8949305B1 (en) | 2011-07-15 | 2015-02-03 | Scale Computing, Inc. | Distributed dynamic system configuration |
US10209768B1 (en) | 2012-01-06 | 2019-02-19 | Seagate Technology Llc | File-aware priority driver |
US9542324B1 (en) | 2012-04-05 | 2017-01-10 | Seagate Technology Llc | File associated pinning |
US9268692B1 (en) | 2012-04-05 | 2016-02-23 | Seagate Technology Llc | User selectable caching |
FR2989801B1 (en) * | 2012-04-18 | 2014-11-21 | Schneider Electric Ind Sas | METHOD FOR SECURE MANAGEMENT OF MEMORY SPACE FOR MICROCONTROLLER |
US9077665B1 (en) | 2012-05-24 | 2015-07-07 | Scale Computing, Inc. | Transferring virtual machines and resource localization in a distributed fault-tolerant system |
US9612914B1 (en) * | 2012-07-23 | 2017-04-04 | Veritas Technologies Llc | Techniques for virtualization of file based content |
US10019287B1 (en) | 2012-08-23 | 2018-07-10 | Scale Computing | Virtual machine resource display |
US10430216B1 (en) | 2012-08-23 | 2019-10-01 | Scale Computing Inc | Virtual machine automated selection |
US9965336B2 (en) * | 2014-04-30 | 2018-05-08 | International Business Machines Corporation | Delegating iterative storage unit access in a dispersed storage network |
US9405592B2 (en) * | 2014-05-16 | 2016-08-02 | Teradata Us, Inc. | Workload balancing to handle skews for big data analytics |
US10089611B1 (en) * | 2014-06-05 | 2018-10-02 | Amazon Technologies, Inc. | Sharing digital media |
US10296469B1 (en) * | 2014-07-24 | 2019-05-21 | Pure Storage, Inc. | Access control in a flash storage system |
US10430092B1 (en) * | 2014-07-28 | 2019-10-01 | Rambus Inc. | Memory controller systems with nonvolatile memory for storing operating parameters |
US9785427B2 (en) * | 2014-09-05 | 2017-10-10 | Oracle International Corporation | Orchestration of software applications upgrade using checkpoints |
US9740474B2 (en) | 2014-10-29 | 2017-08-22 | Oracle International Corporation | Orchestration of software applications upgrade using automatic hang detection |
US9753717B2 (en) | 2014-11-06 | 2017-09-05 | Oracle International Corporation | Timing report framework for distributed software upgrades |
US9880828B2 (en) | 2014-11-07 | 2018-01-30 | Oracle International Corporation | Notifications framework for distributed software upgrades |
KR20170057902A (en) * | 2015-11-17 | 2017-05-26 | 에스케이하이닉스 주식회사 | Memory system and operating method of memory system |
CN109891396A (en) * | 2017-01-27 | 2019-06-14 | 惠普发展公司,有限责任合伙企业 | Read operation redirects |
US10887357B2 (en) * | 2018-08-22 | 2021-01-05 | International Business Machines Corporation | Document collaboration tool |
Citations (94)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4575827A (en) * | 1984-05-18 | 1986-03-11 | International Business Machines Corporation | Self-archiving data recording |
US5285528A (en) * | 1991-02-22 | 1994-02-08 | International Business Machines Corporation | Data structures and algorithms for managing lock states of addressable element ranges |
US5329619A (en) * | 1992-10-30 | 1994-07-12 | Software Ag | Cooperative processing interface and communication broker for heterogeneous computing environments |
US5426427A (en) * | 1991-04-04 | 1995-06-20 | Compuserve Incorporated | Data transmission routing system |
US5463772A (en) * | 1993-04-23 | 1995-10-31 | Hewlett-Packard Company | Transparent peripheral file systems with on-board compression, decompression, and space management |
US5483652A (en) * | 1994-01-24 | 1996-01-09 | Digital Equipment Corporation | Mechanism for locating without search discrete application resources known by common name only in a distributed network computing environment |
US5513314A (en) * | 1995-01-27 | 1996-04-30 | Auspex Systems, Inc. | Fault tolerant NFS server system and mirroring protocol |
US5524247A (en) * | 1992-01-30 | 1996-06-04 | Kabushiki Kaisha Toshiba | System for scheduling programming units to a resource based on status variables indicating a lock or lock-wait state thereof |
US5566331A (en) * | 1994-01-24 | 1996-10-15 | University Corporation For Atmospheric Research | Mass storage system for file-systems |
US5721818A (en) * | 1996-01-25 | 1998-02-24 | Apple Computer, Inc. | Method and system for enabling a file server to service multiple networks of the same network protocol family by invoking multiple instances of a network session protocol |
US5774660A (en) * | 1996-08-05 | 1998-06-30 | Resonate, Inc. | World-wide-web server with delayed resource-binding for resource-based load balancing on a distributed resource multi-node network |
US5781550A (en) * | 1996-02-02 | 1998-07-14 | Digital Equipment Corporation | Transparent and secure network gateway |
US5812930A (en) * | 1996-07-10 | 1998-09-22 | International Business Machines Corp. | Information handling systems with broadband and narrowband communication channels between repository and display systems |
US5838916A (en) * | 1996-03-14 | 1998-11-17 | Domenikos; Steven D. | Systems and methods for executing application programs from a memory device linked to a server |
US5889942A (en) * | 1996-12-18 | 1999-03-30 | Orenshteyn; Alexander S. | Secured system for accessing application services from a remote station |
US5987523A (en) * | 1997-06-04 | 1999-11-16 | International Business Machines Corporation | Applet redirection for controlled access to non-orginating hosts |
US5987627A (en) * | 1992-05-13 | 1999-11-16 | Rawlings, Iii; Joseph H. | Methods and apparatus for high-speed mass storage access in a computer system |
US5999808A (en) * | 1995-12-12 | 1999-12-07 | Aeris Communications, Inc. | Wireless gaming method |
US6026474A (en) * | 1996-11-22 | 2000-02-15 | Mangosoft Corporation | Shared client-side web caching using globally addressable memory |
US6047307A (en) * | 1994-12-13 | 2000-04-04 | Microsoft Corporation | Providing application programs with unmediated access to a contested hardware resource |
US6085234A (en) * | 1994-11-28 | 2000-07-04 | Inca Technology, Inc. | Remote file services network-infrastructure cache |
US6128644A (en) * | 1998-03-04 | 2000-10-03 | Fujitsu Limited | Load distribution system for distributing load among plurality of servers on www system |
US6128690A (en) * | 1998-03-24 | 2000-10-03 | Compaq Computer Corporation | System for remote memory allocation in a computer having a verification table contains information identifying remote computers which are authorized to allocate memory in said computer |
US6167490A (en) * | 1996-09-20 | 2000-12-26 | University Of Washington | Using global memory information to manage memory in a computer network |
US6175869B1 (en) * | 1998-04-08 | 2001-01-16 | Lucent Technologies Inc. | Client-side techniques for web server allocation |
US6195678B1 (en) * | 1996-09-03 | 2001-02-27 | Fujitsu Limited | Remote resource management system for automatically downloading required files from application server depending on contents of selected files on requesting computer |
US6216202B1 (en) * | 1998-06-30 | 2001-04-10 | Emc Corporation | Method and apparatus for managing virtual storage devices in a storage system |
US20010011338A1 (en) * | 1998-08-26 | 2001-08-02 | Thomas J. Bonola | System method and apparatus for providing linearly scalable dynamic memory management in a multiprocessing system |
US6314465B1 (en) * | 1999-03-11 | 2001-11-06 | Lucent Technologies Inc. | Method and apparatus for load sharing on a wide area network |
US6317775B1 (en) * | 1995-11-03 | 2001-11-13 | Cisco Technology, Inc. | System for distributing load over multiple servers at an internet site |
US6327594B1 (en) * | 1999-01-29 | 2001-12-04 | International Business Machines Corporation | Methods for shared data management in a pervasive computing environment |
US6345300B1 (en) * | 1997-03-25 | 2002-02-05 | Intel Corporation | Method and apparatus for detecting a user-controlled parameter from a client device behind a proxy |
US6347095B1 (en) * | 1999-11-15 | 2002-02-12 | Pango Networks, Inc. | System, devices and methods for use in proximity-based networking |
US6356915B1 (en) * | 1999-02-22 | 2002-03-12 | Starbase Corp. | Installable file system having virtual file system drive, virtual device driver, and virtual disks |
US6360265B1 (en) * | 1998-07-08 | 2002-03-19 | Lucent Technologies Inc. | Arrangement of delivering internet protocol datagrams for multimedia services to the same server |
US6366988B1 (en) * | 1997-07-18 | 2002-04-02 | Storactive, Inc. | Systems and methods for electronic data storage management |
US6389432B1 (en) * | 1999-04-05 | 2002-05-14 | Auspex Systems, Inc. | Intelligent virtual volume access |
US6393569B1 (en) * | 1996-12-18 | 2002-05-21 | Alexander S. Orenshteyn | Secured system for accessing application services from a remote station |
US20020069245A1 (en) * | 2000-10-13 | 2002-06-06 | Han-Gyoo Kim | Disk system adapted to be directly attached to network |
US6404766B1 (en) * | 1995-12-29 | 2002-06-11 | Hitachi, Ltd. | Network data communication system |
US6421753B1 (en) * | 1997-12-31 | 2002-07-16 | Crossroads Systems, Inc. | Storage router and method for providing virtual local storage |
US6449647B1 (en) * | 1997-08-01 | 2002-09-10 | Cisco Systems, Inc. | Content-aware switching of network packets |
US6470389B1 (en) * | 1997-03-14 | 2002-10-22 | Lucent Technologies Inc. | Hosting a network service on a cluster of servers using a single-address image |
US20030014569A1 (en) * | 2001-07-16 | 2003-01-16 | Han-Gyoo Kim | Scheme for dynamically connecting I/O devices through network |
US6510164B1 (en) * | 1998-11-16 | 2003-01-21 | Sun Microsystems, Inc. | User-level dedicated interface for IP applications in a data packet switching and load balancing system |
US20030018403A1 (en) * | 1996-11-13 | 2003-01-23 | Braun Adam C. | Hybrid control of haptic feedback for host computer and interface device |
US20030028614A1 (en) * | 2001-08-02 | 2003-02-06 | Nexter Information & Technology Co., Ltd. | Portable storage media and method of utilizing remote storage unit on network as auxiliary memory of local computer by using the same |
US6518965B2 (en) * | 1998-04-27 | 2003-02-11 | Interactive Silicon, Inc. | Graphics system and method for rendering independent 2D and 3D objects using pointer based display list video refresh operations |
US6523066B1 (en) * | 1999-08-23 | 2003-02-18 | Harris-Exigent, Inc. | Dynamic distributed memory locking in a computer network |
US6529996B1 (en) * | 1997-03-12 | 2003-03-04 | Storage Technology Corporation | Network attached virtual tape data storage subsystem |
US6539446B1 (en) * | 1999-05-07 | 2003-03-25 | Oracle Corporation | Resource locking approach |
US6578111B1 (en) * | 2000-09-29 | 2003-06-10 | Sun Microsystems, Inc. | Cache memory system and method for managing streaming-data |
US6594677B2 (en) * | 2000-12-22 | 2003-07-15 | Simdesk Technologies, Inc. | Virtual tape storage system and method |
US6598068B1 (en) * | 1996-01-04 | 2003-07-22 | Sun Microsystems, Inc. | Method and apparatus for automatically managing concurrent access to a shared resource in a multi-threaded programming environment |
US6609178B1 (en) * | 2000-11-28 | 2003-08-19 | Emc Corporation | Selective validation for queued multimodal locking services |
US6609167B1 (en) * | 1999-03-17 | 2003-08-19 | Adaptec, Inc. | Host and device serial communication protocols and communication packet formats |
US20030172149A1 (en) * | 2002-01-23 | 2003-09-11 | Andiamo Systems, A Delaware Corporation | Methods and apparatus for implementing virtualization of storage within a storage area network |
US6647016B1 (en) * | 1998-12-11 | 2003-11-11 | Canon Kabushiki Kaisha | Communication control method, communication control apparatus, and storage medium |
US20030225981A1 (en) * | 2002-05-30 | 2003-12-04 | International Business Machines Corporation | Direct addressed shared compressed memory system |
US20030225961A1 (en) * | 2002-06-03 | 2003-12-04 | James Chow | Flash memory management system and method |
US20030225834A1 (en) * | 2002-05-31 | 2003-12-04 | Microsoft Corporation | Systems and methods for sharing dynamic content among a plurality of online co-users |
US20040068563A1 (en) * | 2002-10-08 | 2004-04-08 | International Business Machines Corporation | Method, system, and program for managing locks enabling access to a shared resource |
US6732166B1 (en) * | 1999-05-28 | 2004-05-04 | Intel Corporation | Method of distributed resource management of I/O devices in a network cluster |
US6732104B1 (en) * | 2001-06-06 | 2004-05-04 | Lsi Logic Corporatioin | Uniform routing of storage access requests through redundant array controllers |
US20040117813A1 (en) * | 2002-12-11 | 2004-06-17 | Jeyhan Karaoguz | Third party media channel access in a media exchange network |
US6760783B1 (en) * | 1999-05-21 | 2004-07-06 | Intel Corporation | Virtual interrupt mechanism |
US6807581B1 (en) * | 2000-09-29 | 2004-10-19 | Alacritech, Inc. | Intelligent network storage interface system |
US20040220933A1 (en) * | 2003-05-01 | 2004-11-04 | International Business Machines Corporation | Method, system, and program for managing locks and transactions |
US6823458B1 (en) * | 1999-11-18 | 2004-11-23 | International Business Machines Corporation | Apparatus and method for securing resources shared by multiple operating systems |
US6834326B1 (en) * | 2000-02-04 | 2004-12-21 | 3Com Corporation | RAID method and device with network protocol between controller and storage devices |
US20050042591A1 (en) * | 2002-11-01 | 2005-02-24 | Bloom Phillip Jeffrey | Methods and apparatus for use in sound replacement with automatic synchronization to images |
US6894981B1 (en) * | 1997-07-31 | 2005-05-17 | Cisco Technology, Inc. | Method and apparatus for transparently proxying a connection |
US20050110768A1 (en) * | 2003-11-25 | 2005-05-26 | Greg Marriott | Touch pad for handheld device |
US20050149682A1 (en) * | 2001-10-09 | 2005-07-07 | Han-Gyoo Kim | Virtual multiple removable media jukebox |
US20050193017A1 (en) * | 2004-02-19 | 2005-09-01 | Han-Gyoo Kim | Portable multimedia player/recorder that accesses data contents from and writes to networked device |
US20050193189A1 (en) * | 2004-02-17 | 2005-09-01 | Han-Gyoo Kim | Device and method for booting an operating system for a computer from a passive directly attached network device |
US6941576B2 (en) * | 1999-04-12 | 2005-09-06 | Texas Instruments Incorporated | System and methods for home network communications |
US20060004935A1 (en) * | 2004-06-30 | 2006-01-05 | Pak-Lung Seto | Multi-protocol bridge |
US20060045130A1 (en) * | 2004-07-22 | 2006-03-02 | Han-Gyoo Kim | Low-level communication layers and device employing same |
US7010303B2 (en) * | 2000-12-22 | 2006-03-07 | Research In Motion Limited | Wireless router system and method |
US20060069884A1 (en) * | 2004-02-27 | 2006-03-30 | Han-Gyoo Kim | Universal network to device bridge chip that enables network directly attached device |
US20060067356A1 (en) * | 2004-08-23 | 2006-03-30 | Han-Gyoo Kim | Method and apparatus for network direct attached storage |
US7069312B2 (en) * | 2002-12-06 | 2006-06-27 | Microsoft Corporation | Network location signature for disambiguating multicast messages in dual-IP stack and/or multi-homed network environments |
US7069350B2 (en) * | 2002-08-05 | 2006-06-27 | Seiko Epson Corporation | Data transfer control system, electronic instrument, and data transfer control method |
US7076690B1 (en) * | 2002-04-15 | 2006-07-11 | Emc Corporation | Method and apparatus for managing access to volumes of storage |
US20060155805A1 (en) * | 1999-09-01 | 2006-07-13 | Netkingcall, Co., Ltd. | Scalable server architecture based on asymmetric 3-way TCP |
US7124128B2 (en) * | 2003-06-17 | 2006-10-17 | International Business Machines Corporation | Method, system, and program for managing requests to tracks subject to a relationship |
US20070008988A1 (en) * | 2004-08-23 | 2007-01-11 | Han-Gyoo Kim | Enhanced network direct attached storage controller |
US7251704B2 (en) * | 2002-08-23 | 2007-07-31 | Intel Corporation | Store and forward switch device, system and method |
US7254578B2 (en) * | 2002-12-10 | 2007-08-07 | International Business Machines Corporation | Concurrency classes for shared file systems |
US7277955B2 (en) * | 2000-12-22 | 2007-10-02 | Verizon Corporate Services Group Inc. | Streaming content |
US7376133B2 (en) * | 2003-10-16 | 2008-05-20 | Alcatel-Lucent | System and method for providing communications in a network using a redundant switching architecture |
US7383229B2 (en) * | 2003-03-12 | 2008-06-03 | Yahoo! Inc. | Access control and metering system for streaming media |
US7584262B1 (en) * | 2002-02-11 | 2009-09-01 | Extreme Networks | Method of and system for allocating resources to resource requests based on application of persistence policies |
Family Cites Families (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE19610840C2 (en) | 1996-03-19 | 2000-04-13 | Siemens Ag | Method for loading electronic games onto a mobile communication terminal of a mobile communication network |
JPH10113469A (en) | 1996-10-09 | 1998-05-06 | Takeshi Horii | Method to play game opposing and cooperating through mobile communication device |
JPH10271562A (en) | 1997-03-25 | 1998-10-09 | Taito Corp | Mobile communication terminal capable of playing game |
JPH117404A (en) | 1997-06-17 | 1999-01-12 | Toshiba Corp | Network connection scsi device and file system using the device |
US6128295A (en) | 1997-07-11 | 2000-10-03 | Telefonaktiebolaget Lm Ericsson | Buffering of point-to-point and/or point-to-multipoint ATM cells |
JPH11114224A (en) | 1997-10-09 | 1999-04-27 | Hiroyuki Nakanishi | Communication type game system |
US6470397B1 (en) | 1998-11-16 | 2002-10-22 | Qlogic Corporation | Systems and methods for network and I/O device drivers |
KR20010016943A (en) | 1999-08-05 | 2001-03-05 | 윤종용 | Method for preforming network game function using potable phone |
KR20000072493A (en) | 2000-09-06 | 2000-12-05 | 임동희 | The method for using a PDA as a controling terminal for a PC on wireless internet. |
-
2004
- 2004-09-27 US US10/951,474 patent/US7457880B1/en active Active
-
2008
- 2008-10-21 US US12/255,433 patent/US20090043971A1/en not_active Abandoned
Patent Citations (95)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4575827A (en) * | 1984-05-18 | 1986-03-11 | International Business Machines Corporation | Self-archiving data recording |
US5285528A (en) * | 1991-02-22 | 1994-02-08 | International Business Machines Corporation | Data structures and algorithms for managing lock states of addressable element ranges |
US5426427A (en) * | 1991-04-04 | 1995-06-20 | Compuserve Incorporated | Data transmission routing system |
US5524247A (en) * | 1992-01-30 | 1996-06-04 | Kabushiki Kaisha Toshiba | System for scheduling programming units to a resource based on status variables indicating a lock or lock-wait state thereof |
US5987627A (en) * | 1992-05-13 | 1999-11-16 | Rawlings, Iii; Joseph H. | Methods and apparatus for high-speed mass storage access in a computer system |
US5329619A (en) * | 1992-10-30 | 1994-07-12 | Software Ag | Cooperative processing interface and communication broker for heterogeneous computing environments |
US5463772A (en) * | 1993-04-23 | 1995-10-31 | Hewlett-Packard Company | Transparent peripheral file systems with on-board compression, decompression, and space management |
US5566331A (en) * | 1994-01-24 | 1996-10-15 | University Corporation For Atmospheric Research | Mass storage system for file-systems |
US5483652A (en) * | 1994-01-24 | 1996-01-09 | Digital Equipment Corporation | Mechanism for locating without search discrete application resources known by common name only in a distributed network computing environment |
US6085234A (en) * | 1994-11-28 | 2000-07-04 | Inca Technology, Inc. | Remote file services network-infrastructure cache |
US6047307A (en) * | 1994-12-13 | 2000-04-04 | Microsoft Corporation | Providing application programs with unmediated access to a contested hardware resource |
US5513314A (en) * | 1995-01-27 | 1996-04-30 | Auspex Systems, Inc. | Fault tolerant NFS server system and mirroring protocol |
US6317775B1 (en) * | 1995-11-03 | 2001-11-13 | Cisco Technology, Inc. | System for distributing load over multiple servers at an internet site |
US5999808A (en) * | 1995-12-12 | 1999-12-07 | Aeris Communications, Inc. | Wireless gaming method |
US6404766B1 (en) * | 1995-12-29 | 2002-06-11 | Hitachi, Ltd. | Network data communication system |
US6598068B1 (en) * | 1996-01-04 | 2003-07-22 | Sun Microsystems, Inc. | Method and apparatus for automatically managing concurrent access to a shared resource in a multi-threaded programming environment |
US5721818A (en) * | 1996-01-25 | 1998-02-24 | Apple Computer, Inc. | Method and system for enabling a file server to service multiple networks of the same network protocol family by invoking multiple instances of a network session protocol |
US5781550A (en) * | 1996-02-02 | 1998-07-14 | Digital Equipment Corporation | Transparent and secure network gateway |
US5838916A (en) * | 1996-03-14 | 1998-11-17 | Domenikos; Steven D. | Systems and methods for executing application programs from a memory device linked to a server |
US5812930A (en) * | 1996-07-10 | 1998-09-22 | International Business Machines Corp. | Information handling systems with broadband and narrowband communication channels between repository and display systems |
US5774660A (en) * | 1996-08-05 | 1998-06-30 | Resonate, Inc. | World-wide-web server with delayed resource-binding for resource-based load balancing on a distributed resource multi-node network |
US6195678B1 (en) * | 1996-09-03 | 2001-02-27 | Fujitsu Limited | Remote resource management system for automatically downloading required files from application server depending on contents of selected files on requesting computer |
US6167490A (en) * | 1996-09-20 | 2000-12-26 | University Of Washington | Using global memory information to manage memory in a computer network |
US20030018403A1 (en) * | 1996-11-13 | 2003-01-23 | Braun Adam C. | Hybrid control of haptic feedback for host computer and interface device |
US6026474A (en) * | 1996-11-22 | 2000-02-15 | Mangosoft Corporation | Shared client-side web caching using globally addressable memory |
US6393569B1 (en) * | 1996-12-18 | 2002-05-21 | Alexander S. Orenshteyn | Secured system for accessing application services from a remote station |
US5889942A (en) * | 1996-12-18 | 1999-03-30 | Orenshteyn; Alexander S. | Secured system for accessing application services from a remote station |
US6529996B1 (en) * | 1997-03-12 | 2003-03-04 | Storage Technology Corporation | Network attached virtual tape data storage subsystem |
US6470389B1 (en) * | 1997-03-14 | 2002-10-22 | Lucent Technologies Inc. | Hosting a network service on a cluster of servers using a single-address image |
US6345300B1 (en) * | 1997-03-25 | 2002-02-05 | Intel Corporation | Method and apparatus for detecting a user-controlled parameter from a client device behind a proxy |
US5987523A (en) * | 1997-06-04 | 1999-11-16 | International Business Machines Corporation | Applet redirection for controlled access to non-orginating hosts |
US6366988B1 (en) * | 1997-07-18 | 2002-04-02 | Storactive, Inc. | Systems and methods for electronic data storage management |
US6894981B1 (en) * | 1997-07-31 | 2005-05-17 | Cisco Technology, Inc. | Method and apparatus for transparently proxying a connection |
US6449647B1 (en) * | 1997-08-01 | 2002-09-10 | Cisco Systems, Inc. | Content-aware switching of network packets |
US6421753B1 (en) * | 1997-12-31 | 2002-07-16 | Crossroads Systems, Inc. | Storage router and method for providing virtual local storage |
US6128644A (en) * | 1998-03-04 | 2000-10-03 | Fujitsu Limited | Load distribution system for distributing load among plurality of servers on www system |
US6128690A (en) * | 1998-03-24 | 2000-10-03 | Compaq Computer Corporation | System for remote memory allocation in a computer having a verification table contains information identifying remote computers which are authorized to allocate memory in said computer |
US6175869B1 (en) * | 1998-04-08 | 2001-01-16 | Lucent Technologies Inc. | Client-side techniques for web server allocation |
US6518965B2 (en) * | 1998-04-27 | 2003-02-11 | Interactive Silicon, Inc. | Graphics system and method for rendering independent 2D and 3D objects using pointer based display list video refresh operations |
US6216202B1 (en) * | 1998-06-30 | 2001-04-10 | Emc Corporation | Method and apparatus for managing virtual storage devices in a storage system |
US6360265B1 (en) * | 1998-07-08 | 2002-03-19 | Lucent Technologies Inc. | Arrangement of delivering internet protocol datagrams for multimedia services to the same server |
US20010011338A1 (en) * | 1998-08-26 | 2001-08-02 | Thomas J. Bonola | System method and apparatus for providing linearly scalable dynamic memory management in a multiprocessing system |
US6510164B1 (en) * | 1998-11-16 | 2003-01-21 | Sun Microsystems, Inc. | User-level dedicated interface for IP applications in a data packet switching and load balancing system |
US6647016B1 (en) * | 1998-12-11 | 2003-11-11 | Canon Kabushiki Kaisha | Communication control method, communication control apparatus, and storage medium |
US6327594B1 (en) * | 1999-01-29 | 2001-12-04 | International Business Machines Corporation | Methods for shared data management in a pervasive computing environment |
US6356915B1 (en) * | 1999-02-22 | 2002-03-12 | Starbase Corp. | Installable file system having virtual file system drive, virtual device driver, and virtual disks |
US6314465B1 (en) * | 1999-03-11 | 2001-11-06 | Lucent Technologies Inc. | Method and apparatus for load sharing on a wide area network |
US6609167B1 (en) * | 1999-03-17 | 2003-08-19 | Adaptec, Inc. | Host and device serial communication protocols and communication packet formats |
US6389432B1 (en) * | 1999-04-05 | 2002-05-14 | Auspex Systems, Inc. | Intelligent virtual volume access |
US6941576B2 (en) * | 1999-04-12 | 2005-09-06 | Texas Instruments Incorporated | System and methods for home network communications |
US6539446B1 (en) * | 1999-05-07 | 2003-03-25 | Oracle Corporation | Resource locking approach |
US6760783B1 (en) * | 1999-05-21 | 2004-07-06 | Intel Corporation | Virtual interrupt mechanism |
US6732166B1 (en) * | 1999-05-28 | 2004-05-04 | Intel Corporation | Method of distributed resource management of I/O devices in a network cluster |
US6523066B1 (en) * | 1999-08-23 | 2003-02-18 | Harris-Exigent, Inc. | Dynamic distributed memory locking in a computer network |
US20060155805A1 (en) * | 1999-09-01 | 2006-07-13 | Netkingcall, Co., Ltd. | Scalable server architecture based on asymmetric 3-way TCP |
US6347095B1 (en) * | 1999-11-15 | 2002-02-12 | Pango Networks, Inc. | System, devices and methods for use in proximity-based networking |
US6823458B1 (en) * | 1999-11-18 | 2004-11-23 | International Business Machines Corporation | Apparatus and method for securing resources shared by multiple operating systems |
US6834326B1 (en) * | 2000-02-04 | 2004-12-21 | 3Com Corporation | RAID method and device with network protocol between controller and storage devices |
US6807581B1 (en) * | 2000-09-29 | 2004-10-19 | Alacritech, Inc. | Intelligent network storage interface system |
US6578111B1 (en) * | 2000-09-29 | 2003-06-10 | Sun Microsystems, Inc. | Cache memory system and method for managing streaming-data |
US20020069245A1 (en) * | 2000-10-13 | 2002-06-06 | Han-Gyoo Kim | Disk system adapted to be directly attached to network |
US20060010287A1 (en) * | 2000-10-13 | 2006-01-12 | Han-Gyoo Kim | Disk system adapted to be directly attached |
US6609178B1 (en) * | 2000-11-28 | 2003-08-19 | Emc Corporation | Selective validation for queued multimodal locking services |
US7277955B2 (en) * | 2000-12-22 | 2007-10-02 | Verizon Corporate Services Group Inc. | Streaming content |
US7010303B2 (en) * | 2000-12-22 | 2006-03-07 | Research In Motion Limited | Wireless router system and method |
US6594677B2 (en) * | 2000-12-22 | 2003-07-15 | Simdesk Technologies, Inc. | Virtual tape storage system and method |
US6732104B1 (en) * | 2001-06-06 | 2004-05-04 | Lsi Logic Corporatioin | Uniform routing of storage access requests through redundant array controllers |
US20030014569A1 (en) * | 2001-07-16 | 2003-01-16 | Han-Gyoo Kim | Scheme for dynamically connecting I/O devices through network |
US20030028614A1 (en) * | 2001-08-02 | 2003-02-06 | Nexter Information & Technology Co., Ltd. | Portable storage media and method of utilizing remote storage unit on network as auxiliary memory of local computer by using the same |
US20050149682A1 (en) * | 2001-10-09 | 2005-07-07 | Han-Gyoo Kim | Virtual multiple removable media jukebox |
US20030172149A1 (en) * | 2002-01-23 | 2003-09-11 | Andiamo Systems, A Delaware Corporation | Methods and apparatus for implementing virtualization of storage within a storage area network |
US7584262B1 (en) * | 2002-02-11 | 2009-09-01 | Extreme Networks | Method of and system for allocating resources to resource requests based on application of persistence policies |
US7076690B1 (en) * | 2002-04-15 | 2006-07-11 | Emc Corporation | Method and apparatus for managing access to volumes of storage |
US20030225981A1 (en) * | 2002-05-30 | 2003-12-04 | International Business Machines Corporation | Direct addressed shared compressed memory system |
US20030225834A1 (en) * | 2002-05-31 | 2003-12-04 | Microsoft Corporation | Systems and methods for sharing dynamic content among a plurality of online co-users |
US20030225961A1 (en) * | 2002-06-03 | 2003-12-04 | James Chow | Flash memory management system and method |
US7069350B2 (en) * | 2002-08-05 | 2006-06-27 | Seiko Epson Corporation | Data transfer control system, electronic instrument, and data transfer control method |
US7251704B2 (en) * | 2002-08-23 | 2007-07-31 | Intel Corporation | Store and forward switch device, system and method |
US20040068563A1 (en) * | 2002-10-08 | 2004-04-08 | International Business Machines Corporation | Method, system, and program for managing locks enabling access to a shared resource |
US20050042591A1 (en) * | 2002-11-01 | 2005-02-24 | Bloom Phillip Jeffrey | Methods and apparatus for use in sound replacement with automatic synchronization to images |
US7069312B2 (en) * | 2002-12-06 | 2006-06-27 | Microsoft Corporation | Network location signature for disambiguating multicast messages in dual-IP stack and/or multi-homed network environments |
US7254578B2 (en) * | 2002-12-10 | 2007-08-07 | International Business Machines Corporation | Concurrency classes for shared file systems |
US20040117813A1 (en) * | 2002-12-11 | 2004-06-17 | Jeyhan Karaoguz | Third party media channel access in a media exchange network |
US7383229B2 (en) * | 2003-03-12 | 2008-06-03 | Yahoo! Inc. | Access control and metering system for streaming media |
US20040220933A1 (en) * | 2003-05-01 | 2004-11-04 | International Business Machines Corporation | Method, system, and program for managing locks and transactions |
US7124128B2 (en) * | 2003-06-17 | 2006-10-17 | International Business Machines Corporation | Method, system, and program for managing requests to tracks subject to a relationship |
US7376133B2 (en) * | 2003-10-16 | 2008-05-20 | Alcatel-Lucent | System and method for providing communications in a network using a redundant switching architecture |
US20050110768A1 (en) * | 2003-11-25 | 2005-05-26 | Greg Marriott | Touch pad for handheld device |
US20050193189A1 (en) * | 2004-02-17 | 2005-09-01 | Han-Gyoo Kim | Device and method for booting an operating system for a computer from a passive directly attached network device |
US20050193017A1 (en) * | 2004-02-19 | 2005-09-01 | Han-Gyoo Kim | Portable multimedia player/recorder that accesses data contents from and writes to networked device |
US20060069884A1 (en) * | 2004-02-27 | 2006-03-30 | Han-Gyoo Kim | Universal network to device bridge chip that enables network directly attached device |
US20060004935A1 (en) * | 2004-06-30 | 2006-01-05 | Pak-Lung Seto | Multi-protocol bridge |
US20060045130A1 (en) * | 2004-07-22 | 2006-03-02 | Han-Gyoo Kim | Low-level communication layers and device employing same |
US20060067356A1 (en) * | 2004-08-23 | 2006-03-30 | Han-Gyoo Kim | Method and apparatus for network direct attached storage |
US20070008988A1 (en) * | 2004-08-23 | 2007-01-11 | Han-Gyoo Kim | Enhanced network direct attached storage controller |
Cited By (81)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10878646B2 (en) | 2005-12-08 | 2020-12-29 | Smartdrive Systems, Inc. | Vehicle event recorder systems |
US9633318B2 (en) | 2005-12-08 | 2017-04-25 | Smartdrive Systems, Inc. | Vehicle event recorder systems |
US20160117872A1 (en) * | 2005-12-08 | 2016-04-28 | Smartdrive Systems, Inc. | Memory management in event recording systems |
US9226004B1 (en) * | 2005-12-08 | 2015-12-29 | Smartdrive Systems, Inc. | Memory management in event recording systems |
US9911253B2 (en) * | 2005-12-08 | 2018-03-06 | Smartdrive Systems, Inc. | Memory management in event recording systems |
US8880279B2 (en) * | 2005-12-08 | 2014-11-04 | Smartdrive Systems, Inc. | Memory management in event recording systems |
US20140098228A1 (en) * | 2005-12-08 | 2014-04-10 | Smart Drive Systems, Inc. | Memory management in event recording systems |
US20090157255A1 (en) * | 2005-12-08 | 2009-06-18 | Smart Drive Systems, Inc. | Vehicle Event Recorder Systems |
US8374746B2 (en) * | 2005-12-08 | 2013-02-12 | Smartdrive Systems, Inc. | Memory management in event recording systems |
US20090222163A1 (en) * | 2005-12-08 | 2009-09-03 | Smart Drive Systems, Inc. | Memory Management In Event Recording Systems |
US9691195B2 (en) | 2006-03-16 | 2017-06-27 | Smartdrive Systems, Inc. | Vehicle event recorder systems and networks having integrated cellular wireless communications systems |
US9942526B2 (en) | 2006-03-16 | 2018-04-10 | Smartdrive Systems, Inc. | Vehicle event recorders with integrated web server |
US9566910B2 (en) | 2006-03-16 | 2017-02-14 | Smartdrive Systems, Inc. | Vehicle event recorder systems and networks having integrated cellular wireless communications systems |
US9472029B2 (en) | 2006-03-16 | 2016-10-18 | Smartdrive Systems, Inc. | Vehicle event recorder systems and networks having integrated cellular wireless communications systems |
US9402060B2 (en) | 2006-03-16 | 2016-07-26 | Smartdrive Systems, Inc. | Vehicle event recorders with integrated web server |
US9208129B2 (en) | 2006-03-16 | 2015-12-08 | Smartdrive Systems, Inc. | Vehicle event recorder systems and networks having integrated cellular wireless communications systems |
US10404951B2 (en) | 2006-03-16 | 2019-09-03 | Smartdrive Systems, Inc. | Vehicle event recorders with integrated web server |
US9201842B2 (en) | 2006-03-16 | 2015-12-01 | Smartdrive Systems, Inc. | Vehicle event recorder systems and networks having integrated cellular wireless communications systems |
US20070219685A1 (en) * | 2006-03-16 | 2007-09-20 | James Plante | Vehicle event recorders with integrated web server |
US9545881B2 (en) | 2006-03-16 | 2017-01-17 | Smartdrive Systems, Inc. | Vehicle event recorder systems and networks having integrated cellular wireless communications systems |
US8996240B2 (en) | 2006-03-16 | 2015-03-31 | Smartdrive Systems, Inc. | Vehicle event recorders with integrated web server |
US11556518B2 (en) * | 2006-03-31 | 2023-01-17 | Amazon Technologies, Inc. | System and method for providing high availability data |
US20160179872A1 (en) * | 2006-03-31 | 2016-06-23 | Amazon Technologies, Inc. | System and Method for Providing High Availability Data |
US8468235B2 (en) | 2006-08-09 | 2013-06-18 | Intel Corporation | System for extranet security |
US20080040478A1 (en) * | 2006-08-09 | 2008-02-14 | Neocleus Ltd. | System for extranet security |
US20080040470A1 (en) * | 2006-08-09 | 2008-02-14 | Neocleus Ltd. | Method for extranet security |
US8769128B2 (en) | 2006-08-09 | 2014-07-01 | Intel Corporation | Method for extranet security |
US10339732B2 (en) | 2006-11-07 | 2019-07-02 | Smartdrive Systems, Inc. | Vehicle operator performance history recording, scoring and reporting systems |
US10053032B2 (en) | 2006-11-07 | 2018-08-21 | Smartdrive Systems, Inc. | Power management systems for automotive video event recorders |
US10682969B2 (en) | 2006-11-07 | 2020-06-16 | Smartdrive Systems, Inc. | Power management systems for automotive video event recorders |
US9761067B2 (en) | 2006-11-07 | 2017-09-12 | Smartdrive Systems, Inc. | Vehicle operator performance history recording, scoring and reporting systems |
US8989959B2 (en) | 2006-11-07 | 2015-03-24 | Smartdrive Systems, Inc. | Vehicle operator performance history recording, scoring and reporting systems |
US9554080B2 (en) | 2006-11-07 | 2017-01-24 | Smartdrive Systems, Inc. | Power management systems for automotive video event recorders |
US11623517B2 (en) | 2006-11-09 | 2023-04-11 | SmartDriven Systems, Inc. | Vehicle exception event management systems |
US9738156B2 (en) | 2006-11-09 | 2017-08-22 | Smartdrive Systems, Inc. | Vehicle exception event management systems |
US20080111666A1 (en) * | 2006-11-09 | 2008-05-15 | Smartdrive Systems Inc. | Vehicle exception event management systems |
US10471828B2 (en) | 2006-11-09 | 2019-11-12 | Smartdrive Systems, Inc. | Vehicle exception event management systems |
US8868288B2 (en) | 2006-11-09 | 2014-10-21 | Smartdrive Systems, Inc. | Vehicle exception event management systems |
US8296844B2 (en) | 2007-03-21 | 2012-10-23 | Intel Corporation | Protection against impersonation attacks |
US20080235794A1 (en) * | 2007-03-21 | 2008-09-25 | Neocleus Ltd. | Protection against impersonation attacks |
US20080235779A1 (en) * | 2007-03-22 | 2008-09-25 | Neocleus Ltd. | Trusted local single sign-on |
US8365266B2 (en) | 2007-03-22 | 2013-01-29 | Intel Corporation | Trusted local single sign-on |
US9183679B2 (en) | 2007-05-08 | 2015-11-10 | Smartdrive Systems, Inc. | Distributed vehicle event recorder systems having a portable memory data transfer system |
US9679424B2 (en) | 2007-05-08 | 2017-06-13 | Smartdrive Systems, Inc. | Distributed vehicle event recorder systems having a portable memory data transfer system |
US7774568B2 (en) * | 2007-08-13 | 2010-08-10 | Novell, Inc. | Clustered snapshots in networks |
US20090049259A1 (en) * | 2007-08-13 | 2009-02-19 | Sudhakar Gosukonda Naga Venkat | Clustered snapshots in networks |
US8474037B2 (en) * | 2008-01-07 | 2013-06-25 | Intel Corporation | Stateless attestation system |
US9497210B2 (en) | 2008-01-07 | 2016-11-15 | Intel Corporation | Stateless attestation system |
US20090178138A1 (en) * | 2008-01-07 | 2009-07-09 | Neocleus Israel Ltd. | Stateless attestation system |
US9342683B2 (en) | 2008-01-07 | 2016-05-17 | Intel Corporation | Stateless attestation system |
US20090307705A1 (en) * | 2008-06-05 | 2009-12-10 | Neocleus Israel Ltd | Secure multi-purpose computing client |
US8892820B2 (en) * | 2010-03-19 | 2014-11-18 | Netapp, Inc. | Method and system for local caching of remote storage data |
US20110231613A1 (en) * | 2010-03-19 | 2011-09-22 | Ober Robert E | Remote storage caching |
US20110231615A1 (en) * | 2010-03-19 | 2011-09-22 | Ober Robert E | Coherent storage network |
US8868846B2 (en) * | 2010-03-19 | 2014-10-21 | Netapp, Inc. | Method and system for maintaining data coherency across a network |
US9336139B2 (en) * | 2010-11-29 | 2016-05-10 | Cleversafe, Inc. | Selecting a memory for storage of an encoded data slice in a dispersed storage network |
US20120137091A1 (en) * | 2010-11-29 | 2012-05-31 | Cleversafe, Inc. | Selecting a memory for storage of an encoded data slice in a dispersed storage network |
US10237233B2 (en) * | 2011-08-30 | 2019-03-19 | Amazon Technologies, Inc. | Allocating identifiers with minimal fragmentation |
US20170195283A1 (en) * | 2011-08-30 | 2017-07-06 | Amazon Technologies, Inc. | Allocating identifiers with minimal fragmentation |
US8756380B2 (en) * | 2011-09-07 | 2014-06-17 | Kabushiki Kaisha Toshiba | Controlling access to a removable medium from a module and an external device |
US20130061015A1 (en) * | 2011-09-07 | 2013-03-07 | Kabushiki Kaisha Toshiba | Access control apparatus and access control system |
US9135116B1 (en) * | 2011-09-29 | 2015-09-15 | Emc Corporation | Cloud enabled filesystems provided by an agent which interfaces with a file system on a data source device |
US20130227225A1 (en) * | 2012-02-27 | 2013-08-29 | Nokia Corporation | Method and apparatus for determining user characteristics based on use |
US9728228B2 (en) | 2012-08-10 | 2017-08-08 | Smartdrive Systems, Inc. | Vehicle event playback apparatus and methods |
US20140365445A1 (en) * | 2013-06-11 | 2014-12-11 | Hon Hai Precision Industry Co., Ltd. | Server with file managing function and file managing method |
US10019858B2 (en) | 2013-10-16 | 2018-07-10 | Smartdrive Systems, Inc. | Vehicle event playback apparatus and methods |
US9501878B2 (en) | 2013-10-16 | 2016-11-22 | Smartdrive Systems, Inc. | Vehicle event playback apparatus and methods |
US10818112B2 (en) | 2013-10-16 | 2020-10-27 | Smartdrive Systems, Inc. | Vehicle event playback apparatus and methods |
US9610955B2 (en) | 2013-11-11 | 2017-04-04 | Smartdrive Systems, Inc. | Vehicle fuel consumption monitor and feedback systems |
US11260878B2 (en) | 2013-11-11 | 2022-03-01 | Smartdrive Systems, Inc. | Vehicle fuel consumption monitor and feedback systems |
US11884255B2 (en) | 2013-11-11 | 2024-01-30 | Smartdrive Systems, Inc. | Vehicle fuel consumption monitor and feedback systems |
US10497187B2 (en) | 2014-02-21 | 2019-12-03 | Smartdrive Systems, Inc. | System and method to detect execution of driving maneuvers |
US11250649B2 (en) | 2014-02-21 | 2022-02-15 | Smartdrive Systems, Inc. | System and method to detect execution of driving maneuvers |
US10249105B2 (en) | 2014-02-21 | 2019-04-02 | Smartdrive Systems, Inc. | System and method to detect execution of driving maneuvers |
US9594371B1 (en) | 2014-02-21 | 2017-03-14 | Smartdrive Systems, Inc. | System and method to detect execution of driving maneuvers |
US11734964B2 (en) | 2014-02-21 | 2023-08-22 | Smartdrive Systems, Inc. | System and method to detect execution of driving maneuvers |
US8892310B1 (en) | 2014-02-21 | 2014-11-18 | Smartdrive Systems, Inc. | System and method to detect execution of driving maneuvers |
US9663127B2 (en) | 2014-10-28 | 2017-05-30 | Smartdrive Systems, Inc. | Rail vehicle event detection and recording system |
US11069257B2 (en) | 2014-11-13 | 2021-07-20 | Smartdrive Systems, Inc. | System and method for detecting a vehicle event and generating review criteria |
US10930093B2 (en) | 2015-04-01 | 2021-02-23 | Smartdrive Systems, Inc. | Vehicle event recording system and method |
US10649856B2 (en) * | 2017-09-01 | 2020-05-12 | International Business Machines Corporation | Concurrent writing to a file during backup of the file |
Also Published As
Publication number | Publication date |
---|---|
US7457880B1 (en) | 2008-11-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7457880B1 (en) | System using a single host to receive and redirect all file access commands for shared data storage device from other hosts on a network | |
JP3704573B2 (en) | Cluster system | |
US7010554B2 (en) | Delegation of metadata management in a storage system by leasing of free file system blocks and i-nodes from a file system owner | |
US8285967B1 (en) | Method for on-demand block map generation for direct mapped LUN | |
US7552197B2 (en) | Storage area network file system | |
US6931450B2 (en) | Direct access from client to storage device | |
US7937453B1 (en) | Scalable global namespace through referral redirection at the mapping layer | |
US9405680B2 (en) | Communication-link-attached persistent memory system | |
US9031984B2 (en) | Providing multiple concurrent access to a file system | |
US7945726B2 (en) | Pre-allocation and hierarchical mapping of data blocks distributed from a first processor to a second processor for use in a file system | |
US8949557B2 (en) | File management method and hierarchy management file system | |
JP4568115B2 (en) | Apparatus and method for hardware-based file system | |
US7836018B2 (en) | Simultaneously accessing file objects through web services and file services | |
US20080005468A1 (en) | Storage array virtualization using a storage block mapping protocol client and server | |
JP2004110218A (en) | Virtual volume creation/management method for dbms | |
JP2001504616A (en) | System and method for providing highly available data storage using globally addressable memory | |
US20090112811A1 (en) | Exposing storage resources with differing capabilities | |
US8335903B2 (en) | Method and system for processing access to disk block | |
US8769196B1 (en) | Configuring I/O cache | |
JP2002312210A (en) | Method for providing disc array with file system access | |
US9934140B1 (en) | Allocating blocks in storage systems | |
KR100785774B1 (en) | Obeject based file system and method for inputting and outputting | |
US7533225B1 (en) | Method and apparatus for enabling adaptive endianness | |
CN117113380A (en) | Embedded virtual file system design method based on domestic operating system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: XIMETA TECHNOLOGY, INC., VIRGIN ISLANDS, BRITISH Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:KIM, HAN-GYOO;REEL/FRAME:021715/0445 Effective date: 20050107 |
|
AS | Assignment |
Owner name: PAK, ZHE KHI, RUSSIAN FEDERATION Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:XIMETA TECHNOLOGY, INC.;REEL/FRAME:022113/0815 Effective date: 20081212 |
|
AS | Assignment |
Owner name: LEE, HANS, KOREA, REPUBLIC OF Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:PAK, ZHE KHI;REEL/FRAME:032560/0155 Effective date: 20140129 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |
|
AS | Assignment |
Owner name: LEE, HEON SU, KOREA, REPUBLIC OF Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE ASSIGNEE NAME PREVIOUSLY RECORDED AT REEL: 032560 FRAME: 155. ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT;ASSIGNOR:PAK, ZHE KHI;REEL/FRAME:035736/0439 Effective date: 20140129 |