WO2014174578A1 - エッジサーバ及び記憶制御方法 - Google Patents

エッジサーバ及び記憶制御方法 Download PDF

Info

Publication number
WO2014174578A1
WO2014174578A1 PCT/JP2013/061798 JP2013061798W WO2014174578A1 WO 2014174578 A1 WO2014174578 A1 WO 2014174578A1 JP 2013061798 W JP2013061798 W JP 2013061798W WO 2014174578 A1 WO2014174578 A1 WO 2014174578A1
Authority
WO
WIPO (PCT)
Prior art keywords
file
directory
edge server
home
core
Prior art date
Application number
PCT/JP2013/061798
Other languages
English (en)
French (fr)
Inventor
邦仁 松木
荒井　仁
信之 雜賀
昌忠 高田
Original Assignee
株式会社日立製作所
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 株式会社日立製作所 filed Critical 株式会社日立製作所
Priority to PCT/JP2013/061798 priority Critical patent/WO2014174578A1/ja
Priority to US14/349,616 priority patent/US9286318B2/en
Publication of WO2014174578A1 publication Critical patent/WO2014174578A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
    • G06F11/2056—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant by mirroring
    • G06F11/2084—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant by mirroring on the same storage unit
    • 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/18—File system types
    • G06F16/182—Distributed file systems
    • G06F16/1824—Distributed file systems implemented using Network-attached Storage [NAS] architecture
    • G06F16/183—Provision of network file services by network file servers, e.g. by using NFS, CIFS
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • 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]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2097—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements maintaining the standby controller/processing unit updated

