Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L12/00—Data switching networks
  • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
• • 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]
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication

Definitions

• the present invention relates to a distributed storage system, to a distributed storage management system and to a server for managing access to distributed storage.
• data files such as digital photographs
• a storage device such as a magnetic hard disk
• users increasingly want to be able to access their data remotely and even on-the-move.
• users may also want to share their data with other users.
• Distributed storage comprising more than one storage device and which is managed using a virtual file system can offer solutions to these problems.
• Storage devices can be added to provide additional capacity. Furthermore, to the user, it appears that their data is stored in a single, accessible "location", even though physically the data may be stored disparately across many storage devices, which may even change with time. Also, the user can grant access privileges to other users, such as friends or work colleagues, allowing them to read and even update his or her files. Conventional distributed storage systems using virtual file systems are known.
• US-A-5873085 describes a system having a plurality of servers, each server managing a respective file system and at least one server operating a virtual file management system.
• the virtual file management system includes a management table storing a virtual file identifier, a server name and a real file name for each virtual file. If a server receives a request from a client to read or modify a specified file and the server does not hold the file, then the server identifies which other server stores the file, modifies the request to instruct the other server to respond directly to the client and forwards the modified request to the other server.
• This system suffers the drawback that the servers also store data. This can limit the amount of the storage that can be added to any one server. Adding further servers can provide additional storage, but this is more expensive than simply adding additional storage devices.
• US-A-20050246393 describes a network storage system having a virtual file system and a storage cluster having a plurality of intelligent storage nodes and a plurality of control nodes (referred to also as “distributed object storage managers") for identifying and accessing an intelligent storage node storing a specified object file.
• Each distributed object storage manager maintains a lookup table identifying the location of object files stored in intelligent storage nodes and a state table storing information regarding the overall capacity and health of intelligent storage nodes.
• the state table is used to select an intelligent storage node to store a new object file.
• a load balancing fabric selects one of the distributed object storage managers based on availability and forwards the request to the selected distributed object storage manager. In turn, the distributed object storage manager selects an intelligent storage node.
• each distributed object storage manager is responsible for storing new object files. Thus, each distributed object storage manager only stores information about files for which they are responsible, at least initially. Thus, if a distributed object storage manager receives a request to access a given file for which they are not responsible, then they broadcast a request for the file to the intelligent storage nodes. Therefore, the intelligent storage nodes must be provided with sufficient processing capability to handle such requests. This makes it more difficult to add storage nodes.
• the present invention seeks to provide an improved server for managing access to distributed storage and, thus, an improved distributed storage system.
• a server for managing access to distributed storage comprising a plurality of storage devices, the server configured to communicate with at least one other server so as to determine which one of the servers selects a portion of distributed storage to be used when storing data.
• a single server controls storing of data which helps to avoid the problem of concurrent allocation of storage and to permit information about the data to be stored orderly in a single metadata server.
• the server may comprise a first controller for receiving a request to store data in the distributed storage from a client and a second controller for selecting the portion of the distributed storage to use when storing the data, the second controller configured to communicate with at least one other second controller so as to determine which one of the second controllers selects the portion of distributed storage to be used.
• the server may be configured, in response to a determination that another server is to select the portion of distributed storage to be used, to receive identity of the portion of the distributed storage from the other server and, in response to a determination that it is to select the portion of distributed storage to be used, to select the portion of distributed storage.
• the server may be configured to select one of the storage devices within the portion of the distributed storage.
• the server may further comprise a third controller for selecting one of the storage devices within the portion of distributed storage in response to an instruction from the second controller.
• the server may be configured, after the file has been stored in the one storage device, to cause the file to be replicated in other storage devices within the portion of the distributed storage.
• the server may be configured, after the file has been stored, to transmit information relating to the file to a metadata server.
• the server may be configured to receive a virtual file identifier corresponding to the file from the metadata server and to transmit the virtual file identifier to the client.
• the server may be configured, in response to a request to read or update a file, to transmit a request for information relating to the file to any one of at least one metadata server.
• At least one of the storage devices may be provided by a remote storage system, such as a storage access network.
• a distributed storage management system comprising a plurality of access managing servers and a metadata server for storing information about files stored in the distributed storage.
• the metadata server may be separate from the access-managing servers.
• the distributed storage management system may further comprise at least one further metadata server, wherein the access-managing servers are each configured to send information relating to files to the metadata server, but not to the at least one further metadata server.
• the access-managing servers may each be configured to send requests for information relating to files to any of the at least one further metadata server.
• a distributed storage system comprising a distributed file management system and distributed storage comprising a plurality of storage device.
• the storage devices may include plural types of storage device.
• a method of operating a server for managing access to distributed storage comprising a plurality of storage devices, the method comprising communicating with at least one other server so as to determine which one of the servers selects the portion of distributed storage to be used when storing data.
• the method may comprise receiving a request to store data in the distributed storage from a client.
• the method may comprise a first controller receiving the request to store data in the distributed storage and a second controller communicating with at least one other second controller so as to determine which one of the second controllers selects the portion of distributed storage to be used.
• the method may comprise determining that another server is to select the portion of distributed storage to be used and receiving identity of the portion of the distributed storage to be used from the other server.
• the method may comprise determining that the server is to select a portion of distributed storage to be used and selecting a portion of the distributed storage to be used.
• the method may comprise selecting one of the storage devices within the portion of the distributed storage to be used.
• the method may comprise storing the data in a selected portion of the distributed storage.
• the method may comprise, after the file has been stored in the one storage device, causing the file to be replicated in other storage devices within the portion of the distributed storage.
• the method may comprise transmitting information relating to the file to a metadata server after the file has been stored.
• the method may comprise receiving a virtual file identifier corresponding to the file from the metadata server and transmitting the virtual file identifier to the client.
• the method may further comprise receiving a request to read or update a file and transmitting a request for information relating to the file to any one of at least one metadata server.
• a computer program comprising instructions which, when executed by a computer, causes the computer to perform the method.
• a computer- readable medium storing the computer program.
• FIG. 1 is schematic diagram of a distributed storage system in accordance with the present invention
• Figure 2 illustrates a computer system for the servers shown in Figure 1 ;
• Figure 3 is a block diagram of a server for managing access to distributed storage
• Figure 4 is a block diagram of the system shown in Figure 1 ;
• Figures 5a and 5b illustrates a file writing process performed in the system shown in Figure 4;
• Figure 6 is a process flow diagram of a method of operating an allocation manager
• Figures 7a and 7b illustrates a file updating process performed in the system shown in Figure 4.
• Figure 8 illustrates a file reading process performed in the system shown in Figure 4.
• a distributed storage system 1 in accordance with the present invention is shown.
• Clients 2, 3, in this example a desktop personal computer 2 and a mobile telephone handset 3, can access the distributed storage system 1 over a communications network 4, such as the Internet.
• a communications network 4 such as the Internet.
• the network 4 may include a plurality of wireless and wired networks, including a public land mobile network (not shown) or a wireless local area network (not shown).
• the distributed storage system 1 includes first, second and third servers 5 l 3 5 2 , 5 3 for managing access to distributed storage (the servers 5 l 3 5 2 , 5 3 are hereinafter referred to as "file service providers").
• the system 1 may have fewer, e.g. one or two, or a greater number of file service providers.
• the file service providers 5 l3 5 2 , 5 3 communicate with storage devices 6 locally, such as a first storage device O 1 in the form of a hard disk drive provided by the third file service providers 5 3 , or remotely via the communications network 4 or via another communications network 7, such as an Intranet.
• a storage area network (SAN) 8 may provide a second storage device 6 2
• a network attached storage (NAS) 9 may provide a third storage device 6 3
• a file server 6 3 may provide a fourth storage device 6 4 .
• the number of storage devices 6 may differ.
• SAN 8 or NAS 9 can provide more than one storage device and/or more than one SAN or NAS may be provided, each providing at least one storage device 6.
• Other forms of systems providing storage devices 6 can be used, such as common internet file systems (CIFS) (not shown), optical disk (e.g. DVD) drives and USB drives may be used.
• CIFS common internet file systems
• DVD optical disk drives
• USB drives may be used.
• the number of storage devices 6 may change with time. For example, storage devices 6 may be added or removed. The arrangement of storage devices 6 may also change.
• the storage devices 6 collectively provide a single storage volume 26 ( Figure 4) and are arranged into clusters 27 ( Figure 4).
• the file service providers 5 communicate, via communications network 7, with a first metadata server H 1 and an optional second metadata server H 2 for mapping between a virtual file reference and a real file.
• the file service providers 5 can read and write metadata to and from the first metadata server H 1 .
• the file service providers 5 l 3 5 2 , 5 3 can only read metadata from the second metadata server H 2 .
• the first and second metadata servers H 1 , H 2 are hereinafter referred to as "active" and “passive" metadata servers H 1 , H 2 respectively.
• the active metadata server H 1 may copy metadata to the passive metadata server H 2 , for example periodically, on demand or in response to predetermined trigger. More than one passive metadata server H 2 may be provided.
• each metadata server H 1 , H 2 may be distributed between two or more servers.
• Each computer system 12 includes a processor 13, memory 14 and an input/output (I/O) interface 15 operatively connected by a bus 16.
• a computer system 12 may include more than one processor.
• the I/O interface 15 is operatively connected to a network interface 17, storage 18 in the form of a hard disc drive or drives and, optionally, removable storage 19.
• Other elements, including peripheral devices such as keyboards (not shown) and displays (not shown), may be temporarily or permanently provided.
• Computer program codes 2O 1 , 2O 2 which, when executed by a computer system 12, causes the computer system 12 to provide file service provider or metadata server processes are stored on the hard drive 18 and loaded into memory 14 for execution by the processor 13.
• the computer program codes 2O 1 , 2O 2 may be stored on and transferred from removable storage 19 or through network interface 17 from a remote source (not shown).
• each file service providers 5 includes a first service or controller 21 for interfacing with clients 2, 3, a second service or controller 22 for selecting a storage cluster 27 ( Figure 4), a third service or controller 23 for selecting a storage device 6 within a cluster 27 ( Figure 4), a fourth service or controller 24 for controlling replication of data within and between clusters 27 ( Figure 4) and a fifth service or controller 25 for interfacing with the metadata servers H 1 , H 2 .
• the first service 21 manages requests to access files, such as to write and read files, received from the clients 2, 3 and also manages other components shown in Figure 3.
• the first service 21 is herein referred to as a "file service manager".
• the second service 22 selects a cluster 27 ( Figure 4) when writing data and is herein referred to as an "allocation manager". As will be described in more detail later, the allocation manager 22 communicates with other allocation managers 22.
• One allocation manager 22 M ( Figure 4), referred to as the "master allocation manager”, is chosen to be responsible for selecting clusters 27 ( Figure 4), with the other allocations manager(s) 22 acting as proxies for the master allocation manager 22 M ( Figure 4).
• the chosen allocation manager 22 M can change.
• the third service 23 selects a storage device 6 and validates its availability.
• the third service 22 is referred to as a "cluster manager".
• the cluster manager 23 triggers replication of a filestream in one storage device 6 to other storage device(s) 6.
• the cluster manager 23 also distributes a read process between storage devices 6 to increase throughput.
• the cluster manager 23 also gathers data relating to client-to-storage device throughput. Throughput data can be used, during a writing or reading process, to select storage devices 6 having faster responses to clients 2, 3.
• the fourth service 24 is herein referred to as a "replication service”. As explained earlier, the replication service 24 controls replication of data within, and between, clusters 27 ( Figure 4). The cluster manager 23 logs replication transactions in case any of the storage devices 6 are not available.
• the fifth service 25 is herein referred to as a "metadata server interface".
• the metadata server interface 25 sends metadata, e.g. information about files, to the active metadata server H 1 and retrieves metadata from the active or passive metadata servers H 1 , H 2 -
• the storage devices 6 provide a single storage volume or storage space 26.
• Storage devices 6 are arranged into clusters 27 in which each storage device 6 stores the same data as another storage device 6 in the same cluster 27, i.e. the storage devices 6 in one cluster 27 are mirrors of one another. Only two clusters 27 are illustrated for clarity. In one cluster 27, the storage devices 6 have different access configurations, for example network addresses.
• Each file service provider 5 can access at least one storage device 6 in each cluster 27.
• the metadata servers H 1 , H 2 store first, second, third, fourth and fifth metadata tables 28, 29, 30, 31, 32.
• the metadata includes information for mapping virtual file references onto physical file references and attributes of files before filters (such as file compression and virus checks) are applied.
• the metadata also includes other information such as folder trees, folder content data and also access control lists for each file and folder.
• the first table 28 (hereinafter referred to as a "virtual file system entity table”) stores a virtual entity identifier 33, a cluster identifier 34, an entity type 35 for each entity, such as a file or directory, and a path in physical storage identifier 36.
• the second table 29 (hereinafter referred to as a "virtual file system access control list”) stores a virtual entity identifier 37 and an access list 38 for each entity and defines security privileges of users, i.e. client users.
• the virtual file system access control list 29 lists users who have access privilege to an entity, together with their set of access privileges in relation to the entity, such as read, write, create, delete and change privileges.
• Each request to access an entity sent by a client 2, 3 specifies the identity of a user. Therefore, each time a file service provider 5 receives a request to access a given entity, it interrogates the virtual file system access control list 29, for example by retrieving a portion of the list 29 relating to the entity and the user, to verify the user's access privilege.
• the third table 30 (hereinafter referred to as a "virtual file system entity sharing list”) stores a virtual entity identifier 39 and an access list 40 for each entity and defines access privileges for unregistered users (referred to as "share viewers") which are invited by registered users to share viewing of files.
• the virtual file system access control list 30 is similar to the virtual file system access control list 29 except that access privileges are usually limited, for example, to read only.
• Share viewers are identified and authenticated differently from registered users. Identification and authentication can be performed by external system(s) (not shown) having a trust relationship established with the distributed storage system 1.
• the virtual file system access control list 30 may be omitted, for example, if share viewers are not permitted to access the distributed storage system 1.
• the fourth table 31 (hereinafter referred to as a "logical cluster metadata table”) stores a (logical) cluster identifier 41 and (physical) storage device identifier 42 for each cluster 27.
• the logical cluster metadata table 31 allows a cluster manager 23 to identify storage devices 6 in a cluster 27.
• the fifth table 32 (hereinafter referred to as a "logical clusters relations table”) stores a first cluster identifier 43, a second cluster identifier 44 and a relationship type 45 for each cluster 27 and describes relationships between clusters 27.
• the logical clusters relations table 32 may specify that a first cluster 27 A is a replica (i.e. a mirror) of a second cluster 27 B .
• the logical clusters relations table 32 may specify that the first cluster 27 A is an archive for files stored in the second cluster 27 B , stored according to predefined criteria. An archive may contain rarely accessed files or files created before a specific date. Thus, a first cluster 27 A need not store files which are archived in a second cluster 27 B . Archived files may be stored in, for example, a tape storage system.
• the system 1 can be used to provide a file service to clients 2, 3. Requests and responses are exchanged sessionlessly and so different file service providers 5 can handle different requests from the same client 2, 3. Thus, file service providers 5 need not store any information about the state of the client 2, 3. Instead, the client 2, 3 can store information about its state and supply this information when sending a request to a file service provider 5. For example, a request may include authentication information needed to validate a user against access privileges stored in the virtual file system access control list 29.
• a client in this example the personal computer 2, sends a file write request 46 to the file service manager 21 of a file service provider 5 (step Wl).
• the file service provider 5 is selected according to a routing mechanism or by load balancers (not shown) in the network 4 ( Figure 1).
• the file write request 46 includes a file 47 to be written including file data 48 and file attributes 49, such as file type and file size.
• the file service manager 21 forwards a cluster allocation request 50 to the allocation manager 22 (step W2).
• the request 50 may include the file attributes 49 which may used to select a cluster 27.
• the master allocation manager 22 M selects a cluster 27, for example based on the file attributes 49 and/or cluster attributes and state (not shown), such as available space and percentage of utilization, or on some other basis, such round robin (step
• the allocation manager 22 determines whether it is the master allocation manager 22 M . If the allocation manager 22 is the master allocation manager 22 M , then it selects a cluster 27. If not, the allocation manager 22 forwards the request to the master allocation manager 22 M which allocates a cluster 27 and returns a cluster identifier.
• the allocation manger 22 invokes the cluster manager 23 with an instruction 51 to select a storage device 6 within the selected cluster 27 (step W4).
• the cluster manager 23 selects a storage device 6 (step W5).
• the cluster manager 23 makes the selection based on highest network availability between the file service manager 21 and storage devices 6. Network availability can be determined using network state information collected at predetermined times, e.g. periodically, by the allocation manager 22 and by the cluster manager 23.
• the cluster manager 23 sends an instruction 52 to the storage device 6 to create a filestream 53 having a given path in the storage device 6 (step W6).
• the storage device 6 creates a filestream 53 (step W7).
• a unique file handler is associated with the filestream 53 which points (with pointer P) to a first writable block in the filestream 53 in the storage device 6.
• the identity 54 of the file handler (which identifies the filestream 53) is returned to the cluster manager 23 (step W8).
• the cluster manager 23 returns the file handler identity 54, a path 55 and cluster identity 56 to the allocation manager 22 (step W9), which in turn returns the information to the file service manager 21 (step WlO).
• the file service manager 21 applies writing filters, such as compression and/or virus checking, to the file data 48 (step WI l) and writes filtered file data 57 to the open filestream 53 (step Wl 2).
• the filestream 53 is filled with filtered file data 57.
• the storage device advances the pointer P to point to the next available free block.
• the file service manager 21 sends an instruction 59 to the cluster manager 23 to close the filestream 53 (step Wl 3).
• the cluster manager 23 sends an instruction 60 to the storage device 6 to close the filestream 53 (step Wl 4).
• the storage device 6 writes an end of file (EOF) marker 61 to the filestream 52 (step Wl 5), frees the pointer and updates the storage system allocation table (not shown), such as a file allocation table provided by the storage device 6.
• EEF end of file
• the cluster manager 23 then triggers replication of the stored filestream 53 in other storage devices 6 in the same cluster 27 by sending an instruction (not shown) to the replication service 24 ( Figure 2) (step Wl 6).
• the file service manager 21, via metadata server interface 25, sends an instruction 62 to the metadata server H 1 to write metadata into the virtual file system entity table 28, virtual file system access control list 29, virtual file system entity sharing list table 30, logical cluster metadata table 31 and logical clusters relations table 32, as necessary (step Wl 7).
• the metadata server H 1 writes the file information (step Wl 8) and returns a virtual file identifier 63 to the file service manager 21 (step W19).
• the file service manager 21 sends confirmation 64 to the client 2 that the file has been written including the virtual file identifier 63 (step W20).
• the allocation manager 22 determines whether or not it is the master allocation manager 22 M . A process by which this is achieved will now be described in more detail.
• the allocation manager 22 receives a request 48 ( Figure 5a) to allocate a cluster 27 (step Sl).
• the allocation manager 22 checks whether the master allocation manager 22 M is known (step S2).
• the allocation manager 22 determines whether it is the master allocation manager 22 M (step S3). If so, then the allocation manager 22 processes the request and selects a cluster 27 as described earlier (step S4). If not, then the allocation manager 22 forwards the request to the master allocation manager 22 M (step S5). The allocation manager 22 receives a cluster identifier from the master allocation manager 22 M .
• the allocation manager 22 If the allocation manager 22 does not know the identity of the master allocation manager 22 M , then the allocation manager 22 sends a query 65 to the other allocation manager (s) 22 asking for the identity of the master (step S6).
• the allocation manager 22 waits for replies (step S7) and checks whether the query "times out", i.e. whether a response is received before a predetermined period elapses (step S8). If the allocation manager 22 receives a reply 66 before the query times out, then it stores the identity of the master allocation manager 22 M (step S 9) and forwards the request to the master allocation manager 22 M (step S5).
• step SI l If the allocation manager 22 does not receive any reply before the query times out, then it sends a message 67 asserting that it is the master (step SI l). The allocation manager 22 waits for objections (step SI l) and checks whether the message 67 times out (step S 12).
• the allocation manager 22 If the allocation manager 22 does not receive any objection before the request times out, then it records itself as the master allocation manager 22 M (step S 13) and processes the request to select a cluster (step S4).
• the allocation manager 22 If, however, the allocation manager 22 receives an objection 68, then it re-sends an identification query 65 to the other allocation managers 22 (step S6).
• the allocation manager 22 continuously listens for queries 65 and messages 67.
• a master allocation manager 22 M can be relegated if it receives a message 67 from another allocation manager 22 or if the file service provider 5 is de-activated, for example shut down.
• the file update process is similar to the file writing process described earlier.
• the allocation manager 22 frees space allocated to an older version of a file, allocates space to a newer version of the file and writes the newer version of the file, as if it were a newly created file.
• the client 2 sends a file update request 69 to the file service manager 21 of a file service provider 5 (step Ul).
• the file write request 69 includes an updated file 70, including a new file data 71 and new file attributes 72, and a virtual file identifier 73 for an old file, for example the previously stored file 47.
• the file service manager 21 sends a query 74 to the active metadata server H 1 to find out which cluster 27 the old file is stored (step U2). Alternatively, the file server manager 21 may send the query 74 to the passive metadata server H 2 .
• the active metadata server H 1 returns an old cluster identifier 75, a path 76 in the storage device 6 and old file attributes 77 (step U3).
• step U4 to U22 proceeds in a similar way to steps W2 to W20 of the writing process described earlier.
• the file service manager 21 forwards a cluster allocation request 78 to the allocation manager 22 (step U4) and the master allocation manager 22 M selects a cluster 27 (step U5).
• the allocation manger 22 sends an instruction 79 to select a storage device 6 within the selected cluster 27 (step U6).
• the cluster manager 23 selects a storage device 6
• step U7 The cluster manager 23 sends an instruction 80 to the storage device 6 to create a new filestream 81 having a given path in the storage device 6 (step U8).
• the storage device 6 creates a filestream 81 (step U9) and passes a new file handler identifier 82 to the cluster manager 23 (step UlO).
• the cluster manager 23 returns the new filestream 81, a corresponding path 83 and cluster identity 84 to the allocation manager 22 (step UI l).
• the allocation manager 22 forwards this information to the file service manager 21 (step U12).
• the file service manager 21 applies writing filters to the new file data 71 (step U 13) and writes a new filtered file data 85 to the open filestream 81 (step U14).
• the file service manager 21 sends an instruction 87 to the cluster manager 23 to close the filestream 81 (step Ul 5).
• the cluster manager 23 sends an instruction 88 to the storage device 6 to close the filestream 81 (step U16).
• the storage device 6 writes an end of file (EOF) marker
• step U17 frees the pointer and updates the storage device file system allocation table (not shown).
• the cluster manager 23 triggers replication of the filestream 81 in other storage devices 6 in the same cluster 27 by sending an instruction (not shown) to the replication service 24 (Figure 2) (step Ul 8).
• the metadata server H 1 writes the updated file information (step U20) and returns a new virtual file identifier 91 to the file service manager 21 (step U21).
• the file service manager 21 sends confirmation 92 to the client 2 that the file has been written (step U22).
• the file service manager 21 sends an instruction 93 to the cluster manager 23 to delete the old file (step U23).
• the cluster manager 22 finds the storage device 6 storing the old filestream (step U24) and sends an instruction 94 to the storage device 6 to delete the old filestream (step U25).
• the cluster manager 23 triggers replication of the storage device 6 (step U26).
• the client 2 sends a file read request 95 to the file service manager 21 of a file service provider 5 (step Rl).
• the file read request 95 includes a virtual file identifier 96 for a file, for example the previously stored file 42 or the updated file 68.
• the file service manager 21 sends a query 97 to the passive metadata server H 2 to find out which cluster 27 the file is stored (step R2).
• the file server manager 21 may send the query 97 to the active metadata server H 1 .
• the passive metadata server H 2 returns a cluster identifier 98, a path 99 in the storage device 6 and file attributes 100 (step R3).
• the file service manager 21 sends a request 101 to the cluster manager 23 to select a storage device 6 (step R4).
• the cluster manager 23 selects a storage device 6 within the cluster 27 identified by the cluster identifier 98 according to highest network availability (step R5) and sends and instruction 102 to the storage device 6 to open a filestream 103 (steps R6). If the cluster manager 23 fails to access the storage device 6, then it refers to the logical cluster relationship table 32 to determine if the cluster 27 is mirrored or archived. If so, the cluster manager 23 sends a new instruction (not shown) to another storage device 6.
• the storage device 6 retrieves file data 104 from the filestream 99 and forwards it to the cluster manager 23 (step R7).
• the cluster manager 23 passes the file data 104 to file service manager 21 (step R8).
• the file service manager 21 applies reading filters to the file data 104 (step R9) and forwards a filtered filestream 105 to the client 2 (step RlO).
• a user may grant access privileges to other users, referred to as "share viewers".
• the user can grant access privileges to a share viewer and notify the share viewer of the location of a file or folder by e-mailing or texting a message to the share viewer which includes a link, for example in the form of a uniform resource locator (URL) which identifies a file service provider 5 and the virtual file, for accessing the file or folder.
• the share viewer selects the link, thereby sending a request to the file service provider 5 to retrieve the file or folder.
• URL uniform resource locator
• the system 1 hereinbefore described can be used to provide a file service regardless of storage infrastructure. It can provide distributed file input and output over a consolidated storage space with pluggable stream handling over redundant sites.
• the file service can be provided by mobile telephone network providers to users having mobile telephone handsets, by technology integrators and by companies.
• the system 1 decouples file metadata from file data and unites real file systems, i.e. storage devices, so that they appear as a single storage unit. This can help to minimise or circumvent storage device limitations, such as storage capacity, storage device throughput and so on.
• the system 1 can handle filestreams and need not divide filestreams into blocks for handling.

Priority Applications (3)

Applications Claiming Priority (4)

Publications (1)

Family

ID=38269044

Family Applications (1)

Country Status (3)

Cited By (12)

Families Citing this family (1)

Citations (4)

Family Cites Families (6)

• 2007
  • 2007-04-13 WO PCT/EP2007/053657 patent/WO2007134918A1/en active Application Filing
  • 2007-04-13 KR KR1020087028408A patent/KR101366220B1/ko not_active IP Right Cessation
  • 2007-04-13 JP JP2009511432A patent/JP5584910B2/ja not_active Expired - Fee Related

Patent Citations (4)

Also Published As

Similar Documents

Legal Events