Definitions

  • the present invention relates to storage control in a file server system having a plurality of file servers.
  • Patent Document 1 discloses a remote (for example, back-end) file server (hereinafter, core server) and a local (for example, front-end) file server (hereinafter, edge server) connected to the core server via a communication network. There is a description about.
  • a user of an edge server reads a file from the core server to the edge server via the communication network, and updates the read file in the edge server.
  • the edge server then copies the updated file from the edge server to the core server and stubs the file in the edge server. That is, file migration from the edge server to the core server is performed. Thereafter, when the user accesses a stub (stubbed file), the edge server reads the file corresponding to the stub from the core server.
  • the “core space” is a file system (name space) of the core server
  • the “home directory” is a file system (name space) used by the user of the edge server.
  • the first edge server cannot read the file corresponding to the stub in the first home directory from the core space.
  • the user can use the second home directory of the second edge server corresponding to the core space corresponding to the first home directory instead of the first home directory.
  • the user can obtain the file before the updated file is updated from the core space through the second home directory, and update the file.
  • the second edge server migrates the updated file from the second home directory to the core space.
  • the first edge server can migrate the updated file that has not been migrated from the first home directory to the core space.
  • the file ancestor return in the core space is not limited to the case where there is a communication failure between the first edge server and the core server, but before the updated file in the first home directory is copied to the core space. It can also occur in other cases where the second home directory is used instead of, and then the first home directory is used instead of the second home directory.
  • an object of the present invention is to prevent the file from being turned over and to provide the user with the latest file.
  • the first edge server that provides the first home directory performs a securing process to prevent the first file in the first home directory from overwriting the second file in the core space, and copies the update of the first home directory to the core space.
  • the second file is a file updated in the second home directory of the second edge server and copied to the core space.
  • the first file corresponds to the second file and is a file that has been updated in the first home directory and has not been copied to the core space.
  • the first file may be a file having the same identification information as the second file (for example, UUID (Universally Unique Identifier)).
  • FIG. 1 illustrates a hardware configuration of the entire file server system according to the first embodiment.
  • FIG. 2 illustrates a software configuration of the entire file server system according to the first embodiment.
  • FIG. 3 shows an inode management table.
  • FIG. 4 shows the relationship between the inode with the inode number “100” in the inode management table in FIG. 3 and the file position.
  • FIG. 5 is a schematic diagram for explaining an example of the cause of the file ancestor return in the core space in the comparative example of the first embodiment.
  • FIG. 6 is a schematic diagram illustrating an example of a flow from the occurrence of a network failure to the recovery of the network failure in the first embodiment.
  • FIG. 1 illustrates a hardware configuration of the entire file server system according to the first embodiment.
  • FIG. 2 illustrates a software configuration of the entire file server system according to the first embodiment.
  • FIG. 3 shows an inode management table.
  • FIG. 4 shows the relationship between the inode with the inode number “100” in
  • FIG. 7 is a schematic diagram illustrating a part of a schematic example of processing performed when a network failure is recovered in the first embodiment.
  • FIG. 8 is a schematic diagram illustrating the remainder of an outline example of processing performed when a network failure is recovered in the first embodiment.
  • FIG. 9 shows a rename list and an update list in the first embodiment.
  • FIG. 10 is a flowchart of the login process.
  • FIG. 11 is a flowchart of the write process.
  • FIG. 12 is a flowchart of the migration process.
  • FIG. 13 is a flowchart of home directory recovery processing.
  • FIG. 14 is a flowchart of migration recovery processing according to the first embodiment.
  • FIG. 10 is a flowchart of the login process.
  • FIG. 11 is a flowchart of the write process.
  • FIG. 12 is a flowchart of the migration process.
  • FIG. 13 is a flowchart of home directory recovery processing.
  • FIG. 14 is a flowchart of migration recovery processing according
  • FIG. 15 is a schematic diagram illustrating an example of a flow from the occurrence of a network failure to the recovery of the network failure in the second embodiment.
  • FIG. 16 is a schematic diagram illustrating a part of a schematic example of processing performed when a network failure is recovered in the second embodiment.
  • FIG. 17 shows a rename list and an update list in the second embodiment.
  • FIG. 18 is a flowchart of migration recovery processing according to the second embodiment.
  • FIG. 19 is a schematic diagram illustrating an example of a flow from the occurrence of a network failure to the recovery of the network failure in the third embodiment.
  • FIG. 20 is a schematic diagram illustrating a part of a schematic example of processing performed when a network failure is recovered in the third embodiment.
  • FIG. 21 is a schematic diagram illustrating a part of an outline example of processing performed when a network failure is recovered in the third embodiment.
  • FIG. 22 shows a rename list and an update list in the third embodiment.
  • FIG. 23 is a flowchart of migration recovery processing according to the third embodiment.
  • FIG. 24 shows that a plurality of home directories in a plurality of file servers in the first embodiment correspond to the same core space.
  • xxx table various types of information may be described using the expression “xxx table”, but the various types of information may be expressed using a data structure other than a table. In order to show that it does not depend on the data structure, the “xxx table” can be called “xxx information”.
  • the process may be described with “program” as the subject, but the program is executed by a processor (for example, a CPU (Central Processing Unit)) so that a predetermined process can be appropriately performed. Since the processing is performed using a storage resource (for example, a memory) and / or a communication interface device (for example, a communication port), the subject of processing may be a processor.
  • the processing described with the program as the subject may be processing performed by a file server (for example, an edge server or a core server described later).
  • the processor may include a hardware circuit that performs part or all of the processing performed by the processor.
  • the computer program may be installed on each computer from a program source.
  • the program source may be, for example, a program distribution server or a storage medium.
  • FIG. 1 shows a hardware configuration of the entire file server system according to the first embodiment.
  • the file server system includes an edge 100 and a core 200.
  • the edge 100 and the core 200 are connected to each other via the communication network 1.
  • the edge 100 is a base including a local computer system, for example, a base where a user actually performs business such as a branch or a sales office.
  • the core 200 is a base that includes a remote computer system, for example, a base that collectively manages servers and storage devices or a base that provides cloud services.
  • the number of cores 200 is one, but the number of cores 200 may be plural.
  • the present invention relates to the same core space (core system) in a plurality of home directories (file system spaces for users) possessed by a plurality of edge servers 120 at a plurality of edges 100 regardless of whether the core 200 is singular or plural.
  • the present invention can be applied to all file server systems associated with the file system space (name space) provided by the core server 220 in the 200.
  • client or host 130 connected to the edge server 120 may be connected to the edge server 120.
  • client / host 130 may be connected to a plurality of edge servers 120 via one or a plurality of communication networks.
  • the edge 100 includes a RAID system 110, an edge server 120, and a client / host 130.
  • the edge server 120 is an example of a file server at the edge 100 (for example, a file storage device), and is connected to the client / host 130 via a communication network (for example, a LAN (Local Area Network)). Further, the edge server 120 is connected to the RAID system 110 via, for example, a communication network (for example, SAN (Storage Area Network)).
  • a communication network for example, SAN (Storage Area Network)
  • the RAID system 110 is roughly divided into a controller unit and a storage unit.
  • the controller unit includes a CHA (Channel Adapter) 111 and a storage controller (hereinafter ST-CTL) 112.
  • the storage unit includes a DISK 113.
  • a CHA 111 and a DISK 113 are connected to the ST-CTL 112.
  • the CHA 111 is a communication interface device connected to the edge server 120.
  • the ST-CTL 112 is a controller.
  • the DISK 113 is a disk-type physical storage device (for example, HDD (Hard Disk Drive)).
  • HDD Hard Disk Drive
  • the RAID system 110 includes a single DISK 113, but the RAID system 110 actually includes a plurality of DISKs 113.
  • a plurality of DISKs 113 may constitute one or more RAID groups.
  • the RAID system 110 receives the block level I / O request transmitted from the edge server 120 by the CHA 111 and executes I / O to the appropriate DISK 113 based on the control of the ST-CTL 112.
  • the edge server 120 includes a memory 121, a CPU (Central Processing Unit) 122, a NIC (Network Interface Card) 123, and an HBA (Host Bus Adapter) 124.
  • a CPU 122 is connected to the memory 121, the NIC 123, and the HBA 124.
  • the NIC 123 is a communication interface device that communicates with the core server 220 and the client / host 130.
  • the plurality of NICs 123 respectively included in the plurality of edge servers 120 may communicate with the same core server 220 through the plurality of communication networks 1.
  • the HBA 124 is a communication interface device that communicates with the RAID system 110.
  • the memory 121 is a storage area (for example, RAM (Random Access Memory) or ROM (Read Only Memory)) that can be directly read and written by the CPU 122.
  • the edge server 120 reads a program (for example, OS (Operating System)) for controlling the edge server 120 on the memory 121 and causes the CPU 122 to execute the program.
  • the edge server 120 may have another type of storage resource in addition to or instead of the memory 121.
  • the edge server 120 receives a file level I / O request from the client / host 130 via the NIC 123.
  • the edge server 120 creates an I / O request (block level I / O request) for the I / O of the data block constituting the file specified by the I / O request.
  • the edge server 120 transmits a block level I / O request to the RAID system 110 via the HBA 124.
  • the client / host 130 is a computer and includes a memory 131, a CPU 132, a NIC 133, and a DISK 134.
  • the client / host 130 may have other types of storage resources in addition to or instead of the memory 131 and / or the DISK 134.
  • the client / host 130 reads a program stored in the DISK 134 (a program (such as an OS) for controlling the client / host 134) onto the memory 131 and causes the CPU 132 to execute the program.
  • the client / host 130 transmits a file level I / O request to the edge server 120 via the NIC 133.
  • the core 200 includes a RAID system 210 and a core server 220.
  • the RAID system 210 is connected to the core server 220 via, for example, a communication network.
  • the RAID system 210 includes a CHA 211, an ST-CTL 212, and a DISK 213.
  • the configuration of the RAID system 210 and the configuration of the RAID system 110 are substantially the same. Therefore, the RAID system 210 can also receive the block level I / O request transmitted from the core server 220 by the CHA 211 and execute the I / O to the appropriate DISK 213 based on the control of the ST-CTL 212. .
  • the configuration of the RAID system 210 and the configuration of the RAID system 110 may be different.
  • the core server 220 is an example (for example, an archive device) of a file server in the core 200, and includes a memory 221, a CPU 222, a NIC 223, and an HBA 224. Instead of or in addition to the memory 221, another type of storage resource may be provided.
  • the core server 220 reads a program (for example, OS) for controlling the core server 220 on the memory 221 and causes the CPU 222 to execute the program.
  • the core server 220 communicates with the edge server 120 via the NIC 223 and the communication network 1.
  • the core server 220 is connected via the HBA 224 and performs access in block units.
  • one core server 220 is connected to a plurality of physical or logical communication networks 1 to which a plurality of edge servers 120 are respectively connected.
  • the communication network may be common to the plurality of edge servers 120.
  • FIG. 2 shows a software configuration of the entire file server system according to the first embodiment.
  • the RAID system 110 has a plurality of LUs (Logical Units) 1100 (2100).
  • the LU 1100 (2100) is a logical storage device.
  • the LU 1100 (2100) may be a substantive LU based on one or more DISKs 113 (213), may be a virtual LU according to Thin Provisioning, and external storage resources are determined according to storage virtualization technology. It may be an LU generated by being virtualized.
  • the LU 1100 (2100) is composed of a plurality of blocks (storage areas). A file is stored in the LU 1100 (2100).
  • the LU 1100 (2100) may store all or part of file system information described later.
  • the memory 121 of the edge server 120 (the memory 221 of the core server 220) stores a control program 1210 (2210), a file system 1211 (2211), and a kernel / driver 1212 (2212).
  • the memory 121 of the edge server 120 further stores a file sharing program 1213.
  • the control program in the edge server 120 is referred to as an “edge control program”
  • the control program in the core server 220 is referred to as a “core control program”.
  • Files are exchanged between the edge server 120 and the core server 220 via the edge control program 1210 and the core control program 2210.
  • the edge control program 1210 reads the file to be copied from the LU 1100 of the RAID system 110 and transfers the read file to the core server 220.
  • the core control program 2210 receives the file to be copied from the edge server 120 and writes the received file to the LU 2100 of the RAID system 210.
  • the edge control program 1210 deletes the copied file (strictly speaking, the entity) in the LU 1100 when a predetermined condition is satisfied, thereby realizing substantial migration of the copied file. To do.
  • the edge control program 1210 receives a read request from the client / host 130 for the stub (metadata) of the deleted file
  • the edge control program 1210 receives the file linked to the stub via the core control program 2210.
  • the file is acquired from the LU 2100 and the acquired file is transmitted to the client / host 130.
  • the “stub” is an object (metadata) associated with file storage location information (information indicating a link destination).
  • the client / host 130 does not know whether the file is a file or a stub.
  • the file system 1211 (2211) is a file system program and manages file system information.
  • the file system information includes information regarding each file (for example, information indicating the size and location of the file).
  • the file system information includes an inode management table 300 shown in FIG.
  • the inode management table 300 is composed of a plurality of inodes (one line corresponds to one inode).
  • Each inode is composed of a plurality of metadata.
  • the types of metadata include file owner, file access right, file size, file storage position (data block addresses 1, 2, 3,...), And the like.
  • the file is composed of data stored in the following blocks (blocks in the LU).
  • the kernel / driver 1212 (2121) is responsible for general control and hardware-specific operations such as schedule control of multiple programs (processes) operating on the edge server 120 (core server 220) and handling of interrupts from hardware. Take control.
  • the file sharing program 1213 is a program that provides a file sharing service with the client / host 130 using a communication protocol such as CIFS (Common Internet File System) and NFS (Network File System).
  • CIFS Common Internet File System
  • NFS Network File System
  • an application 1310 In the memory 131 of the client / host 130, an application 1310, a file system 1311, and a kernel / driver 1312 are stored.
  • the application 1310 is software (application program) used by the client / host 130 according to the purpose of work.
  • the file system 1311 and the kernel / driver 1312 are substantially the same as the file system 1211 (2211) and the kernel / driver 1212 (2212) described above.
  • FIG. 24 shows that a plurality of home directories in a plurality of edge servers in the first embodiment correspond to the same core space.
  • Edge servers 1 and 2 (120) have home directories 1 and 2 (168).
  • the home directory 1 (2) is a file system space (name space) for users possessed by the edge server 1 (2).
  • the edge server 1 (2) provides the home directory 1 (2) to the client / host 1 (2) used by the user.
  • the client / host 1 (2) adds a file to the home directory 1 (2), updates a file in the home directory 1 (2), or deletes a file from the home directory 1 (2). Can do.
  • a plurality of home directories 1 and 2 are associated with one core space 268.
  • the core space 268 is a file system space (name space) for home directories that the core server 220 has. Since home directories 1 and 2 are associated with one core space, they may be identified as the same home directory by the user. However, for convenience of explanation, these home directories are distinguished.
  • the home server 1 When the home server 1 is updated by the edge server 1 (addition of a file, update of a file, deletion of a file), the update is reflected in the core space 268, and the update of the core space 268 by the reflection is updated by the edge server 2 Are reflected in the home directory 2, and the home directory 2 is thereby updated.
  • the file X is added to the home directory 1, the file X is migrated from the home directory 1 to the core space 268, and the file X is copied from the core space 268 to the home directory 2.
  • the update of the home directory 2 (addition of a file, update of a file, deletion of a file) by the edge server 2 is reflected in the core space 268, and the update of the core space 268 by the reflection is reflected in the home directory of the edge server 1. 1 and the home directory 1 is thereby updated.
  • the file X in the home directory 2 is updated, the updated file X is migrated from the home directory 2 to the core space 268, and the updated file X is copied from the core space 268 to the home directory 1. .
  • At least one edge server 120 may have the local directory 167 separately from the home directory 168.
  • the local directory 167 is a file system space in which the file system space (name space) 267 of the core server 220 corresponds only to itself.
  • the update performed in the local directory 167 may be reflected only in the file system space (name space included in the core server 220) 267 corresponding to the local directory 167.
  • the memory 121 of the edge server 120 stores a rename list and an update list, respectively.
  • the rename list and the update list in the edge server 120 exist for each home directory that the edge server 120 has.
  • the rename list is a list of pre-update path names and post-update path names for paths updated in the home directory 168.
  • the rename list 1301 ⁇ / b> A that the edge server 1 corresponds to the home directory 1 (and the rename list that the edge server 2 does not illustrate) includes “FM” for each updated path. "And” TO ". “FM” indicates a path name before update (path structure), and “TO” indicates a path name after update.
  • path names (path structures) that have not been reflected (migrated) after being updated are recorded.
  • the core server 220 assigns a UUID (Universally Unique Identifier) as file identification information to a file in the core space.
  • UUID Universally Unique Identifier
  • the UUID of the file in the core space is provided to the edge servers 1 and 2 having the home directories 1 and 2 corresponding to the core space.
  • the edge servers 1 and 2 can specify the UUID of the file from the file path name.
  • the edge servers 1 and 2 cannot specify the path name of the file from the UUID of the file.
  • the update list is a list of identification information of files updated in the home directory 168.
  • the identification information is, for example, a path name.
  • the update list 1302A of the edge server 1 corresponding to the home directory 1 (also in the update list 1302B of the edge server 2) is included in the home directory 1 (2).
  • the path names of files that have been updated but not migrated to the core space are registered.
  • the update list records the pathnames of files that have not been migrated to the core space since they were updated.
  • the rename list 1301A and the update list 1302A are transmitted to the core server 220.
  • the file 220 is migrated from the home directory 2 to the core space, and the update list 1302B (and a rename list not shown) is transmitted from the edge server 2 to the core server 220.
  • the update list 1302B (and rename list) is stored in the memory 221. Thereafter, the update list 1302B (and the rename list) is in an initial state (for example, blank), and when the home directory 2 is updated, at least one of the update list 1302B and the rename list is updated.
  • the edge server 1 (2) uses the update list of at least the rename list and the update list received from the core server 220 to receive the updated file in the home directory 2 (1). It can be determined whether or not it is in the core space. In this embodiment, a file ancestor, that is, a file updated in the home directory 2 (1) and migrated to the core space is overwritten with an old file updated in the home directory 1 (2) in the past. Will not occur. A sequential number is associated with each of the update list and the rename list, and the edge server increments the sequential number of each list by 1 each time the update list and the rename list are transmitted to the core server.
  • FIG. 5 is a schematic diagram for explaining an example of the cause of the file ancestor return in the core space in the comparative example of the present embodiment.
  • this comparative example it is assumed that the home directory 1 of the edge server 1 and the home directory 2 of the edge server 2 are associated with one core space.
  • the edge server 1 permits the user to log in to the home directory 1. Then, the edge server 1 locks the core space. As a result, an edge server other than the edge server 1 cannot write a file to the core space (but can read a file from the core space). With the core space locked, the edge server 1 reads at least a file desired by the user (hereinafter referred to as an old file T) from the core space to the home directory 1 and updates the read old file T to the new file T1. . At this time, the edge server 1 has not migrated the new file T1 to the core space.
  • an old file T a file desired by the user
  • the core server issues an inquiry as to whether or not to periodically extend the lock (hereinafter referred to as an extension inquiry) to the edge server that is locked.
  • an extension inquiry the edge server answers to the core server whether or not to extend the lock.
  • a failure occurs in the communication network between the edge server 1 and the core server (hereinafter referred to as the first communication network).
  • the core server cannot receive an answer to the extended inquiry from the edge server 1.
  • the core server releases the lock applied to the core space by the edge server 1.
  • the failure of the communication network is mentioned as described above. Even if a failure of at least one of the server and the core server) occurs, the edge server 1 may not receive an extended inquiry from the core server, or the core server may not receive an answer to the extended inquiry from the edge server 1. .
  • the edge server 1 cannot migrate the new file T1 to the core space.
  • the user moves relative to the edge server 2 from the edge server 1. Specifically, the user logs out from the home directory 1 and logs into the edge server 2.
  • the edge server 2 locks the core space via a communication network (second communication network) connecting the edge server 2 and the core server. As a result, a file cannot be written to the core space from an edge server other than the edge server 2.
  • the edge server 2 reads the file T from the core space to the home directory 2. That is, the file read to the edge server 2 here is the file (old file) T before being updated in the edge server 1. This is because the new file T1 of the edge server 1 is not migrated to the core space due to the failure of the first communication network that occurs before the new file T1 is migrated to the core space. After reading the old file T, the edge server 2 updates the read old file T.
  • the file T updated by the edge server 2 is referred to as the latest file T2.
  • the edge server 2 migrates the latest file T2 to the core space. Thereafter, the user logs out from the home directory 2. When the user logs out from the home directory 2, the core server releases the lock that the edge server 2 holds on the core space. This is because when the user logs out from the home directory 2, the edge server 2 replies that the extension is not extended in response to the extension inquiry from the core server. In response to the reply that the core server does not extend, the core server releases the lock on the core space.
  • the edge server 1 migrates the new file T1 from the home directory 1 to the core space.
  • a contrivance is made to avoid such an ancestor turnover.
  • the tree structures in the frame of edge 1, core, and edge 2 are the tree structures of home directory 1, core space, and home directory 2, respectively.
  • the directory type icon indicates a home directory or a directory in the core space.
  • the file type icon indicates a file (or a stub corresponding to the file).
  • a white star indicates an update or addition in the home directory 1.
  • a black star indicates an update or addition in the home directory 2.
  • the updated directory is a directory to which a lower file or a lower directory has been added or a directory from which a lower file or a lower directory has been deleted.
  • Subordinate files” and “subordinate directories” of a directory are files or directories that are subordinate to the directory and that can be directly accessed from the target directory (without going through another directory). is there.
  • the key mark in the edge server means that the lock flag is turned on for the home directory
  • the key mark in the core server means that the core space is locked.
  • the edge server turns on the lock flag for the home directory corresponding to the core space in order for the edge server to recognize that the core space has been locked. As a result, the edge server can determine that the core server is locked without inquiring whether or not the core server is locked in the core space.
  • the edge server 1 has locked the core space, and as the lists 1301A and 1302A show (see FIG. 9), the path name “/ Assume that “A / C” is updated to the path name “/ A / D / C”, and the files “X” and “G” are updated.
  • the user logs out from the home directory 1 and logs in to the home directory 2, and the core space is unlocked.
  • the tree structure of the home directory 2 is the first communication network. This is the same as the tree structure of the core space at the time of failure.
  • the edge server 2 locks the core space, and in the home directory 2, the lower file “Y” is added to the directory “B”, and the lower file “G” in the directory “C”. Is updated. Accordingly, the edge server 2 records “/ A / C / G”, “/ A / B / Y”, and “/ A / B” in the update list 1302B (see the lower part of FIG. 6 and FIG. 9).
  • the edge server 2 migrates the updated files “Y” and “G” in the home directory 2 to the core space. Further, the edge server 2 transmits the update list 1302B and rename list (not shown) of the home directory 2 to the core server. As a result, as shown in the lower part of FIG. 6 and FIG. 9, the core server receives and has an update list 1302B and a rename list (not shown) of the home directory 2.
  • Triggered by the edge server 1 detecting recovery of a failure in the first communication network (or triggered by detection of a predetermined event that occurs regardless of whether the failure of the first communication network is recovered) 7 and 8 are performed.
  • the processing of the edge server may be performed by executing the edge control program, and the processing of the core server is performed by executing the core control program. Good.
  • Step 1 The edge server 1 determines whether an update list 1302B or a rename list from another edge server exists in the core server. In other words, the edge server 1 determines whether or not the core space has been updated by another Internet server 2.
  • the edge server 1 acquires these lists, and acquires the acquired lists and the lists 1301A and 1302A that the edge server 1 has. You may compare. From the comparison, it can be seen whether there is a file (hereinafter referred to as a conflict file) that causes an ancestor return in the core space when the update (addition, deletion, or update) of the home directory 1 is reflected in the core space. If it is determined that there is a conflict file in the core space, the determination result in step 1 may be true, and if it is determined that there is no conflict file in the core space, the determination result in step 1 may be false.
  • a conflict file a file that causes an ancestor return in the core space when the update (addition, deletion, or update) of the home directory 1 is reflected in the
  • Step 2 If the determination result in step 1 is true, the edge server 1 adds the first directory to a predetermined position in the tree structure of the home directory 1. Specifically, for example, the edge server 1 adds a directory having a directory name “hidden” as a lower directory of the root directory. Then, the edge server 1 moves all files and directories below the root directory of the home directory 1 before adding the “hidden” directory to the created “hidden” directory while maintaining the tree structure. Thereby, the user using the edge server 1 can determine that the files under the “hidden” directory are the files and directories in the home directory 1 before the failure occurs in the first communication network. The edge server 1 may hide at least the “hidden” directory from the “hidden” directory and the “conflict” directory from the client / host 1.
  • Step 3 The edge server 1 copies all the subordinate directories and subordinate files of the root directory of the core space to a predetermined position of the home directory 1 (for example, subordinate to the root directory).
  • the edge server 1 reads the directory or file to be accessed from the core space to the home directory 1 every time the client / host 1 is accessed from the root directory of the home directory 1 to the lower level via the lower directory. it can.
  • the edge server 1 may create stubs for all directories and files under the root directory of the core space under the root directory of the home directory 1.
  • Step 4 The edge server 1 adds a second directory at a predetermined position in the tree structure of the home directory 1. Specifically, for example, the edge server 1 adds a directory having a directory name “conflict” as a lower directory of the root directory. The edge server 1 moves the file specified from the update list 1302A from the “hidden” directory to the “conflict” directory while maintaining the path structure. Then, the edge server 1 migrates the “conflict” directory to the core space, and transmits the rename list and the update list to the core server.
  • a “conflict” directory is added, and a file with a path name “B / X” and a file with a path name “D / C / G” are added below the “conflict” directory. I understand that.
  • the edge server 1 does not migrate the “hidden” directory to the core space, but may migrate the “hidden” directory to the core space.
  • Step 5 The core space and home directory 2 are synchronized.
  • the term “synchronization” here means that files and directories having a difference from the home directory 2 in the core space are read from the core space to the home directory 2.
  • a file is added to the home directory 2 from the core space, a file in the home directory 2 is overwritten by a file in the core space, or a file is deleted from the home directory 2.
  • the edge server 2 acquires the rename list and update list of the core space from the core server, and compares these lists with the rename list and update list of the home directory 2 to thereby obtain “conflict”. ”Directory and its subordinate files.
  • the edge server 2 reads the “conflict” directory and its lower files to the home directory 2.
  • the user who uses the edge server 2 determines that the file in the “conflict” directory is an updated file using an edge server other than the edge server 2 before a failure occurs in the first communication network. Can do.
  • the user who uses the edge server 2 can copy or move only an arbitrary file among the files in the “conflict” directory to the outside of the “conflict” directory.
  • the edge server 1 will be described as an example.
  • the processing performed by the edge server 1 can be similarly performed by the other edge servers existing in the file server system according to the present embodiment.
  • the processing performed by the edge server may be performed by executing the edge control program
  • the processing performed by the core server may be performed by executing the core control program.
  • FIG. 10 is a flowchart of the login process.
  • the login process is performed by the edge server 1 when the edge server 1 receives a login request for the home directory.
  • the login destination is the home directory 1.
  • the edge server 1 determines whether the core space associated with the home directory 1 is locked by itself (whether the lock is valid or invalid) (S601). Specifically, for example, the edge server 1 transmits a lock file acquisition request corresponding to the core space corresponding to the login destination home directory 1 to the core server 220 having the core space. .
  • the core server 220 has a lock file for each core space in the memory 221.
  • the core server 220 sends a lock file corresponding to the core space specified in the request to the request transmission source.
  • the edge server 1 receives the lock file and determines whether or not the node number of the edge server 1 is recorded in the lock file.
  • the edge server 1 determines whether there is an update of the home directory 1 (S602). Whether there is an update of the home directory 1 is determined based on the rename list and the update list of the home directory 1.
  • the edge server 1 locks the core space (S603). Specifically, for example, the edge server 1 transmits a lock file acquisition request specifying a core space corresponding to the login destination home directory 1 to the core server 220. The core server transmits a lock file corresponding to the core space designated by the request to the edge server 1. The edge server 1 receives the lock file. If the node number of any edge server is not recorded in the lock file, the edge server 1 records the node number of the edge server 1 in the lock file and transmits the lock file to the core server 220. As a result, the lock is applied.
  • the edge server 1 When the lock could not be applied (for example, when the node number of another edge server is already recorded in the lock file) (S604: No), the edge server 1 reads Read-only (that is, about the home directory 1). Notifies the user (client / host 1 of the login request source) that the user only permits reading (S610). This is because the core space is locked by another edge server, and the edge server 1 cannot migrate the file to the core space even if a new file is written in the home directory 1.
  • the lock extension process is started (S605). Specifically, as described with reference to FIG. 5, the edge server 1 periodically receives a lock extension inquiry from the core server 220 and determines whether or not to extend the lock each time the inquiry is received. Will come to answer.
  • the edge server 1 performs file synchronization processing (S606). Specifically, the edge server 1 reads a file in the core space that is different from the file in the home directory 1 from the core space to the home directory 1. As a result, the file in the home directory 1 is overwritten by the file read from the core space. If there is no file to be synchronized in the core space, S606 is skipped.
  • the edge server 1 turns on the lock flag corresponding to the home directory 1 (S607).
  • the lock flag is an example of a tool for the edge server 1 to recognize that the edge server 1 has locked the core space.
  • the edge server 1 After S607, the edge server 1 notifies the user (login request source client / host 1) of the RW (that is, the read / write is possible) (S608).
  • S607 and S608 are performed. Although the lock is released after the migration is performed, in the case of S601: Yes, for example, after the user logs out from the home directory 1, the user is again in the home directory before the migration from the home directory 1 is performed. A case of logging in to 1 is considered.
  • FIG. 7 is a flowchart of the write process.
  • the write process is performed when the edge server 1 receives a write request from the client / host 1.
  • the “write” mentioned here may be any of update, addition and deletion of a file, may be a change of a file or directory pathname, and may be an update of file metadata.
  • the write is a file write, specifically, a file update or a new write.
  • the edge server 1 receives a file write request specifying the home directory 1 from the client / host 1 (S701).
  • the edge server 1 determines whether or not the lock flag of the home directory 1 specified by the received write request is on (S702).
  • the edge server 1 If the determination result in S702 is true (S702: Yes), the edge server 1 writes a file in the home directory 1 in accordance with the write request (S711). Further, the edge server 1 updates the update list 1302A or the rename list 1301A corresponding to the home directory 1.
  • the edge server 1 has an elapsed time (elapsed time from the time recorded in S713 described later) after the process of locking the core space has failed. It is determined whether a predetermined time (for example, 10 minutes) has elapsed (S703). The reason why the predetermined time is provided is that the edge server 1 avoids the process of frequently locking the core space and reflects the update in a lump.
  • the edge server 1 responds to the client / host 1 with an error (Read-Only) (S714).
  • the edge server 1 determines whether there is an update of the home directory 1 (S704).
  • S704 is specifically the same processing as S602 in FIG. Since S704 is performed when S703 is Yes, the load on the edge server 1 is reduced as compared with the case where it is performed every time No in S702.
  • the edge server 1 performs migration recovery processing (S712). Thereafter, the edge server 1 proceeds to the process of S706.
  • the edge server 1 performs a process of locking the core space (S705).
  • S706 to S709 corresponding to S604 to S607 in FIG. 10 are performed.
  • the edge server 1 records the time when the process of S705 was performed recently in a storage area such as a memory (S713).
  • the edge server 1 determines whether or not the target file (the file opened by the edge server 1 in this write process (that is, the file to be updated)) is a synchronized file from another edge server ( S710).
  • the edge server 1 overwrites the target file with the file according to the write request (S711).
  • the edge server 1 responds with an error (Read-Only) (S714). This is because the contents of the target file are different from the contents recognized by the client / host 1 when the write request is transmitted.
  • the edge server 1 records the time when the processing of S705 is started (S713). Thereafter, the edge server performs the process of S714.
  • FIG. 12 is a flowchart of the migration process.
  • Migration process is a process that is started periodically, but may be started when a specific event occurs.
  • the edge server 1 acquires a list of users logged out from the home directory (logout user list) for each home directory of the edge server 1 (S801).
  • the edge server 1 sorts the acquired logout user list according to a predetermined rule for each home directory of the edge server 1 (S802).
  • the edge server 1 determines whether or not migration has been performed for all home directories included in the edge server 1 (S803).
  • the edge server 1 locks the corresponding core space by itself for one home directory that is not the target of the processing after S804 in this migration processing. It is determined whether or not (S804).
  • the edge server 1 determines whether there is an update of the home directory 1 (S805).
  • the edge server 1 migrates the files specified from the rename list and the update list of the home directory 1 to the core space, and transmits these lists to the core server. (S810).
  • the edge server 1 determines whether or not the user using the home directory 1 that is the migration target in S810 is logged out (S811).
  • the file in the home directory 1 may be updated by the user, so the edge server 1 performs the process in S803.
  • the edge server 1 turns off the lock flag corresponding to the home directory (S806).
  • the edge server 1 When there is a lock extension inquiry from the core server 220, the edge server 1 replies that the lock is not extended (S807). The edge server 1 requests the core server 220 to delete its node number from the lock file (S808). After that, the edge server 1 performs the process of S803 and determines whether there is another home directory that has not been migrated.
  • FIG. 13 is a flowchart of home directory recovery processing.
  • the home directory recovery processing of the edge server 1 is performed when a specific event such as replacement of the edge server 1, reboot of the edge server 1, or failover from another edge server to the edge server 1 occurs.
  • the edge server 1 determines whether recovery processing has been performed for all home directories (S901).
  • the edge server 1 determines whether there is an update of the home directory for one of the home directories for which recovery processing has not been performed (S901: No). S902).
  • the edge server 1 performs migration recovery processing (S903).
  • the edge server 1 acquires the core space rename list and update list from the core server 220 (S904).
  • the edge server 1 checks the sequential numbers associated with the rename list and the update list, and determines whether the sequential numbers are consecutive (S905).
  • the edge server 1 can perform synchronization by reading the file from the core space to the home directory (S906).
  • the edge server 1 performs a restore process for copying all files in the core space to the home directory (S907).
  • FIG. 14 is a flowchart of migration recovery processing according to the present embodiment.
  • the edge server 1 determines whether the lock of the core space corresponding to the home directory 1 is valid by the same method as S601 in FIG. 10 (S1401).
  • the edge server 1 performs the processes in S1405 to S1408. That is, the lock extension process is started (S1405).
  • the edge server 1 turns on the lock flag corresponding to the home directory 1 (S1406).
  • the edge server 1 performs the migration process of FIG. 12 (S1408). Note that the migration process may not be performed. This is because the migration process is performed periodically.
  • the edge server 1 determines whether there are update lists and rename lists from other edge servers (S1402). For example, the edge server 1 inquires of the core server whether there is an update list or a rename list from another edge server for the core space. If there is an update list or rename list from another edge server for the core space, the core server transmits the list to the edge server 1. If both lists are present, both lists are sent.
  • the edge server 1 locks the core space (S1403). If the lock can be applied, S1405 to S1408 are performed.
  • the edge server 1 determines whether the core space is locked by another edge server (S1409). This determination is a determination as to whether or not the node number of another edge server is described in the lock file acquired for the core space.
  • the edge server 1 moves all files and directories below the root directory of the current home directory to the “hidden” directory (S1410) (step 2 in FIG. 7). reference).
  • the edge server 1 copies at least the lower directory (and lower files) of the root directory among the files and directories under the root directory of the core space to the root directory of the home directory 1 (S1411) (FIG. 7). Step 3). That is, the edge server 1 restores a directory (and file) below the root directory of the core space to the home directory 1.
  • the edge server 1 After that, the edge server 1 generates a “conflict” directory as a subordinate directory of the root directory of the home directory 1, and among the files and directories below the “hidden” directory, files specified from the rename list 1301A and the update list 1302A The directory is copied to the “conflict” directory (S1412) (see step 4 in FIG. 8).
  • the files and directories in the home directory 1 that are different from the files and directories in the core space are copied to the “conflict” directory, and the “conflict” directory is migrated to the core space.
  • Example 2 will be described. At that time, differences from the first embodiment will be mainly described, and description of common points with the first embodiment will be omitted or simplified. Specifically, the main difference between the first and second embodiments is the migration recovery process, and therefore the migration recovery process according to the second embodiment will be mainly described below.
  • the edge server 2 records “/ A / B / G”, “/ A / B / Y”, and “/ A / B” in the update list 1302B of the home directory 2 (FIG. 15 lower row and FIG. 15). 17).
  • the edge server 2 migrates the updated file “Y” and the moved file “G” in the home directory 2 to the core space. In addition, the edge server 2 transmits the update list 1302B (and rename list) of the home directory 2 to the core server. As a result, as shown in the lower part of FIG. 15 and FIG. 17, the core server receives and has the update list 1302B (and rename list) of the home directory 2.
  • Step 1 In step 1, processing similar to that performed in step 1 of FIG. 7 is performed.
  • Step 2 If the determination result in step 1 is true (when it is determined in step 1 that there is a rename list or update list 1302B), the edge server 1 synchronizes the home directory 1 with the core space. That is, the edge server 1 reads the update files “Y” and “G” (files specified from the update list 1302B of the core space) into the home directory 1 in the core space. As a result, the latest files “Y” and “G” are merged under the directory “B”. Regarding the file “G”, the edge server 1 has a file “G” as a subordinate file of the directory “C” in the home directory 1 according to the UUID specified from the path name, although the path name is different, but the directory “B”.
  • the edge server 1 deletes the path name of the file “G” from the update list 1302A of the home directory 1. This is to prevent the old file “G” in the home directory 1 from being migrated to the core space in the subsequent step 3. If the path name of the update file “G” is the same in the home directory 1 and the core space and the file “G” is read from the core space, the edge server 1 stores the update file “G” in the home directory 1. Compare the update time (time stamp in the metadata) with the update time (time stamp in the metadata) of the update file “G” in the core space, and overwrite the old file “G” with the new file “G”. become. That is, in the example of FIG. 16, since the path names are different, the file “G” coexists in the home directory 1, but if the path names are the same, a new file “G” exists instead of the old file “G”. become.
  • Step 3 The edge server 1 migrates the update file “X” (file specified from the update list 1302A) that is not stored in the core space to the core space.
  • the subordinate file “G” in the directory “D” is also an update file, but as described above, the path name of the file “G” is deleted from the update list 1302A (the file “G” from the core space Therefore, the edge server 1 does not migrate the lower file “G” of the directory “D” to the core space. Further, as described above, in the case of migration, the edge server 1 transmits the rename list 1301A and the update list 1302A to the core server.
  • the core server updates the path “/ A / C” to the path “/ A / D / C” based on the rename list 1301A (and the update list 1302A), and the latest file as a subordinate file of the directory “C”.
  • Migration processing reflecting home directory updates to the core space
  • synchronization processing reflecting core space updates to the home directory
  • the directory structure of the home directory 2 becomes the same as the directory structure of the core space in step 3.
  • FIG. 18 is a flowchart of migration recovery processing according to the second embodiment.
  • S1801 to S1806 are the same as S1401 to S1406 in FIG.
  • the edge server 1 can perform a synchronization process for reflecting the update of the core space in the home directory 1. That is, the edge server 1 reads the core space update (the core space rename list and the file and directory specified from the update list) into the home directory 1. Thereafter, the edge server 1 can perform the migration process of FIG.
  • the edge server 1 can perform the same synchronization processing as S1807 (S1810).
  • the update file is not migrated to the core space. Therefore, it is possible to avoid the occurrence of ancestor turn in the core space.
  • Example 3 will be described. At that time, differences from the first embodiment will be mainly described, and description of common points with the first embodiment will be omitted or simplified. Specifically, since the main difference between the first and third embodiments is the migration recovery process, the migration recovery process according to the third embodiment will be mainly described below.
  • the path “/ A / C” is the path “/ A / It is assumed that the files “X” and “G” are updated as shown in the update list 1302A of the home directory 1 after being updated to “D / C”.
  • the user logs in to the home directory 2 instead of the home directory 1, and the tree structure of the home directory 2 is the core at the time when the failure occurs in the first communication network. It is the same as the space tree structure.
  • the edge server 2 records FM “/ A / C” and TO “/ A / B / C” in the rename list 1301B of the home directory 2 and “/ A” in the update list 1302B of the home directory 2. “/ B / C / G”, “/ A / B / Y”, and “/ A / B” are recorded (see the lower part of FIG. 19 and FIG. 22).
  • the edge server 2 migrates the updated files “Y” and “G” in the home directory 2 to the core space. Further, the edge server 2 transmits the update list 1302B and rename list 1301B of the home directory 2 to the core server. As a result, as shown in the lower part of FIG. 19 and FIG. 22, the core server receives and has the update list 1302B and rename list 1301B of the home directory 2.
  • Step 1 the edge server 1 reverses the directory structure, that is, based on the rename list 1301A, the path structure “/ A / D / C” after the update is changed to the path structure “/ A / C” before the update. Return to. As a result, the lower directory “C” disappears from the directory “D”, and the directory “C” becomes a lower directory of the root directory.
  • Step 2 The edge server 1 identifies each update file in the home directory 1 from the path name of each update file in the home directory 1 in which the directory structure is reversed, and updates each update file in the home directory 1 and each update in the core space. Compare the update point of the update file. If there is an old update file in the home directory 1, the edge server 1 adds a subordinate directory “conflict” of the root directory of the home directory 1 and creates a “conflict” directory as a subordinate directory of the “conflict” directory.
  • a directory (hereinafter referred to as a time stamp directory) having a directory name as a directory name is added (for example, a time represented by a date).
  • the edge server 1 copies the old update file “G” in the home directory 1 to the time stamp directory while maintaining the path structure. Further, the edge server 1 deletes the path name of the old update file copied to the time stamp directory from the update list 1302A. Next, the edge server 1 migrates the update file (file specified from the update list 1302A) of the home directory 1 and the “conflict” directory to the core space, and the update list 1302A and the rename list 1301A are transferred to the core server. Send to.
  • the “conflict” directory exists in the core space, and the lower file “X” is added to the directory “B” based on the update list 1302A and the rename list 1301A in the core space, and The lower directory “D” is added to the root directory.
  • the core server receives the update list 1302A and the rename list 1301A
  • the core server has the update list 1302B and the rename list 1301B.
  • the core server can have the received rename list and update list for each edge server for one core space.
  • the core server deletes the rename list and update list received in the past from the edge server and stores the newly received rename list and update in the memory. can do.
  • Step 3 The edge server 1 reads a file (directory) not stored in the home directory 1 from the core space to the home directory based on the lists 1301B and 1302B from the other edge servers 2 (synchronization).
  • the files “Y” and “G” and the updated directory “B” are read to the home directory 1.
  • a check mark is added to the icon of the synchronized (overwritten) directory and file in the home directory 1, and the path structure is the latest in the icon of the directory via the path whose structure has been returned.
  • a mark “R” indicating that the structure has been returned is attached.
  • FIG. 23 is a flowchart of migration recovery processing according to the third embodiment.
  • S2310 to S2306 are performed in place of S1410 to S1406 in FIG.
  • the edge server 1 restores the directory structure of the home directory 1 based on the rename list 1301A (S2307) (see step 1 in FIG. 20). Then, the edge server 1 performs the migration process of FIG. 12 (see step 2 of FIG. 21).
  • the edge server 1 performs a synchronization process for synchronizing the home directory 1 with the core space (S2312).
  • the third embodiment it is determined which of the update file in the home directory 1 and the update file in the core space is old, and if there is an old update file in the home directory 1, the old update file is copied to the “conflict” directory. Then, the “conflict” directory is migrated to the core space. Thereby, it is possible to avoid the occurrence of ancestor turn in the core space.
  • the directory structure of the home directory 1 is reversed, so that the amount of calculation is reduced compared to the second embodiment where the directory structure of the home directory 1 is not reversed. Can be reduced.
  • Example 3 the directory structure of the core space may be reversed based on the rename space 1301B in Step 1 of FIG. 20, and then Step 2 of FIG.
  • the directory structure may be restored to the state before reverse.
  • a directory having a value indicating the update time (time stamp) of the file as a directory name may be added below the “confict” directory.
  • a directory having a value indicating a time point (time stamp) when the “conflict” directory is created as a directory name is added, and the directory of the added directory Files under the “hidden” directory may be copied below.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Quality & Reliability (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

　第１ホームディレクトリを提供する第１エッジサーバが、第１ホームディレクトリにおける第１ファイルがコアスペースにおける第２ファイルを上書きすることを回避する確保処理を第１ホームディレクトリのアップデートのコアスペースへのコピーの前に行う。第２ファイルは、第２エッジサーバの第２ホームディレクトリにおいてアップデートされコアスペースにコピーされたファイルである。第１ファイルは、第２ファイルに対応し第１ホームディレクトリにおいてアップデートされコアスペースにコピーされていないファイルである。

Description

エッジサーバ及び記憶制御方法
　本発明は、複数のファイルサーバを有するファイルサーバシステムでの記憶制御に関する。
　特許文献１には、リモート（例えばバックエンド）のファイルサーバ（以下、コアサーバ）と、コアサーバに通信ネットワークを介して接続されているローカル（例えばフロントエンド）のファイルサーバ（以下、エッジサーバ）についての記載がある。
　特許文献１では、エッジサーバのユーザは、コアサーバから通信ネットワークを介してエッジサーバにファイルをリードし、エッジサーバ内でのリードされたファイルをアップデートする。その後、エッジサーバは、アップデートされたファイルを、エッジサーバからコアサーバにコピーし、エッジサーバ内のそのファイルをスタブ化する。つまり、エッジサーバからコアサーバへのファイルのマイグレーションが行われる。その後、ユーザからスタブ（スタブ化されたファイル）にアクセスがあった場合、エッジサーバは、スタブに対応するファイルをコアサーバからリードする。
米国特許出願公開第２０１２／００１６８３８号明細書
　１つのコアスペースに対応付けられている複数のホームディレクトリを複数のエッジサーバが有するファイルサーバシステムの問題点について考察する。なお、ここで言う「コアスペース」は、コアサーバが有するファイルシステム（ネームスペース）であり、「ホームディレクトリ」は、エッジサーバのユーザに使用されるファイルシステム（ネームスペース）である。
　例えば、第１エッジサーバが有する第１ホームディレクトリ内のファイルがアップデートされたとする。しかし、その後、アップデートされたファイルがコアスペースにマイグレーションされる前に、第１エッジサーバとコアサーバとの通信に障害（例えば第１エッジサーバとコアサーバを接続する通信ネットワークの障害）が発生したとする。この場合、第１エッジサーバは、第１ホームディレクトリ内のスタブに対応するファイルをコアスペースからリードすることができない。
　そこで、ユーザは、第１ホームディレクトリに代えて、第１ホームディレクトリに対応したコアスペースに対応し第２エッジサーバが有する第２ホームディレクトリを使用することができる。ユーザは、そのアップデートされたファイルがアップデートされる前のファイルをコアスペースから第２ホームディレクトリを通じて取得し、そのファイルをアップデートすることができる。第２エッジサーバが、アップデートされたファイルを第２ホームディレクトリからコアスペースにマイグレーションする。
　その後、第１のエッジサーバとコアサーバとの通信障害が回復した場合、第１エッジサーバは、未だマイグレーションされていないアップデートされたファイルを第１ホームディレクトからコアスペースにマイグレーションすることができる。
　しかし、そうすると、コアスペースにおいてファイルの先祖返りが生じる。すなわち、第２エッジサーバからマイグレーションされた最新ファイルが、そのファイルよりも前にアップデートされた旧いファイルによって上書きされてしまうことになる。
　コアスペースにおけるファイルの先祖返りは、第１エッジサーバとコアサーバとの通信障害があった場合に限らず、第１ホームディレクトリにおけるアップデートされたファイルがコアスペースにコピーされる前に、第１ホームディレクトリに代えて第２ホームディレクトリが使用され、その後第２ホームディレクトリに代えて第１ホームディレクトリが使用される他の場合にも起こり得る。
　すなわち、本願発明の目的は、ファイルの先祖返りを防止し、ユーザに最新のファイルを提供することを目的とする。
　第１ホームディレクトリを提供する第１エッジサーバが、第１ホームディレクトリにおける第１ファイルがコアスペースにおける第２ファイルを上書きすることを回避する確保処理を第１ホームディレクトリのアップデートのコアスペースへのコピーの前に行う。第２ファイルは、第２エッジサーバの第２ホームディレクトリにおいてアップデートされコアスペースにコピーされたファイルである。第１ファイルは、第２ファイルに対応し第１ホームディレクトリにおいてアップデートされコアスペースにコピーされていないファイルである。第１ファイルは、第２ファイルと識別情報（例えばＵＵＩＤ（Universally Unique Identifier））が同じファイルで良い。
図１は、実施例１に係るファイルサーバシステム全体のハードウェア構成を示す。 図２は、実施例１に係るファイルサーバシステム全体のソフトウェア構成を示す。 図３は、inode管理テーブルを示す。 図４は、図３のinode管理テーブルにおけるinode番号「１００」のinodeと、ファイルの位置との関係を示す。 図５は、実施例１の比較例においてコアスペースでファイルの先祖返りが発生する原因の一例を説明するための模式図である。 図６は、実施例１においてネットワーク障害が発生してからネットワーク障害が回復するまでの流れの一例を示す模式図である。 図７は、実施例１においてネットワーク障害が回復した場合に行われる処理の概要例の一部を示す模式図である。 図８は、実施例１においてネットワーク障害が回復した場合に行われる処理の概要例の残りを示す模式図である。 図９は、実施例１におけるリネームリスト及びアップデートリストを示す。 図１０は、ログイン処理のフローチャートである。 図１１は、ライト処理のフローチャートである。 図１２は、マイグレーション処理のフローチャートである。 図１３は、ホームディレクトリ回復処理のフローチャートである。 図１４は、実施例１に係るマイグレーション回復処理のフローチャートである。 図１５は、実施例２においてネットワーク障害が発生してからネットワーク障害が回復するまでの流れの一例を示す模式図である。 図１６は、実施例２においてネットワーク障害が回復した場合に行われる処理の概要例の一部を示す模式図である。 図１７は、実施例２におけるリネームリスト及びアップデートリストを示す。 図１８は、実施例２に係るマイグレーション回復処理のフローチャートである。 図１９は、実施例３においてネットワーク障害が発生してからネットワーク障害が回復するまでの流れの一例を示す模式図である。 図２０は、実施例３においてネットワーク障害が回復した場合に行われる処理の概要例の一部を示す模式図である。 図２１は、実施例３においてネットワーク障害が回復した場合に行われる処理の概要例の一部を示す模式図である。 図２２は、実施例３におけるリネームリスト及びアップデートリストを示す。 図２３は、実施例３に係るマイグレーション回復処理のフローチャートである。 図２４は、実施例１において複数のファイルサーバにある複数のホームディレクトリが同一のコアスペースに対応していることを示す。
　以下、幾つか実施例を説明する。
　なお、以下の説明では、「ｘｘｘテーブル」の表現にて各種情報を説明することがあるが、各種情報は、テーブル以外のデータ構造で表現されていてもよい。データ構造に依存しないことを示すために「ｘｘｘテーブル」を「ｘｘｘ情報」と呼ぶことができる。
　また、以下の説明では、「プログラム」を主語として処理を説明する場合があるが、プログラムは、プロセッサ（例えばＣＰＵ（Central　Processing　Unit））によって実行されることで、定められた処理を、適宜に記憶資源（例えばメモリ）及び／又は通信インタフェース装置（例えば通信ポート）を用いながら行うため、処理の主語がプロセッサとされても良い。プログラムを主語として説明された処理は、ファイルサーバ（例えば、後述のエッジサーバ、コアサーバ）が行う処理としても良い。また、プロセッサは、プロセッサが行う処理の一部又は全部を行うハードウェア回路を含んでも良い。コンピュータプログラムは、プログラムソースから各計算機にインストールされても良い。プログラムソースは、例えば、プログラム配布サーバ又は記憶メディアであっても良い。
　図１は、実施例１に係るファイルサーバシステム全体のハードウェア構成を示す。
　ファイルサーバシステムは、エッジ１００とコア２００により構成されている。エッジ１００とコア２００は、通信ネットワーク１を介して相互に接続されている。
　エッジ１００とは、ローカルの計算機システムを含んだ拠点であり、例えば、支店や営業所などユーザが実際に業務を行う拠点である。また、コア２００とは、リモートの計算機システムを含んだ拠点であり、例えば、サーバやストレージ装置を一括管理する拠点やクラウドサービスを提供する拠点である。
　なお、図に示す例では、コア２００が単数であるが、コア２００は複数であっても良い。本発明は、コア２００が単数であるか複数であるかに関わらず、複数のエッジ１００における複数のエッジサーバ１２０が有する複数のホームディレクトリ（ユーザ用のファイルシステムスペース）に同一のコアスペース（コア２００内のコアサーバ２２０が提供するファイルシステムスペース（ネームスペース））が対応付けられているファイルサーバシステム全般に適用することができる。
　また、図では、エッジサーバ１２０に接続されている１つのクライアント又はホスト（クライアント／ホスト）１３０が示されているが、エッジサーバ１２０に複数のクライアント／ホスト１３０が接続されても良い。また、１つのクライアント／ホスト１３０は、１又は複数の通信ネットワークを介して、複数のエッジサーバ１２０に接続されていても良い。
　エッジ１００は、ＲＡＩＤシステム１１０と、エッジサーバ１２０と、クライアント／ホスト１３０と、を備える。
　エッジサーバ１２０は、エッジ１００にあるファイルサーバの一例（例えばファイルストレージ装置）であり、例えば、通信ネットワーク（例えばＬＡＮ（Local　Area　Network））経由で、クライアント／ホスト１３０に接続されている。また、エッジサーバ１２０は、例えば、通信ネットワーク（例えばＳＡＮ（Storage　Area　Network））経由で、ＲＡＩＤシステム１１０に接続されている。
　ＲＡＩＤシステム１１０は、コントローラ部と記憶部とに大別される。コントローラ部は、ＣＨＡ（Channel　Adaptor）１１１と、ストレージコントローラ（以下、ＳＴ－ＣＴＬ）１１２とを備える。記憶部は、ＤＩＳＫ１１３を備える。ＳＴ－ＣＴＬ１１２に、ＣＨＡ１１１及びＤＩＳＫ１１３が接続されている。ＣＨＡ１１１は、エッジサーバ１２０に接続される通信インタフェースデバイスである。ＳＴ－ＣＴＬ１１２は、コントローラである。ＤＩＳＫ１１３は、ディスク型の物理記憶デバイス（例えば、ＨＤＤ（Hard　Disk　Drive））である。物理記憶デバイスとして、他種の物理記憶デバイス（例えば、フラッシュメモリデバイス）が採用されても良い。また、図に示す例では、ＲＡＩＤシステム１１０が備えているＤＩＳＫ１１３は単数であるが、実際にＲＡＩＤシステム１１０は、ＤＩＳＫ１１３を複数備えている。複数のＤＩＳＫ１１３で、１以上のＲＡＩＤグループが構成されて良い。
　ＲＡＩＤシステム１１０は、エッジサーバ１２０から送信されたブロックレベルのＩ／Ｏ要求をＣＨＡ１１１で受信し、ＳＴ－ＣＴＬ１１２の制御に基づいて、適切なＤＩＳＫ１１３へのＩ／Ｏを実行する。
　エッジサーバ１２０は、メモリ１２１と、ＣＰＵ（Central　Processing　Unit）１２２と、ＮＩＣ（Network　Interface　Card）１２３と、ＨＢＡ（Host　Bus　Adaptor）１２４と、を備える。メモリ１２１、ＮＩＣ１２３及びＨＢＡ１２４に、ＣＰＵ１２２が接続されている。
　ＮＩＣ１２３は、コアサーバ２２０及びクライアント／ホスト１３０と通信する通信インタフェースデバイスである。複数のエッジサーバ１２０がそれぞれ有する複数のＮＩＣ１２３が、複数の通信ネットワーク１を通じて同一のコアサーバ２２０と通信しても良い。
　ＨＢＡ１２４は、ＲＡＩＤシステム１１０と通信する通信インタフェースデバイスである。
　メモリ１２１は、ＣＰＵ１２２が直接読み書きできる記憶領域（例えば、ＲＡＭ（Random　Access　Memory）やＲＯＭ（Read　Only　Memory））である。エッジサーバ１２０は、メモリ１２１上にエッジサーバ１２０を制御するプログラム（例えばＯＳ（Operating　System））を読み込み、ＣＰＵ１２２にそのプログラムを実行させる。エッジサーバ１２０は、メモリ１２１に加えて又は代えて、別種の記憶資源を有しても良い。
　エッジサーバ１２０は、ＮＩＣ１２３経由で、クライアント／ホスト１３０からファイルレベルのＩ／Ｏ要求を受信する。エッジサーバ１２０は、そのＩ／Ｏ要求で指定されているファイルを構成するデータブロックのＩ／ＯのためのＩ／Ｏ要求（ブロックレベルのＩ／Ｏ要求)を作成する。エッジサーバ１２０は、ブロックレベルのＩ／Ｏ要求を、ＨＢＡ１２４経由で、ＲＡＩＤシステム１１０に送信する。
　クライアント／ホスト１３０は、計算機であり、メモリ１３１と、ＣＰＵ１３２と、ＮＩＣ１３３と、ＤＩＳＫ１３４と、を備える。クライアント／ホスト１３０は、メモリ１３１及び／又はＤＩＳＫ１３４に加えて又は代えて、別種の記憶資源を有しても良い。
　クライアント／ホスト１３０は、ＤＩＳＫ１３４に格納されているプログラム（クライアント／ホスト１３４を制御するプログラム（例えばＯＳ））をメモリ１３１上に読み込み、ＣＰＵ１３２にプログラムを実行させる。また、クライアント／ホスト１３０は、ＮＩＣ１３３経由で、ファイルレベルのＩ／Ｏ要求をエッジサーバ１２０に送信する。
　コア２００は、ＲＡＩＤシステム２１０と、コアサーバ２２０と、を備える。コアサーバ２２０に、例えば通信ネットワークを介して、ＲＡＩＤシステム２１０が接続されている。
　ＲＡＩＤシステム２１０は、ＣＨＡ２１１と、ＳＴ－ＣＴＬ２１２と、ＤＩＳＫ２１３と、を備える。図では、ＲＡＩＤシステム２１０の構成とＲＡＩＤシステム１１０の構成は、実質的に同一である。従って、ＲＡＩＤシステム２１０も、コアサーバ２２０から送信されたブロックレベルのＩ／Ｏ要求をＣＨＡ２１１で受信し、ＳＴ－ＣＴＬ２１２の制御に基づいて、適切なＤＩＳＫ２１３へのＩ／Ｏを実行することができる。なお、ＲＡＩＤシステム２１０の構成とＲＡＩＤシステム１１０の構成は、異なっていても良い。
　コアサーバ２２０は、コア２００にあるファイルサーバの一例（例えばアーカイブ装置）であり、メモリ２２１と、ＣＰＵ２２２と、ＮＩＣ２２３と、ＨＢＡ２２４と、を備える。メモリ２２１に代えて又は加えて、別種の記憶資源が備えられても良い。コアサーバ２２０は、メモリ２２１上にコアサーバ２２０を制御するプログラム（例えばＯＳ）を読み込み、ＣＰＵ２２２にそのプログラムを実行させる。また、コアサーバ２２０は、ＮＩＣ２２３及び通信ネットワーク１経由で、エッジサーバ１２０と通信する。コアサーバ２２０は、ＨＢＡ２２４経由で接続され、ブロック単位のアクセスを行う。
　本実施例では、複数のエッジサーバ１２０がそれぞれ接続された複数の物理的或いは論理的な通信ネットワーク１に１つのコアサーバ２２０が接続されている。しかし、通信ネットワークは、複数のエッジサーバ１２０に共通であっても良い。
　図２は、実施例１に係るファイルサーバシステム全体のソフトウェア構成を示す。
　ＲＡＩＤシステム１１０（２１０）は、複数のＬＵ（Logical　Unit）１１００（２１００）を有する。ＬＵ１１００（２１００）は、論理的な記憶デバイスである。ＬＵ１１００（２１００）は、１以上のＤＩＳＫ１１３（２１３）に基づく実体的なＬＵであっても良いし、Thin　Provisioningに従う仮想的なＬＵであっても良いし、ストレージ仮想化技術に従い外部のストレージリソースが仮想化されることにより生成されたＬＵであっても良い。
　ＬＵ１１００（２１００）は、複数のブロック（記憶領域）で構成されている。ＬＵ１１００（２１００）に、ファイルが記憶される。また、ＬＵ１１００（２１００）に、後述のファイルシステム情報の全部又は一部が、記憶されて良い。
　エッジサーバ１２０のメモリ１２１（コアサーバ２２０のメモリ２２１）には、制御プログラム１２１０（２２１０）と、ファイルシステム１２１１（２２１１）と、カーネル／ドライバ１２１２（２２１２）と、が記憶されている。エッジサーバ１２０のメモリ１２１には、更に、ファイル共有プログラム１２１３が記憶されている。以下、エッジサーバ１２０内の制御プログラムを、「エッジ制御プログラム」と言い、コアサーバ２２０内の制御プログラムを、「コア制御プログラム」と言い、それらを特に区別しない場合に、「制御プログラム」と言う。エッジサーバ１２０とコアサーバ２２０との間では、エッジ制御プログラム１２１０及びコア制御プログラム２２１０を介して、ファイルのやり取りが行われる。
　エッジ制御プログラム１２１０は、ＲＡＩＤシステム１１０のＬＵ１１００から、コピー対象のファイルを読み出し、読み出したファイルをコアサーバ２２０に転送する。コア制御プログラム２２１０は、コピー対象のファイルをエッジサーバ１２０から受信し、受信したファイルを、ＲＡＩＤシステム２１０のＬＵ２１００に書き込む。
　また、エッジ制御プログラム１２１０は、ＬＵ１１００内のコピー済みファイル（厳密にはその実体）を、ある所定の条件が満たされた場合に、削除し、それにより、コピー済みファイルの実質的なマイグレーションを実現する。
　その後、エッジ制御プログラム１２１０は、削除されたファイルのスタブ（メタデータ）に対してクライアント／ホスト１３０からリード要求を受けた場合、コア制御プログラム２２１０を経由して、スタブにリンクしているファイルを、例えばＬＵ２１００から取得し、取得したファイルをクライアント／ホスト１３０に送信する。
　なお、本実施例において、「スタブ」とは、ファイルの格納先情報（リンク先を表す情報）に関連付けられたオブジェクト（メタデータ）である。クライアント／ホスト１３０からは、ファイルであるかスタブであるかは分からない。
　ファイルシステム１２１１（２２１１）は、ファイルシステムプログラムであり、ファイルシステム情報を管理する。ファイルシステム情報は、各ファイルに関する情報（例えば、ファイルのサイズや場所などを表す情報）を含む。具体的には、例えば、ファイルシステム情報は、図３に示すinode管理テーブル３００を含む。inode管理テーブル３００は、複数のinodeより構成される（１行が１つのinodeに対応する）。各inodeは、複数のメタデータで構成される。メタデータの種類としては、ファイルの所有者、ファイルのアクセス権、ファイルサイズ、ファイルの格納位置（データブロックアドレス１、２、３、…）などがある。
　例えば、inode番号「１００」を含んだ行によれば、ファイルは、図４に示すように、下記のブロック（ＬＵ内のブロック）が記憶するデータで構成されていることがわかる。（＊）アドレス１００のブロックを先頭とした３つの連続したブロック（データブロックアドレス「１００－３」から特定されるブロック群）内のデータ。
（＊）アドレス２００のブロックを先頭とした２つの連続したブロック（データブロックアドレス２「２００－２」から特定されるブロック群）内のデータ。
（＊）アドレス２５０のブロックを先頭とした５つの連続したブロック（データブロックアドレス３「２５０－５」から特定されるブロック群）内のデータ。
　再び、図２を参照する。カーネル／ドライバ１２１２（２１２１）は、エッジサーバ１２０（コアサーバ２２０）上で動作する複数のプログラム（プロセス）のスケジュール制御やハードウェアからの割り込みをハンドリングするなど、全般的な制御及びハードウェア固有の制御を行う。
　ファイル共有プログラム１２１３は、ＣＩＦＳ（Common　Internet　File　System）、ＮＦＳ（Network　File　System）といった通信プロトコルを使用して、クライアント／ホスト１３０との間で、ファイル共有サービスを提供するプログラムである。
　クライアント／ホスト１３０のメモリ１３１には、アプリケーション１３１０と、ファイルシステム１３１１と、カーネル／ドライバ１３１２が記憶されている。
　アプリケーション１３１０は、クライアント／ホスト１３０が、作業の目的に応じて使うソフトウェア（アプリケーションプログラム）である。ファイルシステム１３１１及びカーネル／ドライバ１３１２は、上述のファイルシステム１２１１（２２１１）、カーネル／ドライバ１２１２（２２１２）と、ほぼ同様である。
　図２４は、実施例１において複数のエッジサーバにある複数のホームディレクトリが同一のコアスペースに対応していることを示す。
　エッジサーバ１及び２（１２０）が、ホームディレクトリ１及び２（１６８）を有する。ホームディレクトリ１（２）は、エッジサーバ１（２）が有する、ユーザ用のファイルシステムスペース（ネームスペース）である。エッジサーバ１（２）は、ユーザが使用するクライアント／ホスト１（２）に、ホームディレクトリ１（２）を提供する。クライアント／ホスト１（２）は、ホームディレクトリ１（２）にファイルを追加したり、ホームディレクトリ１（２）内のファイルをアップデートしたり、ホームディレクトリ１（２）からファイルを削除したりすることができる。
　複数のホームディレクトリ１及び２が、１つのコアスペース２６８に対応付けられている。コアスペース２６８は、コアサーバ２２０が有する、ホームディレクトリ用のファイルシステムスペース（ネームスペース）である。なお、ホームディレクトリ１及び２は１つのコアスペースに対応付けられているため、ユーザからは同じホームディレクトリとして識別されて良いが、説明の便宜上、これらのホームディレクトリを区別する。
　エッジサーバ１によってホームディレクトリ１がアップデート（ファイルの追加、ファイルのアップデート、ファイルの削除）された場合、そのアップデートは、コアスペース２６８に反映され、その反映によるコアスペース２６８のアップデートが、エッジサーバ２のホームディレクトリ２に反映され、それにより、ホームディレクトリ２がアップデートされる。例えば、ホームディレクトリ１にファイルＸが追加された場合、ファイルＸがホームディレクトリ１からコアスペース２６８にマイグレーションされ、コアスペース２６８からホームディレクトリ２にファイルＸがコピーされる。
　同様に、エッジサーバ２によるホームディレクトリ２のアップデート（ファイルの追加、ファイルのアップデート、ファイルの削除）は、コアスペース２６８に反映され、その反映によるコアスペース２６８のアップデートが、エッジサーバ１のホームディレクトリ１に反映され、それにより、ホームディレクトリ１がアップデートされる。例えば、ホームディレクトリ２内のファイルＸがアップデートされた場合、アップデートされたファイルＸがホームディレクトリ２からコアスペース２６８にマイグレーションされ、アップデートされたファイルＸが、コアスペース２６８からホームディレクトリ１にコピーされる。
　なお、少なくとも１つのエッジサーバ１２０は、ローカルディレクトリ１６７をホームディレクトリ１６８とは別に有していても良い。ローカルディレクトリ１６７は、コアサーバ２２０のファイルシステムスペース（ネームスペース）２６７が自身だけに対応したファイルシステムスペースである。ローカルディレクトリ１６７で行われたアップデートは、そのローカルディレクトリ１６７に対応したファイルシステムスペース（コアサーバ２２０が有するネームスペース）２６７のみに反映されて良い。
　エッジサーバ１２０のメモリ１２１には、それぞれ、リネームリスト及びアップデートリストが記憶される。エッジサーバ１２０におけるリネームリスト及びアップデートリストは、そのエッジサーバ１２０が有するホームディレクトリ毎に存在する。
　リネームリストとは、ホームディレクトリ１６８においてアップデートされたパスについてのアップデート前のパスネーム及びアップデート後のパスネームのリストである。具体的には、例えば、図９に示すように、ホームディレクトリ１に対応しエッジサーバ１が有するリネームリスト１３０１Ａは（エッジサーバ２が有する図示しないリネームリストも）、アップデートされたパス毎に「ＦＭ」及び「ＴＯ」という項目を有する。「ＦＭ」は、アップデート前のパスネーム（パスの構造）を示し、「ＴＯ」は、アップデート後のパスネームを示す。リネームリストには、アップデートされてからコアスペースに反映（マイグレーション）されていないパスネーム（パス構造）が記録されている。なお、本実施例では、コアサーバ２２０は、コアスペースにおけるファイルに、ファイルの識別情報として、ＵＵＩＤ（Universally Unique Identifier）を付与する。コアスペースにおけるファイルのＵＵＩＤは、そのコアスペースに対応したホームディレクトリ１及び２を有するエッジサーバ１及び２に提供される。エッジサーバ１及び２は、ファイルのパスネームから、そのファイルのＵＵＩＤを特定することができる。しかし、エッジサーバ１及び２は、ファイルのＵＵＩＤからそのファイルのパスネームを特定することはできない。
　アップデートリストとは、ホームディレクトリ１６８においてアップデートされたファイルの識別情報のリストである。識別情報は、例えばパスネームである。具体的には、例えば、図９に示すように、ホームディレクトリ１に対応しエッジサーバ１が有するアップデートリスト１３０２Ａには（エッジサーバ２が有するアップデートリスト１３０２Ｂにも）、ホームディレクトリ１（２）に格納されているファイルのうち、アップデートされたがコアスペースにマイグレーションされていないファイルのパスネームが登録される。アップデートリストには、アップデートされてからコアスペースにマイグレーションされていないファイルのパスネームが記録されている。
　ホームディレクトリ１（２）からコアスペースへのファイルのマイグレーションの都度に、リネームリスト１３０１Ａ及びアップデートリスト１３０２Ａ（１３０２Ｂ）がコアサーバ２２０に送信される。図９の例によれば、ホームディレクトリ２からコアスペースへ２２０のファイルのマイグレーションが行われ、アップデートリスト１３０２Ｂ（及び図示しないリネームリスト）がエッジサーバ２からコアサーバ２２０に送信され、コアサーバ２２０のメモリ２２１にそのアップデートリスト１３０２Ｂ（及びリネームリスト）が記憶される。この後、アップデートリスト１３０２Ｂ（及びリネームリスト）は初期状態（例えばブランク）となり、ホームディレクトリ２がアップデートされた場合、アップデートリスト１３０２Ｂ及びリネームリストのうちの少なくとも一方がアップデートされる。
　エッジサーバ１（２）は、コアサーバ２２０が受信した、エッジサーバ２（１）からのリネームリスト及びアップデートリストのうちの少なくともアップデートリストを用いて、ホームディレクトリ２（１）においてアップデートされたファイルがコアスペースにあるか否かを判断することができる。本実施例では、ファイルの先祖返り、すなわち、ホームディレクトリ２（１）においてアップデートされコアスペースにマイグレーションされたファイルが、そのファイルよりも過去にホームディレクトリ１（２）においてアップデートされた旧いファイルで上書きされてしまうことが生じない。なお、アップデートリスト及びリネームリストの各々にはシーケンシャル番号が関連付けられ、エッジサーバは、アップデートリスト及びリネームリストをコアサーバに送信する都度に、それらのリストのシーケンシャル番号を１インクリメントする。
　まず、本実施例の比較例として、コアスペースでファイルの先祖返りが発生する原因の一例を説明し、その後に、本実施例で行われる種々の処理を説明する。
　図５は、本実施例の比較例においてコアスペースでファイルの先祖返りが発生する原因の一例を説明するための模式図である。なお、この比較例でも、エッジサーバ１が有するホームディレクトリ１とエッジサーバ２が有するホームディレクトリ２が１つのコアスペースと対応付けられているとする。
　～１について～
エッジサーバ１は、ホームディレクトリ１に対するユーザのログインを許可する。そして、エッジサーバ１は、コアスペースにロックを掛ける。これにより、エッジサーバ１以外のエッジサーバがコアスペースにファイルを書き込むことができなくなる（しかし、コアスペースからのファイルの読み出しはできる）。コアスペースにロックが掛かった状態で、エッジサーバ１は、コアスペースから少なくともユーザ所望のファイル（以下、旧ファイルＴ）をホームディレクトリ１に読み出して、読み出した旧ファイルＴを新ファイルＴ１にアップデートする。この時点において、エッジサーバ１は、新ファイルＴ１を、コアスペースにマイグレーションしていない。
　なお、コアサーバは、ロックを掛けているエッジサーバに対して、定期的にロックを延長するか否かの問合せ（以下、延長問合せ）を出すようになっている。そして、エッジサーバは、延長問合せを受けた場合、ロックを延長するか否かを、コアサーバに対して回答するようになっている。
　～２について～
エッジサーバ１とコアサーバとの間の通信ネットワーク（以下、第１の通信ネットワーク）に障害が発生する。第１の通信ネットワークに障害が発生すると、コアサーバは、エッジサーバ１から延長問合せに対する回答を受信することができなくなる。この場合、コアサーバは、エッジサーバ１がコアスペースに掛けたロックを解除する。なお、本実施例では、エッジサーバとコアサーバ間の通信障害の一例として、上記のように通信ネットワークの障害を挙げているが、エッジサーバとコアサーバ間で他種の通信障害（例えば、エッジサーバ及びコアサーバの少なくとも一方のＮＩＣの障害）が発生しても、エッジサーバ１がコアサーバから延長問合せを受信できない、或いは、コアサーバがエッジサーバ１から延長問合せに対する回答を受信できないことがある。
　～３について～
第１の通信ネットワークに障害が発生すると、エッジサーバ１は、新ファイルＴ１を、コアスペースにマイグレーションできない。
　～４について～
ユーザがエッジサーバ１からエッジサーバ２に相対的に移動する。具体的には、ユーザは、ホームディレクトリ１からログアウトし、エッジサーバ２にログインする。エッジサーバ２は、エッジサーバ２とコアサーバを接続する通信ネットワーク（第２の通信ネットワーク）を介して、コアスペースにロックを掛ける。これにより、エッジサーバ２以外のエッジサーバからコアスペースにファイルを書き込むことができなくなる。
　～５について～
エッジサーバ２は、コアスペースからホームディレクトリ２にファイルＴを読み出す。つまり、ここでエッジサーバ２に読み出されたファイルは、エッジサーバ１においてアップデートする前のファイル（旧ファイル）Ｔである。なぜなら、エッジサーバ１の新ファイルＴ１は、新ファイルＴ１をコアスペースにマイグレーションする前に生じた、第１の通信ネットワークの障害により、コアスペースにマイグレーションされていないからである。エッジサーバ２は、旧ファイルＴを読み出した後、リードした旧ファイルＴをアップデートする。以下、エッジサーバ２によってアップデートされたファイルＴを最新ファイルＴ２と称する。
　～６について～
エッジサーバ２が、最新ファイルＴ２をコアスペースにマイグレーションする。その後、ユーザは、ホームディレクトリ２からログアウトする。ユーザがホームディレクトリ２からログアウトした場合、コアサーバは、エッジサーバ２がコアスペースに掛けているロックを解除する。なぜなら、ユーザがホームディレクトリ２からログアウトした場合、エッジサーバ２は、コアサーバからの延長問合せに対して、延長しないと回答するからである。コアサーバは、延長しないとの回答を受けて、コアスペースに掛けられているロックを解除する。
　～７について～
第１の通信ネットワークの障害が回復する。
　～８について～
その後、エッジサーバ１は、新ファイルＴ１を、ホームディレクトリ１からコアスペースにマイグレーションする。
　以上の流れにより、コアスペースにおいて、エッジサーバ２からの最新ファイルＴ２にエッジサーバ１の新ファイルＴ１が上書きされてしまうという先祖返りが生じてしまう。
　本実施例では、このような先祖返りを回避するための工夫がなされている。
　以下、図６乃至図８を参照して、本実施例の一つの処理流れの概要を説明する。なお、図６乃至図８では、エッジ１、コア及びエッジ２の枠内のツリー構造は、それぞれ、ホームディレクトリ１、コアスペース及びホームディレクトリ２のツリー構造である。また、ディレクトリタイプのアイコンは、ホームディレクトリ又はコアスペースにおけるディレクトリを示す。また、ファイルタイプのアイコンは、ファイル（又はファイルに対応したスタブ）を示す。また、白星印は、ホームディレクトリ１におけるアップデート又は追加を示す。また、黒星印は、ホームディレクトリ２におけるアップデート又は追加を示す。ここで、アップデートしたディレクトリとは、下位ファイル又は下位ディレクトリが追加されたディレクトリ、或いは、下位ファイル又は下位ディレクトリが削除されたディレクトリである。ディレクトリの「下位ファイル」及び「下位ディレクトリ」とは、そのディレクトリの下位にあるファイル又はディレクトリであって対象のディレクトリから直接的に（別のディレクトリを経由することなく）アクセス可能なファイル又はディレクトリである。また、エッジサーバにおける鍵マークは、ホームディレクトリについてロックフラグがオンになっていることを意味し、コアサーバにおける鍵マークは、コアスペースにロックが掛かっていることを意味する。エッジサーバは、コアスペースにロックが掛かったことをそのエッジサーバが認識するために、そのコアスペースに対応するホームディレクトリについてロックフラグをオンにするようになっている。これにより、エッジサーバは、コアサーバにコアスペースにロックが掛かっているか否かを問合せなくても、ロックが掛かっていると判断することができる。
　図６の上段に示すように、第１の通信ネットワークの障害が発生する前、エッジサーバ１がコアスペースにロックを掛けており、リスト１３０１Ａ及び１３０２Ａが示す通り（図９参照）、パスネーム「／Ａ／Ｃ」がパスネーム「／Ａ／Ｄ／Ｃ」へとアップデートされ、且つ、ファイル「Ｘ」及び「Ｇ」がアップデートされたとする。第１の通信ネットワークの障害が発生した場合、ユーザがホームディレクトリ１からログアウトしホームディレクトリ２にログインし、コアスペースのロックが解除されるが、ホームディレクトリ２のツリー構造は、第１の通信ネットワークの障害が発生した時点でのコアスペースのツリー構造と同じである。
　図６の下段に示すように、エッジサーバ２がコアスペースにロックを掛けて、ホームディレクトリ２では、ディレクトリ「Ｂ」に下位ファイル「Ｙ」が追加され、ディレクトリ「Ｃ」の下位ファイル「Ｇ」がアップデートされたとする。これにより、エッジサーバ２が、アップデートリスト１３０２Ｂに、「／Ａ／Ｃ／Ｇ」、「／Ａ／Ｂ／Ｙ」及び「／Ａ／Ｂ」を記録する（図６下段及び図９参照）。
　エッジサーバ２は、ホームディレクトリ２におけるアップデートされたファイル「Ｙ」及び「Ｇ」を、コアスペースにマイグレーションする。また、エッジサーバ２は、ホームディレクトリ２のアップデートリスト１３０２Ｂ及びリネームリスト（図示せず）をコアサーバに送信する。この結果、図６下段及び図９に示すように、コアサーバは、ホームディレクトリ２のアップデートリスト１３０２Ｂ及びリネームリスト（図示せず）を受信し有することになる。
　その後、第１の通信ネットワークの障害が回復したとする。エッジサーバ１が、第１の通信ネットワークの障害の回復を検知したことを契機として（或いは、第１の通信ネットワークの障害の回復か否かに関わらずに起こった所定イベントの検知を契機として）、図７及び図８に示す処理が行われる。なお、図７及び図８を参照した説明において、エッジサーバの処理は、エッジ制御プログラムが実行されることによって行われて良く、コアサーバの処理は、コア制御プログラムが実行されることによって行われて良い。
　～ステップ１～
エッジサーバ１は、他のエッジサーバからのアップデートリスト１３０２Ｂ又はリネームリストがコアサーバにあるか否かを判断する。つまり、エッジサーバ１は、他のエッサーバ２によってコアスペースがアップデートされたか否かを判断する。なお、ステップ１において、エッジサーバ１は、コアサーバがアップデートリスト１３０２Ｂ及びリネームリストのうちの少なくとも１つを有する場合、それらリストを取得し、取得したリストと、自分が持つリスト１３０１Ａ及び１３０２Ａとを比較しても良い。その比較により、ホームディレクトリ１のアップデート（ファイルの追加、削除又はアップデート）をコアスペースに反映するとコアスペースにおいて先祖返りが生じてしまうファイル（以下、コンフリクトファイル）があるか否かがわかる。コアスペースにコンフリクトファイルがあるとの判断の場合、ステップ１の判断結果が真となり、コアスペースにコンフリクトファイルが無いとの判断の場合、ステップ１の判断結果が偽となって良い。
　～ステップ２～
ステップ１の判断結果が真の場合、エッジサーバ１は、ホームディレクトリ１のツリー構造における所定位置に、第１のディレクトリを追加する。具体的には、例えば、エッジサーバ１は、ルートディレクトリの下位ディレクトリとして、「ｈｉｄｄｅｎ」というディレクトリネームのディレクトリを追加する。そして、エッジサーバ１は、作成した「ｈｉｄｄｅｎ」ディレクトリに、「ｈｉｄｄｅｎ」ディレクトリを追加する前のホームディレクトリ１のルートディレクトリ以下の全てのファイル及びディレクトリを、そのツリー構造を維持したまま移動させる。これにより、エッジサーバ１を使用するユーザは、「ｈｉｄｄｅｎ」ディレクトリ以下のファイルは、第１の通信ネットワークに障害が発生する前のホームディレクトリ１内のファイル及びディレクトリであると判断できる。なお、エッジサーバ１は、「ｈｉｄｄｅｎ」ディレクトリ及び「ｃｏｎｆｌｉｃｔ」ディレクトリのうち少なくとも「ｈｉｄｄｅｎ」ディレクトリをクライアント／ホスト１に対して隠しても良い。
　～ステップ３～
エッジサーバ１は、ホームディレクトリ１の所定位置（例えばルートディレクトリの下位）に、コアスペースのルートディレクトリの全ての下位ディレクトリ及び下位ファイルをコピーする。エッジサーバ１は、クライアント／ホスト１からホームディレクトリ１のルートディレクトリから下位ディレクトリを経由して更に下位へとアクセスされる都度に、アクセス対象のディレクトリ又はファイルをコアスペースからホームディレクトリ１に読み出すことができる。なお、ステップ３において、エッジサーバ１は、コアスペースのルートディレクトリ以下の全てのディレクトリ及びファイルのスタブを、ホームディレクトリ１のルートディレクトリ以下に作成しても良い。
　～ステップ４～
エッジサーバ１は、ホームディレクトリ１のツリー構造における所定位置に、第２のディレクトリを追加する。具体的には、例えば、エッジサーバ１は、ルートディレクトリの下位ディレクトリとして、「ｃｏｎｆｌｉｃｔ」というディレクトリネームのディレクトリを追加する。エッジサーバ１は、アップデートリスト１３０２Ａから特定されるファイルを、パス構造を維持したまま、「ｈｉｄｄｅｎ」ディレクトリから「ｃｏｎｆｌｉｃｔ」ディレクトリに移動する。そして、エッジサーバ１は、「ｃｏｎｆｌｉｃｔ」ディレクトリをコアスペースにマイグレーションし、且つ、リネームリスト及びアップデートリストをコアサーバに送信する。ここで送信されたリネームリストアップデートリストには、「ｃｏｎｆｌｉｃｔ」ディレクトリの追加、及び、「ｃｏｎｆｌｉｃｔ」ディレクトリ以下にパスネーム「Ｂ／Ｘ」のファイルとパスネーム「Ｄ／Ｃ／Ｇ」のファイルが追加されたことがわかる。なお、エッジサーバ１は、「ｈｉｄｄｅｎ」ディレクトリをコアスペースにマイグレーションしないが「ｈｉｄｄｅｎ」ディレクトリをコアスペースにマイグレーションしても良い。
　～ステップ５～
コアスペースとホームディレクトリ２が同期する。ここで言う同期とは、コアスペースにおける、ホームディレクトリ２との差分のあるファイル及びディレクトリが、コアスペースからホームディレクトリ２に読み出されることを言う。その結果、ホームディレクトリ２にコアスペースからファイルが追加される、ホームディレクトリ２におけるファイルがコアスペース内のファイルによって上書きされる、又は、ホームディレクトリ２からファイルが削除される。具体的には、例えば、エッジサーバ２が、コアスペースのリネームリスト及びアップデートリストをコアサーバから取得し、それらのリストと、ホームディレクトリ２のリネームリスト及びアップデートリストとを比較することで、「ｃｏｎｆｌｉｃｔ」ディレクトリ及びその下位のファイルを特定する。そして、エッジサーバ２は、、「ｃｏｎｆｌｉｃｔ」ディレクトリ及びその下位のファイルを、ホームディレクトリ２に読み出す。エッジサーバ２を使用するユーザは、「ｃｏｎｆｌｉｃｔ」ディレクトリ内のファイルが、第１の通信ネットワークに障害が発生する前にエッジサーバ２以外のエッジサーバを使用してアップデートされたファイルだと判断することができる。エッジサーバ２を使用するユーザは、「ｃｏｎｆｌｉｃｔ」ディレクトリ内のファイルのうちの任意のファイルのみを、「ｃｏｎｆｌｉｃｔ」ディレクトリの外にコピー又は移動させて使用することができる。
　コアスペースにマイグレーションされた「ｃｏｎｆｌｉｃｔ」ディレクトリには、「ｃｏｎｆｌｉｃｔ」ディレクトリ無しにコアスペースにマイグレーションされた場合にコアスペースにおけるアップデートされたファイル（最新ファイル）を上書きしてしまい得るファイル（新ファイル）があり得る。しかし、本実施例によれば、そのような新ファイルは「ｃｏｎｆｌｉｃｔ」ディレクトリ以下に配置されているので、そのような新ファイルがコアスペースにマイグレーションされても最新ファイルが上書きされてしまうことが無い。つまり、ファイルの先祖返りが生じない。
　以下、本実施例で行われる種々の処理を詳細に説明する。その際、エッジサーバ１を例に取り説明するが、エッジサーバ１が行う処理は、本実施例に係るファイルサーバシステムに存在する他の各エッジサーバも同様に行うことができる。また、以下の説明において、エッジサーバが行う処理は、エッジ制御プログラムが実行されることで行われて良く、コアサーバが行う処理は、コア制御プログラムが実行されることで行われて良い。
　図１０は、ログイン処理のフローチャートである。
　ログイン処理は、ホームディレクトリに対するログイン要求をエッジサーバ１が受けた場合にエッジサーバ１によって行われる。以下、ログイン先をホームディレクトリ１とする。
　エッジサーバ１は、ホームディレクトリ１に対応付けられているコアスペースに対して、自身によってロックが掛けられているか（ロックが有効か無効か）を判断する（Ｓ６０１）。具体的に、例えば、エッジサーバ１は、コアサーバ２２０に対して、ログイン先のホームディレクトリ１に対応したコアスペースに対応したロックファイルの取得要求を、そのコアスペースを有するコアサーバ２２０に送信する。コアサーバ２２０は、コアスペース毎にロックファイルをメモリ２２１に有しており、ロックファイルの取得要求を受けた場合、その要求で指定されているコアスペースに対応したロックファイルを、要求の送信元であるエッジサーバ１に送信する。エッジサーバ１は、そのロックファイルを受信し、そのロックファイルに、エッジサーバ１のノード番号が記録されているか否かを判断する。
　Ｓ６０１の判断結果が偽の場合（Ｓ６０１：Ｎｏ）、エッジサーバ１は、ホームディレクトリ１のアップデートがあるか否かを判断する（Ｓ６０２）。ホームディレクトリ１のアップデートがあるか否かは、ホームディレクトリ１のリネームリスト及びアップデートリストを基に判断される。
　Ｓ６０２の判断結果が真の場合（Ｓ６０２：Ｙｅｓ）、マイグレーション回復処理（図１４参照）が行われる。
　Ｓ６０２の判断の結果が偽の場合（Ｓ６０２：Ｎｏ）、エッジサーバ１は、コアスペースにロックを掛ける（Ｓ６０３）。具体的には、例えば、エッジサーバ１は、コアサーバ２２０に対して、ログイン先のホームディレクトリ１に対応したコアスペースを指定したロックファイルの取得要求を送信する。コアサーバは、その要求で指定されたコアスペースに対応するロックファイルをエッジサーバ１に送信する。エッジサーバ１が、そのロックファイルを受信する。エッジサーバ１は、そのロックファイルに、いずれのエッジサーバのノード番号が記録されていなければ、エッジサーバ１のノード番号をそのロックファイルに記録し、そのロックファイルをコアサーバ２２０に送信する。これにより、ロックが掛かる。
　ロックを掛けることができなかった場合（例えばロックファイルに既に他のエッジサーバのノード番号が記録されていた場合）（Ｓ６０４：Ｎｏ）、エッジサーバ１は、Ｒｅａｄ－ｏｎｌｙ（すなわち、ホームディレクトリ１についてはリードのみを許可すること）をユーザ（ログイン要求元のクライアント／ホスト１）に通知する（Ｓ６１０）。なぜなら、コアスペースが他のエッジサーバによってロックが掛けられているため、エッジサーバ１が、ホームディレクトリ１に新たにファイルが書き込まれてもそのファイルをコアスペースにマイグレーションすることができないからである。
　ロックを掛けることができた場合（Ｓ６０４：Ｙｅｓ）、ロック延長処理の開始となる（Ｓ６０５）。具体的には、図５を参照して説明したように、エッジサーバ１は、コアサーバ２２０からロック延長問合せを定期的に受信し、その問合せを受信する都度に、ロックを延長するか否かを回答するようになる。
　そして、エッジサーバ１は、ファイルの同期処理を行う（Ｓ６０６）。具体的には、エッジサーバ１は、コアスペースにおけるファイルのうちホームディレクトリ１におけるファイルと異なるファイルをコアスペースからホームディレクトリ１に読み出す。これにより、ホームディレクトリ１におけるファイルがコアスペースからリードされたファイルによって上書きされることになる。なお、同期対象のファイルがコアスペースに無ければ、Ｓ６０６はスキップされる。
　その後、エッジサーバ１は、ホームディレクトリ１に対応したロックフラグをオンにする（Ｓ６０７）。ロックフラグは、エッジサーバ１がコアスペースにロックを掛けたことをエッジサーバ１が認識するためのツールの一例である。
　Ｓ６０７の後、エッジサーバ１は、ＲＷ（つまりリードもライトも可能であること）を、ユーザ（ログイン要求元のクライアント／ホスト１）に通知する（Ｓ６０８）。
　Ｓ６０１の判断結果が真の場合（Ｓ６０１：Ｙｅｓ）、Ｓ６０７及びＳ６０８が行われる。マイグレーションが行われた後にロックは解除されるが、Ｓ６０１：Ｙｅｓのケースとしては、例えば、ユーザがホームディレクトリ１からログアウトしてからホームディレクトリ１からのマイグレーションが行われる前に再度そのユーザがホームディレクトリ１にログインするケースが考えられる。
　図７は、ライト処理のフローチャートである。
　ライト処理は、エッジサーバ１がライト要求をクライアント／ホスト１から受信することを契機として行われる。ここで言う「ライト」は、ファイルのアップデート、追加及び削除のいずれも良く、また、ファイル又はディレクトリのパスネームの変更でも良く、また、ファイルのメタデータのアップデートでも良い。以下、ライトは、ファイルのライトであって、具体的には、ファイルのアップデート又は新規書込みであるとする。
　エッジサーバ１は、クライアント／ホスト１から、ホームディレクトリ１を指定したファイルのライト要求を受信する（Ｓ７０１）。
　エッジサーバ１は、受信したライト要求で指定されているホームディレクトリ１のロックフラグがオンであるか否かを判断する（Ｓ７０２）。
　Ｓ７０２の判断結果が真の場合（Ｓ７０２：Ｙｅｓ）、エッジサーバ１は、ライト要求に従い、ホームディレクトリ１にファイルを書き込む（Ｓ７１１）。また、エッジサーバ１は、ホームディレクトリ1に対応したアップデートリスト１３０２Ａ又はリネームリスト１３０１Ａをアップデートする。
　Ｓ７０２の判断結果が偽の場合（Ｓ７０２：Ｎｏ）、エッジサーバ１は、コアスペースに対してロックを掛ける処理が失敗してからの経過時間（後述のＳ７１３で記録した時刻からの経過時間）が、所定の時間（例えば、１０分）経過しているか否かを判断する（Ｓ７０３）。なお、この所定時間を設けている理由は、エッジサーバ１が、コアスペースに対して頻繁にロックを掛ける処理をする事を避け、一括して更新を反映するためである。
　Ｓ７０３の判断結果が偽の場合（Ｓ７０３：Ｎｏ）、エッジサーバ１は、エラー（Ｒｅａｄ－Ｏｎｌｙ）をクライアント／ホスト１に応答する（Ｓ７１４）。
　Ｓ７０３の判断結果が真の場合（Ｓ７０３：Ｙｅｓ）、エッジサーバ１は、ホームディレクトリ１のアップデートがあるか否かを判断する（Ｓ７０４）。Ｓ７０４は、具体的には、図１０のＳ６０２と同じ処理である。Ｓ７０４は、Ｓ７０３がＹｅｓの場合に行われるので、Ｓ７０２でＮｏの都度に行われる場合に比べて、エッジサーバ１の負荷が軽減される。
　Ｓ７０４の判断結果が真の場合（Ｓ７０４：Ｙｅｓ）、エッジサーバ１は、マイグレーション回復処理を行う（Ｓ７１２）。その後、エッジサーバ１は、Ｓ７０６の処理に進む。
　Ｓ７０４の判断結果が偽の場合（Ｓ７０４：Ｎｏ）、エッジサーバ１は、コアスペースに対してロックを掛ける処理を行う（Ｓ７０５）。
　Ｓ７１２又はＳ７０５の後、図１０のＳ６０４～Ｓ６０７にそれぞれ対応するＳ７０６～Ｓ７０９が行われる。なお、Ｓ７０６：Ｎｏの場合、エッジサーバ１は、Ｓ７０５の処理を最近行った時刻をメモリ等の記憶領域に記録する（Ｓ７１３）。
　Ｓ７０９の後、エッジサーバ１は、他のエッジサーバから、ターゲットファイル（このライト処理においてエッジサーバ１によって開かれているファイル（つまりアップデート対象のファイル））が同期したファイルか否かを判断する（Ｓ７１０）。
　Ｓ７１０の判断結果が偽の場合（Ｓ７１０：Ｎｏ）、エッジサーバ１は、ライト要求に従うファイルをターゲットファイルに上書きする（Ｓ７１１）。
　Ｓ７１０の判断結果が真の場合（Ｓ７１０：Ｙｅｓ）、エッジサーバ１は、エラー（Ｒｅａｄ－Ｏｎｌｙ）を応答する（Ｓ７１４）。なぜなら、ターゲットファイルの中身が、ライト要求を送信するときにクライアント／ホスト１が認識していた中身と異なってしまっているからである。
　一方、ロックを掛けることができなかった場合（Ｓ７０６：Ｎｏ）、エッジサーバ１は、Ｓ７０５の処理を開始し始めた時間を記録する（Ｓ７１３）。その後、エッジサーバは、Ｓ７１４の処理を行う。
　図１２は、マイグレーション処理のフローチャートである。
　マイグレーション処理は、定期的に開始される処理であるが、特定のイベントが発生した場合に開始されても良い。
　エッジサーバ１は、エッジサーバ１が有するホームディレクトリ毎に、ホームディレクトリからログアウトしたユーザのリスト（ログアウトユーザリスト）を取得する（Ｓ８０１）。
　エッジサーバ１は、エッジサーバ１が有するホームディレクトリ毎に、取得したログアウトユーザリストを所定のルールに従って並び替える（Ｓ８０２）。
　エッジサーバ１は、エッジサーバ１が有する全てのホームディレクトリについて、マイグレーションが行われたか否かを判断する（Ｓ８０３）。
　Ｓ８０３の判断結果が偽の場合（Ｓ８０３：Ｎｏ）、エッジサーバ１は、このマイグレーション処理においてＳ８０４以降の処理の対象になっていない１つのホームディレクトリついて、対応するコアスペースが自身によってロックが掛けられているか否かを判断する（Ｓ８０４）。
　Ｓ８０４の判断結果が真の場合（Ｓ８０４：Ｙｅｓ）、エッジサーバ１は、ホームディレクトリ１のアップデートがあるか否かを判断する（Ｓ８０５）。
　Ｓ８０５の判断結果が真の場合（Ｓ８０５：Ｙｅｓ）、エッジサーバ１は、ホームディレクトリ１のリネームリスト及びアップデートリストから特定されるファイルをコアスペースにマイグレーションし、且つ、それらのリストをコアサーバに送信する（Ｓ８１０）。
　エッジサーバ１は、Ｓ８１０でマイグレーション対象となったホームディレクトリ１を使用しているユーザが、ログアウトしているか否かを判断する（Ｓ８１１）。
　Ｓ８１１の判断結果が偽の場合（Ｓ８１１：Ｎｏ）、ユーザによりホームディレクトリ１内のファイルがアップデートされる可能性があるので、エッジサーバ１は、Ｓ８０３の処理を行う。
　Ｓ８１１の判断結果が真の場合（Ｓ８１１：Ｙｅｓ）、或いは、Ｓ８０５の判断結果が偽の場合（Ｓ８０５：Ｎｏ）、エッジサーバ１は、ホームディレクトリに対応したロックフラグをオフとする（Ｓ８０６）。
　エッジサーバ１は、コアサーバ２２０からのロック延長問合せがあった場合に、ロックを延長しないと回答する（Ｓ８０７）。エッジサーバ１は、コアサーバ２２０に対して、ロックファイルから自身のノード番号を削除する処理を要求する（Ｓ８０８）。その後、エッジサーバ１は、Ｓ８０３の処理を行ない、マイグレーションが行われていない他のホームディレクトリがあるか否かを判断する。
　図１３は、ホームディレクトリ回復処理のフローチャートである。
　エッジサーバ１のホームディレクトリ回復処理は、エッジサーバ１の交換、エッジサーバ１のリブート、他のエッジサーバからエッジサーバ１へのフェイルオーバ等の特定のイベントが発生した場合に行われる。
　エッジサーバ１は、全てのホームディレクトリについて、回復処理が行われたか否かを判断する（Ｓ９０１）。
　Ｓ９０１の判断結果が真の場合（Ｓ９０１：Ｙｅｓ）、エッジサーバ１は、処理を終了する。
　Ｓ９０１の判断結果が偽の場合（Ｓ９０１：Ｎｏ）、エッジサーバ１は、回復処理が行われていないホームディレクトリのうちの１つのホームディレクトリについて、ホームディレクトリのアップデートがあるか否かを判断する（Ｓ９０２）。
　Ｓ９０２の判断結果が真の場合（Ｓ９０２：Ｙｅｓ）、エッジサーバ１は、マイグレーション回復処理を行う（Ｓ９０３）。
　Ｓ９０２の判断結果の偽の場合（Ｓ９０２：Ｎｏ）、エッジサーバ１は、コアサーバ２２０から、コアスペースのリネームリストとアップデートリストを取得する（Ｓ９０４）。
　エッジサーバ１は、リネームリスト及びアップデートリストに関連付けられているシーケンシャル番号をチェックし、シーケンシャル番号が連続しているか否かを判断する（Ｓ９０５）。
　Ｓ９０５の判断結果が真の場合（Ｓ９０５：Ｙｅｓ）、エッジサーバ１は、コアスペースからホームディレクトリにファイルを読み出すことで同期を行うことができる（Ｓ９０６）。
　Ｓ９０５の判断結果が偽の場合（Ｓ９０５：Ｎｏ）、エッジサーバ１は、コアスペースの全てのファイルをホームディレクトリにコピーするリストア処理を行う（Ｓ９０７）。
　図１４は、本実施例に係るマイグレーション回復処理のフローチャートである。
　エッジサーバ１は、図１０のＳ６０１と同じ方法で、ホームディレクトリ１に対応するコアスペースのロックが有効か否かを判断する（Ｓ１４０１）。
　Ｓ１４０１の判断結果が真の場合（Ｓ１４０１：Ｙｅｓ）、エッジサーバ１は、Ｓ１４０５～Ｓ１４０８の処理を行う。すなわち、ロック延長処理が開始される（Ｓ１４０５）。エッジサーバ１は、ホームディレクトリ１に対応したロックフラグをオンにする（Ｓ１４０６）。エッジサーバ１は、図１２のマイグレーション処理を行う（Ｓ１４０８）。なお、マイグレーション処理は行われなくても良い。マイグレーション処理は定期的に行われる処理だからである。
　Ｓ１４０１の判断結果が偽の場合（Ｓ１４０１：Ｎｏ）、エッジサーバ１は、他のエッジサーバからのアップデートリスト及びリネームリストがあるか否かを判断する（Ｓ１４０２）。例えば、エッジサーバ１は、コアスペースについて他のエッジサーバからのアップデートリスト又はリネームリストがあるか否かを、コアサーバに問い合わせる。コアサーバは、コアスペースについて他のエッジサーバからのアップデートリスト又はリネームリストがあれば、そのリストをエッジサーバ１に送信する。両方のリストがあれば両方のリストが送信される。
　Ｓ１４０２の判断結果が偽の場合（Ｓ１４０２：Ｎｏ）、エッジサーバ１は、コアスペースにロックを掛ける（Ｓ１４０３）。ロックを掛けることができた場合、Ｓ１４０５～Ｓ１４０８が行われる。
　ロックを掛けることができなかった場合（Ｓ１４０４：Ｎｏ）、エッジサーバ１は、コアスペースが他のエッジサーバによってロックが掛けられているか否かを判断する（Ｓ１４０９）。この判断は、コアスペースについて取得されたロックファイルに、他のエッジサーバのノード番号が記載されているか否かの判断である。
　Ｓ１４０９の判断結果が真の場合（Ｓ１４０９：Ｙｅｓ）、エッジサーバ１は、現在のホームディレクトリのルートディレクトリ以下の全てのファイル及びディレクトリを「ｈｉｄｄｅｎ」ディレクトリに移動する（Ｓ１４１０）（図７のステップ２参照）。次に、エッジサーバ１は、コアスペースのルートディレクトリ以下のファイル及びディレクトリのうち少なくともルートディレクトリの下位ディレクトリ（及び下位ファイル）を、ホームディレクトリ１のルートディレクトリ以下にコピーする（Ｓ１４１１）（図７のステップ３参照）。つまり、エッジサーバ１は、コアスペースのルートディレクトリ以下のディレクトリ（及びファイル）をホームディレクトリ１にリストアする。その後、エッジサーバ１は、ホームディレクトリ１のルートディレクトリの下位ディレクトリとして「ｃｏｎｆｌｉｃｔ」ディレクトリを生成し、「ｈｉｄｄｅｎ」ディレクトリ以下のファイル及びディレクトリのうち、リネームリスト１３０１Ａ及びアップデートリスト１３０２Ａから特定されるファイル及びディレクトリを、「ｃｏｎｆｌｉｃｔ」ディレクトリにコピーする（Ｓ１４１２）（図８のステップ４参照）。
　Ｓ１４０９の判断結果が偽の場合（Ｓ１４０９：Ｎｏ）、エッジサーバ１は、処理を終了する。
　Ｓ１４０２の判断結果が真の場合（Ｓ１４０２：Ｙｅｓ）、エッジサーバ１は、Ｓ１４１０～Ｓ１４１２を行う。
　実施例１によれば、ホームディレクトリ１におけるファイル及びディレクトリのうちコアスペースにおけるファイル及びディレクトリと異なるファイルが「ｃｏｎｆｌｉｃｔ」ディレクトリにコピーされ、その「ｃｏｎｆｌｉｃｔ」ディレクトリがコアスペースにマイグレーションされる。これにより、コアスペースにおいて先祖返りが生じることを回避することができる。
　次に、実施例２について説明する。その際、実施例１との相違点を主に説明し、実施例１との共通点については説明を省略或いは簡略する。具体的には、実施例１と２とで主に異なるのは、マイグレーション回復処理であるので、以下では、実施例２に係るマイグレーション回復処理を重点的に説明する。
　その前に、まず、図１５を参照して、実施例２において第１通信ネットワークに障害が生じる前とその障害の回復の例を説明する。
　図１５の上段に示すように、第１の通信ネットワークの障害が発生する前、ホームディレクトリ１のリネームリストが示すように（図１７参照）、パス「／Ａ／Ｃ」がパス「／Ａ／Ｄ／Ｃ」へとアップデートされ、ホームディレクトリ１のアップデートリストが示すように、ファイル「Ｘ」及び「Ｇ」がアップデートされたとする。
　図１５の下段に示すように、ホームディレクトリ２では、ディレクトリ「Ｂ」に下位ファイル「Ｙ」が追加され、ディレクトリ「Ｃ」からファイル「Ｇ」がディレクトリ「Ｂ」に移動されたとする。これにより、エッジサーバ２が、ホームディレクトリ２のアップデートリスト１３０２Ｂに、「／Ａ／Ｂ／Ｇ」、「／Ａ／Ｂ／Ｙ」及び「／Ａ／Ｂ」を記録する（図１５下段及び図１７参照）。
　エッジサーバ２は、ホームディレクトリ２におけるアップデートされたファイル「Ｙ」及び移動されたファイル「Ｇ」を、コアスペースにマイグレーションする。また、エッジサーバ２は、ホームディレクトリ２のアップデートリスト１３０２Ｂ（及びリネームリスト）をコアサーバに送信する。この結果、図１５下段及び図１７に示すように、コアサーバは、ホームディレクトリ２のアップデートリスト１３０２Ｂ（及びリネームリスト）を受信し有することになる。
　その後、第１の通信ネットワークの障害が回復した場合、図１６に示す処理が行われる。
　～ステップ１～
ステップ１では、図７のステップ１で行われる処理と同様の処理が行われる。
　～ステップ２～
ステップ１の判断結果が真の場合（ステップ１でリネームリスト又はアップデートリスト１３０２Ｂがあると判断された場合）、エッジサーバ１は、ホームディレクトリ１をコアスペースに同期させる。つまり、エッジサーバ１は、コアスペースにおけるアップデートファイル「Ｙ」及び「Ｇ」（コアスペースのアップデートリスト１３０２Ｂから特定されるファイル）をホームディレクトリ１に読み出す。これにより、ディレクトリ「Ｂ」の下位に、最新ファイル「Ｙ」及び「Ｇ」がマージされる。なお、ファイル「Ｇ」に関して、エッジサーバ１は、パスネームが違うものの、パスネームから特定されるＵＵＩＤにより、ホームディレクトリ１にディレクトリ「Ｃ」の下位ファイルとしてファイル「Ｇ」があるが、ディレクトリ「Ｂ」の下位ファイルとしてファイル「Ｇ」がマージされたことを認識することができる。そして、この段階で、エッジサーバ１は、ホームディレクトリ1のアップデートリスト１３０２Ａから、ファイル「Ｇ」のパスネームを削除する。後のステップ３で、ホームディレクトリ１における旧いファイル「Ｇ」がコアスペースにマイグレーションされないようにするためである。また、もし、ホームディレクトリ１とコアスペースにおいてアップデートファイル「Ｇ」のパスネームが同じであり、コアスペースからファイル「Ｇ」を読み出した場合、エッジサーバ１は、ホームディレクトリ１のアップデートファイル「Ｇ」のアップデート時点（メタデータ中のタイムスタンプ）とコアスペースのアップデートファイル「Ｇ」のアップデート時点（メタデータ中のタイムスタンプ）とを比較し、旧いファイル「Ｇ」に新しいファイル「Ｇ」を上書きすることになる。つまり、図１６の例では、パスネームが異なるため、ファイル「Ｇ」がホームディレクトリ１で共存するが、パスネームが同じであれば、旧いファイル「Ｇ」に代えて新しいファイル「Ｇ」が存在することになる。
　～ステップ３～
エッジサーバ１は、コアスペースに格納されていないアップデートファイル「Ｘ」（アップデートリスト１３０２Ａから特定されるファイル）をコアスペースにマイグレーションする。なお、ディレクトリ「Ｄ」の下位ファイル「Ｇ」もアップデートファイルであるが、前述したように、そのファイル「Ｇ」のパスネームはアップデートリスト１３０２Ａから削除されるので（コアスペースからのファイル「Ｇ」の方が新しいので）、エッジサーバ１は、ディレクトリ「Ｄ」の下位ファイル「Ｇ」はコアスペースにマイグレーションしない。また、前述したように、エッジサーバ１は、マイグレーションの場合、リネームリスト１３０１Ａ及びアップデートリスト１３０２Ａをコアサーバに送信する。コアサーバは、そのリネームリスト１３０１Ａ（及びアップデートリスト１３０２Ａ）に基づき、パス「／Ａ／Ｃ」をパス「／Ａ／Ｄ／Ｃ」にアップデートし、且つ、ディレクトリ「Ｃ」の下位ファイルとして最新ファイル「Ｇ」を追加する。つまり、ホームディレクトリ１のディレクトリ構造の一部がコアスペースに反映される。これにより、最新ファイル「Ｇ」には、ディレクトリ「Ｂ」を含むパス経由でもディレクトリ「Ｃ」を含むパス経由でもアクセスすることが可能である。マイグレーション処理（ホームディレクトリのアップデートのコアスペースへの反映）と、同期処理（コアスペースのアップデートのホームディレクトリへの反映）は、定期的に行われる。従って、ステップ３でのコアスペースのアップデートは、やがて、ホームディレクトリ２に反映される。これにより、ホームディレクトリ２のディレクトリ構造が、ステップ３でのコアスペースのディレクトリ構造と同じになる。
　図１８は、実施例２に係るマイグレーション回復処理のフローチャートである。
　図１８によればＳ１８０１～Ｓ１８０６は、図１４のＳ１４０１～Ｓ１４０６とそれぞれ同じである。
　Ｓ１８０６の後、エッジサーバ１は、コアスペースのアップデートをホームディレクトリ１に反映する同期処理を行うことができる。すなわち、エッジサーバ１は、コアスペースのアップデート（コアスペースのリネームリスト及びアップデートリストから特定されるファイル及びディレクトリ）をホームディレクトリ１に読み出す。その後、エッジサーバ１は、図１２のマイグレーション処理を行うことができる。
　Ｓ１８０９の判断結果が真の場合（Ｓ１８０９：Ｙｅｓ）、エッジサーバ１は、Ｓ１８０７と同じ同期処理を行うことができる（Ｓ１８１０）。
　実施例２によれば、ホームディレクトリ１に、コアスペースにおけるアップデートファイルに対応する旧いアップデートファイルがあっても、そのアップデートファイルはコアスペースにマイグレーションされない。これにより、コアスペースにおいて先祖返りが生じることを回避することができる。
　次に、実施例３について説明する。その際、実施例１との相違点を主に説明し、実施例１との共通点については説明を省略或いは簡略する。具体的には、実施例１と３とで主に異なるのは、マイグレーション回復処理であるので、以下では、実施例３に係るマイグレーション回復処理を重点的に説明する。
　その前に、まず、図１９を参照して、実施例２において第１通信ネットワークに障害が生じる前とその障害の回復の例を説明する。
　図１９の上段に示すように、第１の通信ネットワークの障害が発生する前、ホームディレクトリ１のリネームリスト１３０１Ａが示す通り（図２２参照）、パス「／Ａ／Ｃ」がパス「／Ａ／Ｄ／Ｃ」へとアップデートされ、ホームディレクトリ１のアップデートリスト１３０２Ａが示すように、ファイル「Ｘ」及び「Ｇ」がアップデートされたとする。第１の通信ネットワークの障害が発生した場合、ユーザがホームディレクトリ１に代えてホームディレクトリ２にログインするが、ホームディレクトリ２のツリー構造は、第１の通信ネットワークの障害が発生した時点でのコアスペースのツリー構造と同じである。
　図１９の下段に示すように、ホームディレクトリ２では、パス「／Ａ／Ｃ」がパス「／Ａ／Ｂ／Ｃ」へとアップデートされ、ディレクトリ「Ｂ」の下位ファイル「Ｙ」がアップデートされ、ディレクトリ「Ｃ」の下位ファイル「Ｇ」がアップデートされたとする。これにより、エッジサーバ２が、ホームディレクトリ２のリネームリスト１３０１Ｂに、ＦＭ「／Ａ／Ｃ」及びＴＯ「／Ａ／Ｂ／Ｃ」を記録し、ホームディレクトリ２のアップデートリスト１３０２Ｂに、「／Ａ／Ｂ／Ｃ／Ｇ」、「／Ａ／Ｂ／Ｙ」及び「／Ａ／Ｂ」を記録する（図１９下段及び図２２参照）。
　エッジサーバ２は、ホームディレクトリ２におけるアップデートされたファイル「Ｙ」及び「Ｇ」を、コアスペースにマイグレーションする。また、エッジサーバ２は、ホームディレクトリ２のアップデートリスト１３０２Ｂ及びリネームリスト１３０１Ｂをコアサーバに送信する。この結果、図１９下段及び図２２に示すように、コアサーバは、ホームディレクトリ２のアップデートリスト１３０２Ｂ及びリネームリスト１３０１Ｂを受信し有することになる。
　その後、第１の通信ネットワークの障害が回復した場合、図２０及び図２１に示す処理が行われる。
　～ステップ１～
ステップ１では、エッジサーバ１は、ディレクトリ構造のリバース、すなわち、リネームリスト１３０１Ａを基に、アップデート後のパスの構造「／Ａ／Ｄ／Ｃ」を、アップデート前のパスの構造「／Ａ／Ｃ」に戻す。これにより、ディレクトリ「Ｄ」から下位ディレクトリ「Ｃ」が無くなり、ディレクトリ「Ｃ」が、ルートディレクトリの下位ディレクトリとなる。
　～ステップ２～
エッジサーバ１は、ディレクトリ構造のリバースがなされたホームディレクトリ１における各アップデートファイルのパスネームから、ホームディレクトリ１における各アップデートファイルを特定し、ホームディレクトリ１における各アップデートファイルのアップデート時点と、コアスペースにおける各アップデートファイルのアップデート時点とを比較する。エッジサーバ１は、ホームディレクトリ１に旧いアップデートファイルがあれば、ホームディレクトリ１のルートディレクトリの下位ディレクトリ「ｃｏｎｆｌｉｃｔ」を追加し、且つ、その「ｃｏｎｆｌｉｃｔ」ディレクトリの下位ディレクトリとして、「ｃｏｎｆｌｉｃｔ」ディレクトリを作成した時点（例えば年月日で表現された時点）をディレクトリネームとして有するディレクトリ（以下、タイムスタンプディレクトリ）を追加する。そして、エッジサーバ１は、ホームディレクトリ１における旧いアップデートファイル「Ｇ」を、パス構造を維持したまま、タイムスタンプディレクトリにコピーする。また、エッジサーバ１は、タイムスタンプディレクトリにコピーした旧いアップデートファイルのパスネームをアップデートリスト１３０２Ａから削除する。次に、エッジサーバ１は、ホームディレクトリ１のアップデートファイル（アップデートリスト１３０２Ａから特定されるファイル）、及び「ｃｏｎｆｌｉｃｔ」ディレクトリを、コアスペースにマイグレーションし、且つ、アップデートリスト１３０２Ａ及びリネームリスト１３０１Ａをコアサーバに送信する。これにより、コアスペースに、「ｃｏｎｆｌｉｃｔ」ディレクトリが存在することになり、また、コアスペースにおいて、アップデートリスト１３０２Ａ及びリネームリスト１３０１Ａを基に、ディレクトリ「Ｂ」に下位ファイル「Ｘ」が追加され、且つ、ルートディレクトリに下位ディレクトリ「Ｄ」が追加される。なお、コアサーバは、アップデートリスト１３０２Ａ及びリネームリスト１３０１Ａを受信しても、アップデートリスト１３０２Ｂ及びリネームリスト１３０１Ｂを有している。具体的には、例えば、コアサーバは、１つのコアスペースについて、エッジサーバ毎に、受信したリネームリスト及びアップデートリストを有することができる。コアサーバは、同一のエッジサーバから新たにリネームリスト及びアップデートリストを受信した場合、そのエッジサーバから過去に受けたリネームリスト及びアップデートリストを削除し、新たに受信したリネームリスト及びアップデートをメモリに格納することができる。
　～ステップ３～
エッジサーバ１は、他のエッジサーバ２からのリスト１３０１Ｂ及び１３０２Ｂを基に、ホームディレクトリ１に格納されていないファイル（ディレクトリ）を、コアスペースからホームディレクトリに読み出す（同期）。ここでは、ファイル「Ｙ」及び「Ｇ」と、アップデート後のディレクトリ「Ｂ」が、ホームディレクトリ１に読み出される。図２１では、ホームディレクトリ１における同期された（上書きされた）ディレクトリ及びファイルのアイコンに、チェックマークが付されており、構造が戻されたパスを経由するディレクトリのアイコンに、パス構造が最新の構造に戻ったことを意味するマーク「Ｒ」が付されている。
　図２３は、実施例３に係るマイグレーション回復処理のフローチャートである。
　図２３によれば、図１４のＳ１４１０～Ｓ１４０６に代えて、Ｓ２３１０～Ｓ２３０６が行われる。
　Ｓ２３０６の次に、エッジサーバ１は、リネームリスト１３０１Ａを基にホームディレクトリ１のディレクトリ構造を元に戻す（Ｓ２３０７）（図２０のステップ１参照）。そして、エッジサーバ１は、図１２のマイグレーション処理を行う（図２１のステップ２参照）。
　Ｓ２３０９の判断結果が真の場合（Ｓ２３０９：Ｙｅｓ）、エッジサーバ１は、ホームディレクトリ１をコアスペースに同期させる同期処理を行う（Ｓ２３１２）。
　実施例３によれば、ホームディレクトリ１におけるアップデートファイルとコアスペースにおけるアップデートファイルとのうちどちらが旧いか判断され、ホームディレクトリ１に旧いアップデートファイルがあれば、その旧いアップデートファイルが「ｃｏｎｆｌｉｃｔ」ディレクトリにコピーされ、その「ｃｏｎｆｌｉｃｔ」ディレクトリがコアスペースにマイグレーションされる。これにより、コアスペースにおいて先祖返りが生じることを回避することができる。
　また、実施例３によれば、図２０のステップ１に示すように、ホームディレクトリ１のディレクトリ構造がリバースされるので、ホームディレクトリ１のディレクトリ構造がリバースされない実施例２に比べて、計算量を減らすことができる。
　以上、幾つかの実施例を説明したが、本発明は、それらの実施例に限定されず、その要旨を逸脱しない範囲内で変形可能であることは言うまでもない。
　例えば、実施例３では、図２０のステップ１において、コアスペースのディレクトリ構造がリネームスペース１３０１Ｂに基づいてリバースされても良く、その上で、図２１のステップ２が行われ、その後、コアスペースのディレクトリ構造がリバース前の状態に復元されても良い。
　また、実施例３では、「ｃｏｎｆｉｉｃｔ」ディレクトリの下位に、コピーされるファイル毎に、そのファイルのアップデート時点（タイムスタンプ）を表す値をディレクトリネームとして有するディレクトリが追加されても良い。
　また、例えば、実施例１では、「ｃｏｎｆｌｉｃｔ」ディレクトリの下位ディレクトリとして、「ｃｏｎｆｌｉｃｔ」ディレクトリが作成された時点（タイムスタンプ）を表す値をディレクトリネームとして有するディレクトリが追加され、その追加されたディレクトリの下位に、「ｈｉｄｄｅｎ」ディレクトリ以下のファイルがコピーされても良い。
１２０…エッジサーバ、２２０…コアサーバ

 

Claims (13)

  1. 　コアサーバと通信する通信インタフェースデバイスと、
    　前記通信インタフェースデバイスに接続されており、第１ホームディレクトリを提供し、前記第１ホームディレクトリに対するライト要求に従い前記第１ホームディレクトリにファイルを書き込むプロセッサと
    を有し、
    　前記コアサーバは、コアスペースを提供し、
    　前記コアスペースは、前記第１及び第２ホームディレクトリの各々のアップデートのコピー先となるファイルシステムスペースであり、
    　前記第１ホームディレクトリは、ユーザが使用する第１ファイルシステムスペースであり、
    　前記第２ホームディレクトリは、前記ユーザが使用し別のエッジサーバによって提供される第２ファイルシステムスペースであり、
    　前記プロセッサが、前記第１ホームディレクトリにおける第１ファイルが前記コアスペースにおける第２ファイルを上書きすることを回避する確保処理を前記第１ホームディレクトリのアップデートの前記コアスペースへのコピーの前に行い、
    　前記第２ファイルは、前記第２ホームディレクトリにおいてアップデートされ前記コアスペースにコピーされたファイルであり、
    　前記第１ファイルは、前記第２ファイルに対応し前記第１ホームディレクトリにおいてアップデートされ前記コアスペースにコピーされていないファイルである、
    エッジサーバ。
  2. 　前記確保処理が、下記の処理を含み、
    　　前記第１ホームディレクトリに第１ディレクトリを作成すること、
    　　前記第１ファイルのパス構造を維持したまま、前記第１ファイルを前記第１ディレクトリにコピーすること、
    　前記第１ホームディレクトリのアップデートの前記コアサーバへのコピーとして、前記プロセッサは、前記第１ディレクトリを前記コアスペースにコピーする、
    請求項１記載のエッジサーバ。
  3. 　前記確保処理が、下記の処理を含み、
    　　前記第１ホームディレクトリに第２ディレクトリを作成すること、
    　　前記第１ホームディレクトリのルートディレクトリに属し前記第２ディレクトリ以外のディレクトリ及びファイルを、パス構造を維持したまま前記第２ディレクトリに移動すること、
    　前記第１ディレクトリにコピーされた前記第１ファイルは、前記第２ディレクトリに移動されたディレクトリ及びファイルにおける前記第１ファイルであり、前記第１ファイルのパス構造は、前記第１ディレクトリでのパス構造であり、
    請求項２記載のエッジサーバ。
  4. 　前記第１ディレクトリにコピーされたファイルは、前記第１ホームディレクトリにおいてアップデートされた全てのファイルである、
    請求項３記載のエッジサーバ。
  5. 　前記確保処理が、更に、前記コアスペースのルートディレクトリの少なくとも下位ディレクトリ又は下位ファイルを、前記第１ホームディレクトリにコピーすること、を含む、
    請求項４記載のエッジサーバ。
  6. 　前記確保処理が、下記の処理を含む、
    　　前記第１ファイルのアップデート時点と前記第２ファイルのアップデート時点のどちらが旧いか判断すること、
    　　前記第２ファイルのアップデート時点よりも前記第１ファイルのアップデート時点の方が旧い場合に、前記第１ファイルを前記第１ディレクトリにコピーすること、
    請求項２記載のエッジサーバ。
  7. 　前記確保処理が、更に、下記を含む、
    　　前記第１ホームディレクトリのディレクトリ構造をアップデート前のディレクトリ構造にリバースすること、
    　　前記リバース後に、前記第１ホームディレクトリにおいてアップデートされたファイルのうち前記第１ファイルを特定すること、
    請求項６記載のエッジサーバ。
  8. 　前記確保処理は、前記第１ホームディレクトリの下位に、前記第１ホームディレクトリの作成時点又は前記第１ファイルのアップデート時点を表す値をディレクトリネームとして有するディレクトリであるタイムスタンプディレクトリを作成すること、を含み、
    　前記プロセッサは、前記確保処理において、前記タイムスタンプディレクトリの下位に前記第１ファイルをコピーする、
    請求項６記載のエッジサーバ。
  9. 　前記プロセッサは、前記第１ホームディレクトリのアップデートの前記コアサーバへのコピーの後に、前記コアスペースのアップデートの前記第１ホームディレクトリへのコピーを行う、
    請求項６記載のエッジサーバ。
  10. 　前記確保処理は、下記の処理を含む、
    　　前記コアスペースのアップデートを前記第１ホームディレクトリにコピーする同期処理、
    　　前記同期処理において、前記第１ファイル及び前記第２ファイルのそれぞれのパス構造が異なっていれば、前記第２ファイルの前記コアスペースでのパス構造を維持したまま前記第２ファイルを前記第１ホームディレクトリにコピーし、且つ、前記第１ホームディレクトリのアップデートから前記第１ファイルを除外すること、
    請求項１記載のエッジサーバ。
  11. 　前記第１ホームディレクトリのアップデートの前記コアスペースの反映により前記第１ファイルのアップデートされたパス構造が前記第２ファイルへのパス構造として前記コアスペースに追加されるように、前記確保処理は、前記第１ホームディレクトリのアップデートが前記第１ファイルのパス構造のアップデートを含むことを維持する、
    請求項４記載のエッジサーバ。
  12. 　前記確保処理は、更に、下記の処理を含む、
    　　前記同期処理において、前記第１ファイル及び前記第２ファイルのそれぞれのパス構造が同じであり、前記第１ファイルのアップデート時点が前記第２ファイルのアップデート時点よりも旧ければ、前記第２ファイルを前記第１ファイルに上書きすること、
    請求項４記載のエッジサーバ。
  13. 　第１エッジサーバによって、コアサーバが提供するコアスペースに対応した第１ホームディレクトリを提供し、
    　第１エッジサーバによって、前記第１ホームディレクトリをアップデートし、
    　第１エッジサーバによって、前記第１ホームディレクトリにおける第１ファイルが前記コアスペースにおける第２ファイルを上書きすることを回避する確保処理を前記第１ホームディレクトリのアップデートの前記コアスペースへのコピーの前に行い、
    　前記コアスペースは、前記第１及び第２ホームディレクトリの各々のアップデートのコピー先となるファイルシステムスペースであり、
    　前記第１ホームディレクトリは、ユーザが使用する第１ファイルシステムスペースであり、
    　前記第２ホームディレクトリは、前記ユーザが使用し第２エッジサーバによって提供される第２ファイルシステムスペースであり、
    　前記第２ファイルは、前記第２ホームディレクトリにおいてアップデートされ前記コアスペースにコピーされたファイルであり、
    　前記第１ファイルは、前記第２ファイルに対応し前記第１ホームディレクトリにおいてアップデートされ前記コアスペースにコピーされていないファイルである、
    記憶制御方法。
PCT/JP2013/061798 2013-04-22 2013-04-22 エッジサーバ及び記憶制御方法 WO2014174578A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/JP2013/061798 WO2014174578A1 (ja) 2013-04-22 2013-04-22 エッジサーバ及び記憶制御方法
US14/349,616 US9286318B2 (en) 2013-04-22 2013-04-22 Edge server and storage control method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2013/061798 WO2014174578A1 (ja) 2013-04-22 2013-04-22 エッジサーバ及び記憶制御方法

Publications (1)

Publication Number Publication Date
WO2014174578A1 true WO2014174578A1 (ja) 2014-10-30

Family

ID=51791189

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2013/061798 WO2014174578A1 (ja) 2013-04-22 2013-04-22 エッジサーバ及び記憶制御方法

Country Status (2)

Country Link
US (1) US9286318B2 (ja)
WO (1) WO2014174578A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10805394B2 (en) 2015-01-30 2020-10-13 Hitachi, Ltd. File server apparatus having shared file system with file and directory operation processing

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8402049B2 (en) * 2010-05-27 2013-03-19 International Business Machines Corporation Metadata cache management
US10936541B2 (en) * 2018-08-29 2021-03-02 Red Hat, Inc. Preserving symbolic links and paths in a file system using an intermediate file system structure

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006134214A (ja) * 2004-11-09 2006-05-25 Hitachi Ltd ファイルのバージョン管理方法および計算機システム
JP2009501397A (ja) * 2005-07-12 2009-01-15 マイクロソフト コーポレーション 分散ストレージを有するネットワークコンピュータシステムにおけるデータの単一ビュー
JP2009265930A (ja) * 2008-04-24 2009-11-12 Hitachi Ltd ストレージサブシステムおよびストレージシステム

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0568231B1 (en) * 1992-04-29 1999-03-10 Sun Microsystems, Inc. Methods and apparatus for providing multiple outstanding operations in a cache consistent multiple processor computer system
US6298386B1 (en) * 1996-08-14 2001-10-02 Emc Corporation Network file server having a message collector queue for connection and connectionless oriented protocols
US6173291B1 (en) * 1997-09-26 2001-01-09 Powerquest Corporation Method and apparatus for recovering data from damaged or corrupted file storage media
US6618735B1 (en) * 1999-06-30 2003-09-09 Microsoft Corporation System and method for protecting shared system files
US6718372B1 (en) * 2000-01-07 2004-04-06 Emc Corporation Methods and apparatus for providing access by a first computing system to data stored in a shared storage device managed by a second computing system
GB2364851B (en) * 2000-07-15 2002-07-31 3Com Corp Identifying an edge switch and port to which a network user is attached
US7966353B2 (en) * 2005-01-31 2011-06-21 Broadcom Corporation Method and system for flexibly providing shared access to non-data pool file systems
US7870154B2 (en) * 2007-09-28 2011-01-11 Hitachi, Ltd. Method and apparatus for NAS/CAS unified storage system
WO2011148496A1 (ja) 2010-05-27 2011-12-01 株式会社日立製作所 通信ネットワークを介してリモートのファイルサーバにファイルを転送するローカルのファイルサーバ、及び、それらのファイルサーバを有するストレージシステム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006134214A (ja) * 2004-11-09 2006-05-25 Hitachi Ltd ファイルのバージョン管理方法および計算機システム
JP2009501397A (ja) * 2005-07-12 2009-01-15 マイクロソフト コーポレーション 分散ストレージを有するネットワークコンピュータシステムにおけるデータの単一ビュー
JP2009265930A (ja) * 2008-04-24 2009-11-12 Hitachi Ltd ストレージサブシステムおよびストレージシステム

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10805394B2 (en) 2015-01-30 2020-10-13 Hitachi, Ltd. File server apparatus having shared file system with file and directory operation processing

Also Published As

Publication number Publication date
US9286318B2 (en) 2016-03-15
US20150227550A1 (en) 2015-08-13

Similar Documents

Publication Publication Date Title
US20210200641A1 (en) Parallel change file tracking in a distributed file server virtual machine (fsvm) architecture
US9116913B2 (en) File storage system and file cloning method
US10769024B2 (en) Incremental transfer with unused data block reclamation
US8316066B1 (en) Shadow directory structure in a distributed segmented file system
US7865772B2 (en) Management device and management method
JP4806572B2 (ja) データミラーリングによって参照負荷を分散するストレージシステムにおけるアクセスの制御
JP4451293B2 (ja) 名前空間を共有するクラスタ構成のネットワークストレージシステム及びその制御方法
US7461222B2 (en) Method for mirroring data between clustered NAS systems
JP4919851B2 (ja) ファイルレベルの仮想化を行う中間装置
US7836017B1 (en) File replication in a distributed segmented file system
US20080235300A1 (en) Data migration processing device
WO2012035588A1 (en) Method for managing information processing system and data management computer system
JP2008033912A (ja) Ｎａｓ向けのｃｄｐの方法および装置
US10852996B2 (en) System and method for provisioning slave storage including copying a master reference to slave storage and updating a slave reference
JP2003280964A (ja) スナップショット取得方法、ストレージシステム及びディスク装置
JP2009217404A (ja) ストレージシステム
CN101084481A (zh) 在群集存储环境中执行并行数据迁移的方法
US20130054528A1 (en) Computer system and data access control method
US10031682B1 (en) Methods for improved data store migrations and devices thereof
JP6298903B2 (ja) 計算機システム、分散オブジェクト共有方法、エッジノード
US8612495B2 (en) Computer and data management method by the computer
US7730351B2 (en) Per file dirty region logging
US20230056217A1 (en) Failover and failback of distributed file servers
WO2014174578A1 (ja) エッジサーバ及び記憶制御方法
US7962600B2 (en) WAFS disconnected-mode read-write access

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 14349616

Country of ref document: US

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13882669

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13882669

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP