US20140259123A1 - Aliasing of exported paths in a storage system - Google Patents
Aliasing of exported paths in a storage system Download PDFInfo
- Publication number
- US20140259123A1 US20140259123A1 US14/286,645 US201414286645A US2014259123A1 US 20140259123 A1 US20140259123 A1 US 20140259123A1 US 201414286645 A US201414286645 A US 201414286645A US 2014259123 A1 US2014259123 A1 US 2014259123A1
- Authority
- US
- United States
- Prior art keywords
- resource
- filehandle
- entry
- access
- client
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
-
- 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/13—File access structures, e.g. distributed indices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
- G06F3/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]
Definitions
- Features generally relate to the field of computers, and, more particularly, to aliasing of exported paths in a storage system.
- Modern computer networks can include various types of storage servers.
- Storage servers can be used for many different purposes, such as to provide multiple users with access to shared data or to back up mission-critical data.
- a file server is a type of storage server which operates on behalf of one or more clients to store and manage shared files in a set of mass storage devices, such as magnetic or optical storage based disks or tapes.
- the mass storage devices are typically organized into one or more volumes of Redundant Array of Independent (or Inexpensive) Disks (RAID).
- RAID Redundant Array of Independent
- a single physical file server may implement multiple independent file systems, sometimes referred to as “virtual filers”.
- a file server can be used in a network attached storage (NAS) configuration.
- NAS network attached storage
- a file server can be implemented in the form of an appliance, called a filer, that attaches to a network, such as a local area network (LAN) or a corporate intranet.
- LAN local area network
- An example of such an appliance is any of the Filer products made by Network Appliance, Inc. in Sunnyvale, Calif.
- a storage server can also be employed in a storage area network (SAN).
- SAN is a highly efficient network of interconnected, shared storage devices.
- the storage server (which may be an appliance) provides a remote host with block-level access to stored data, whereas in a NAS configuration, the storage server provides clients with file-level access to stored data.
- Some storage servers such as certain Filers from Network Appliance, Inc. are capable of operating in either a NAS mode or a SAN mode, or even both modes at the same time. Such dual-use devices are sometimes referred to as “unified storage” devices.
- a storage server such as this may use any of various protocols to store and provide data, such as Network File System (NFS), Common Internet File system (CIFS), Internet SCSI (ISCSI), and/or Fibre Channel Protocol (FCP).
- NFS Network File System
- CIFS Common Internet File system
- ISCSI Internet SCSI
- FCP Fibre Channel Protocol
- a storage server may use any of various protocols to communicate with its clients, such as Network File System (NFS) and/or Common Internet File system (CIFS).
- NFS Network File System
- CIFS Common Internet File system
- the use of CIFS “shares” allows an advertised resource (e.g., one or more files or a portion thereof) to be moved to a new location on a file server.
- the client does not have to be informed that the resource has moved, and no state has to change on the client.
- a virtual filer is moved from one location to a new one, it is not necessary to visit each and every client to make changes to the imported resources.
- NFS exports however, as used by the commonly deployed versions of the NFS protocol, NFS versions 2 and 3, do not allow for the moving of an advertised resource to a new location on a file server. Clients must be informed that the resource has been moved, and state must be changed on the client. Consequently, when a virtual filer is moved to a new location, it is necessary to visit each and every client to make changes to the imported resources.
- a request is received, from a client by a storage server, to access a resource stored in the storage server based on a filehandle for the resource.
- a determination is made of whether an entry of a plurality of entries in an exports table has a filehandle that matches the filehandle for the resource.
- the entry includes a physical path of the resource that is different than an advertised path of the resource, in response to the filehandle in the entry retrieved using the physical path.
- a determination is made of whether a pathname in the entry matches a pathname for the resource.
- a determination is made of whether the client has permission to access the resource.
- the request to access the resource is executed.
- a request is received from a client to access a resource based on a filehandle for the resource.
- a determination is made of whether an entry of a plurality of entries in an exports table has a filehandle that matches the filehandle for the resource.
- the entry includes a physical path of the resource that is different than an advertised path of the resource, in response to the filehandle in the entry retrieved using the physical path.
- a determination is made of whether the client has permission to access the resource.
- the request to access the resource is executed.
- FIG. 1 illustrates a network environment that includes storage systems
- FIG. 2 is a block diagram of a storage system
- FIG. 3 is a block diagram of the operating system kernel of a storage system
- FIG. 4 schematically illustrates a portion of a file system
- FIG. 5 illustrates a portion an exports table
- FIG. 6 shows a manner of using a pathname or filehandle to access entries in an exports table
- FIG. 7 is a flow diagram showing a process of building an exports table
- FIG. 8 is a flow diagram showing a process of processing a mount request.
- FIG. 9 is a flow diagram showing a process of processing an NFS request.
- a method and apparatus for aliasing exported paths in a storage system are described.
- the description that follows includes example systems, methods, techniques, instruction sequences and computer program products that embody techniques of the features described herein. However, it is understood that the described features may be practiced without these specific details. In other instances, well-known instruction instances, protocols, structures and techniques have not been shown in detail in order not to obfuscate the description.
- NFS NFS version 2 or 3
- a file server makes available (i.e., “exports”) certain stored resources (e.g., files) to certain clients.
- a particular client can request to “mount” an exported resource (i.e., request to be granted the ability to access an exported resource) in NFS by sending a “mount request” to file server. If the client has permission to access the resource, the file server allows the client to “mount” the resource by returning the filehandle of the resource to the client in response to mount request.
- a filehandle is a compact key, usually with a fixed length and representable as an integer, which a server returns to a client to describe a pathname.
- an NFS-compliant storage system such as a filer can export a stored resource to clients by advertising to the clients a different pathname than the actual pathname of the resource.
- advertising is that the pathname of a resource available for mounting is made known to clients. This enables the storage system to redirect resource locations. As a result, an administrator can make changes to the client over time and remove the indirection at a later date.
- this indirection is created by providing a new option that can be used in an export rule for purposes of exporting NFS resources to clients; the option is referred to herein as an “-actual” directive.
- the “-actual” directive enables an alias to be provided for an exported pathname.
- the “-actual” directive allows migration of storage both on a filer and a virtual filer without reconfiguring all clients which have pathnames coded into automounter and /etc/[v]fstab maps.
- An automounter is a client based scheme which automatically scans the list of advertised exports from a host and mounts them, without the user having to manually specify to the client which exports to load.
- the reference to /etc/[v]fstab is a Sun Microsystems reference to a location where all static mount points to be loaded at boot time are stored in recent versions of Sun's Solaris operating System.
- a virtual filer is migrated from one physical filer to another, the underlying backing storage may change, i.e., it might be stored in filerA:/vol/vol17/vfiler13 and moved to filerB:/vol/vol3/vfiler13a on another filer. It might be that there is no corresponding volume or the path is already in use. Once “-actual” path directives have been added, the advertised paths can stay the same even after the virtual filer has been moved.
- a filer differs from traditional server architectures, such as servers running the UNIX operating system, when they are used to perform file-serving.
- a traditional server associates file systems with regions of a local file system name hierarchy for the purpose of making files accessible by user programs running locally on the server
- a filer has no such user programs, and thus, has no need to maintain data structures to provide such local access.
- this redirection problem may be solved by the creation of a symbolic link from the physical storage path to the advertised path.
- the advertised path does not have to exist anywhere in the physical storage of the filer's file system. That is, with this approach the advertised path does not consume an Mode.
- FIG. 1 illustrates an example of a network environment in accordance with some features.
- the system of FIG. 1 includes a number of storage servers 2 , each coupled locally to a set of mass storage devices 4 , and through an interconnect 3 to a set of clients 1 .
- a path aliasing technique in accordance with some features can be implemented in each of the storage servers 2 .
- Each storage server 2 may be, for example, an NFS-enabled filer, as is henceforth assumed in this description.
- Each filer 2 receives various read and write requests from the clients 1 and accesses data stored in the mass storage devices 4 to service those requests.
- Each of the clients 1 may be, for example, a conventional personal computer (PC), workstation, or the like.
- the mass storage devices 4 may be, for example, conventional magnetic tapes or disks, optical disks such as CD-ROM or DVD based storage, magneto-optical (MO) storage, or any other type of non-volatile storage devices suitable for storing large quantities of data, or a combination thereof.
- the mass storage devices 4 may be organized into one or more volumes of Redundant Array of Independent Disks (RAID).
- the interconnect 3 may be essentially any type of computer network, such as a local area network (LAN), a wide area network (WAN), metropolitan area network (MAN) or the Internet, and may implement the Internet Protocol (IP).
- LAN local area network
- WAN wide area network
- MAN metropolitan area network
- IP Internet Protocol
- FIG. 2 is a block diagram showing the architecture of a filer 2 , according to some features. Certain standard and well-known components which are not germane to some features may not be shown.
- the filer 2 includes one or more processors 21 and memory 22 coupled to a bus system 23 .
- the bus system 23 is an abstraction that represents any one or more separate physical buses and/or point-to-point connections, connected by appropriate bridges, adapters and/or controllers.
- the bus system 23 may include, for example, a system bus, a Peripheral Component Interconnect (PCI) bus, a HyperTransport or industry standard architecture (ISA) bus, a small computer system interface (SCSI) bus, a universal serial bus (USB), or an Institute of Electrical and Electronics Engineers (IEEE) standard 1394 bus (sometimes referred to as “Firewire”).
- PCI Peripheral Component Interconnect
- ISA HyperTransport or industry standard architecture
- SCSI small computer system interface
- USB universal serial bus
- IEEE Institute of Electrical and Electronics Engineers
- the processors 21 are the central processing units (CPUs) of the filer 2 and, thus, control the overall operation of the filer 2 . According to some features, the processors 21 accomplish this by executing software stored in memory 22 .
- a processor 21 may be, or may include, one or more programmable general-purpose or special-purpose microprocessors, digital signal processors (DSPs), programmable controllers, application specific integrated circuits (ASICs), programmable logic devices (PLDs), or the like, or a combination of such devices.
- the memory 22 represents any form of random access memory (RAM), read-only memory (ROM), flash memory, or the like, or a combination of such devices.
- Memory 22 stores, among other things, the operating system 24 of the filer 2 , in which the techniques introduced herein can be implemented.
- Internal mass storage devices 25 may be or include any conventional medium for storing large volumes of data in a non-volatile manner, such as one or more disks.
- the storage adapter 26 allows the filer 2 to access the external mass storage devices 4 and may be, for example, a Fibre Channel adapter or a SCSI adapter.
- the network adapter 27 provides the filer 2 with the ability to communicate with remote devices such as the clients 1 over a network and may be, for example, an Ethernet adapter.
- Memory 22 and mass storage devices 25 store software instructions and/or data which may include instructions and/or data used to implement the techniques introduced herein. For example, these instructions and/or data may be implemented as part of the operating system 24 of the filer 2 .
- the operating system 24 of the filer 2 has a kernel 30 that includes several modules, or layers. These layers include a file system 31 , which executes read and write operations on the mass storage devices 4 in response to client requests, maintains directories of stored data, etc.
- the kernel 30 further includes a mount deamon (“mountd”) module 36 , which implements the mount deamon processes for NFS.
- the mountd module 36 may also implement the resource exportation algorithms and path aliasing algorithms described further below.
- the kernel 30 also includes a network layer 32 and an associated media access layer 33 , to allow the filer 2 to communicate over a network (e.g., with clients 1 ).
- the network access 32 layer may implement any of various protocols, such as NFS, CIFS and/or HTTP.
- the media access layer 33 includes one or more drivers which implement one or more protocols to communicate over the network, such as Ethernet.
- the kernel 30 includes a storage access layer 34 and an associated driver layer 35 , to allow the filer 2 to communicate with external mass storage devices 4 .
- the storage access layer 34 implements a disk storage protocol such as RAID, while the driver layer 35 implements a lower-level storage device access protocol, such as Fibre Channel Protocol (FCP) or SCSI.
- FCP Fibre Channel Protocol
- SCSI Serial Bus interface
- the list of exports (exported resources) advertised by a filer 2 are typically stored in an online exports table.
- An exports table includes permissions for the various clients, with respect to the export points (exported resources) provided by a filer 2 .
- an exports table includes a mapping of filehandle to the advertised pathname and the -actual pathname (if different from advertised pathname), for each export point.
- An exports table is used by the filer 2 to process mount requests from clients 1 , i.e., to retrieve the filehandle corresponding to the advertised pathname specified in each mount request. The filehandles are subsequently included in NFS (read/write) requests submitted by clients 1 to the filer 2 .
- the “-actual” directive is used when constructing an exports table, i.e., when an export rule is loaded into the exports table.
- the filehandle of the physical storage path is mapped to the filehandle that will be returned to the client in response to a mount request.
- the filehandle which will be returned to the client is stored in the exports table in association with the advertised pathname and the -actual (physical) pathname. If a virtual filer is then migrated or the underlying path to the physical storage is changed, the filehandle cannot change.
- the pathname is used to process mount requests
- the filehandle is used to process NFS (read/write) requests.
- the basic process is for a client 1 to supply a pathname in the mount request and for the filer 2 then to return the filehandle for use in NFS requests.
- the filehandle is unique over the lifetime of the export point, but the pathname can be changed. If the pathname is changed, then all clients which do not have the export mounted will have to their automounter maps and static /etc/[v]fstab maps updated to reflect the new value.
- pathname indirection is created in accordance with some features by providing a new option that can be used when exporting NFS resources to clients, referred to herein as the “-actual” directive.
- the “-actual” directive maps a virtual export point to a physical export point.
- the advertised storage path /vol/vol9/vf1 is bound to the physical storage path /vol/vol3/vf1. Note that if the path /vol/vol9/vf1 exists, it is not accessible from outside the filer 2 .
- a mount request is sent to the mountd module 36 on the filer 2 .
- the request provides a pathname that is desired to be shared by the client 1 .
- This pathname can be determined either by a previous request to enumerate the advertised exports (via a show mount command) or by running the export command on the filer 2 to manually determine the set of exports. If the export rule does not contain an “-actual” directive, then the advertised pathname is the physical storage path. For example, in the export rule
- /vol/vol8/vf2 is both the advertised path and the physical storage path.
- the pathname specified by the -actual directive is the physical storage path.
- the filehandle for the physical storage path determined by the pathname supplied to the “-actual” directive is returned to the client.
- the exports table is indexed by two keys: the filehandle associated with the advertised path and the advertised path.
- care should be taken to ensure that the filehandle corresponds to the physical storage path and not the advertised path.
- the filer 2 determines that the “-actual” directive is in use and retrieves the filehandle associated with that path.
- mapping is needed because NFS requests strictly utilize the filehandle and not the path.
- the operation must yield the filehandle associated with the physical storage.
- the mapping is done for NFS request as the export is loaded into memory, avoiding any translations when processing a request.
- the mapping of the second index occurs when mount requests are sent to the filer 2 .
- the requesting client 1 only knows the advertised path and probably has no knowledge that the underlying physical storage has changed.
- the filer 2 returns the filehandle associated with the “-actual” directive as the filehandle of the mount point.
- FIG. 4 shows a simple example of a portion of a file system in a filer 2 .
- FIG. 4 shows a simple example of a portion of a file system in a filer 2 .
- there are four export points in the file system having the following four advertised paths, respectively:
- the export rules for these export points may be initially obtained from an export file (e.g., /etc/exports), for example, which also specifies permissions of the various clients with respect to these export points.
- the export file may specify the following information (and other information not shown):
- the advertised pathname /foo in this example actually corresponds to the physical pathname /vol/vol1, as specified by the “-actual” option in the last export rule.
- FIG. 5 shows a simplified example of an exports table corresponding to the above-described export file (with non-germane information not shown).
- the exports table 50 includes an entry for each export point, wherein each entry includes (among other information): the advertised pathname of the export point, the -actual pathname of the export point (if any), the filehandle of the export point, and any client permissions applicable to the export point.
- An exports table is used to look up filehandles and to determine client permissions in response to both mount requests and NFS requests, as further illustrated in FIG. 6 according to some features.
- the pathname in the mount request is input to a pathname hash unit 61 , which applies a hashing function to the pathname to generate a short key.
- the short key is an index, in a corresponding hash table 62 , of a pointer that refers to one or more entries in an exports table 66 .
- the hashing function and short key are used to reduce the amount of storage needed in the filer 2 , since multiple pathnames can be associated with the same short key. Any ambiguity thereby introduced is easily removed by subsequently comparing the pathname in the request with the pathnames of any entries in the exports table 66 that correspond to the short key.
- the filehandle in the NFS request is input to a filehandle hash unit 63 , which applies a hashing function to the filehandle to generate a short key.
- the short key in this instance is an index, in a corresponding hash table 64 , of a pointer that refers to one or more entries in the exports table 66 .
- FIG. 7 shows the process of building an exports table in a filer 2 , according to some features. It is assumed, to facilitate description, that the export rules are initially obtained from an export file (e.g., /etc/exports). Initially, the process reads the first rule in the export file at 701 . Next, the process determines at 702 whether the rule includes an -actual directive. If the rule does not include an -actual directive, the process branches to 710 .
- an export file e.g., /etc/exports
- the process determines whether the pathname of an entry in the exports table matches an -actual pathname loaded into the exports table from a prior export rule. It is necessary to ensure that the advertised path and filehandles are unique. If they are not unique, access permissions cannot be deterministically checked on every request. Hence, if there is such a match at 710 , then the process generates an error message at 711 , and the process then ends. If there is no such match, then the process uses the pathname to make a call to the file system at 712 to look up the filehandle corresponding to the pathname. The process then proceeds to 707 , as described below.
- the process determines at 703 whether the pathname referenced by the -actual directive exists. As a byproduct, this check disallows nested loops of the form:
- the process determines at 704 whether the -actual pathname corresponds to the advertised pathname of any other resource.
- the advertised path and filehandle are unique in the exports tables, so that access permissions can be deterministically checked on every request. If the actual path corresponds to that of an export already loaded, the duplication rules in force by the operating system are used, which may mean overwriting the export already loaded. Referring back to FIG. 7 , therefore, if the -actual pathname is determined at 704 to correspond to the advertised pathname of another resource, then the process generates an error message at 711 , and the process then ends.
- the process determines at 705 whether any loops would be formed if the -actual directive is used.
- the first export rule should be loaded successfully, because there is no loop.
- the operation should fail because it sets up a loop.
- the process stores the filehandle in the entry in the exports table for the particular export point, in association with the advertised pathname and the -actual pathname (if any).
- the process accesses the next rule in the export file at 708 , and the entire process repeats, until all of the export rules have been processed.
- the second major process performed by a filer 2 is the process of responding to a mount request from a client.
- FIG. 8 shows an example of such process according to some features. Initially, a mount request is received from a client at 801 . The process then hashes the pathname in the mount request at 802 to produce a short key. The process then determines at 803 whether any entry in the exports table matches the short key. If there is no matching entry, then the process returns an error message to the client at 815 , and the process then ends.
- the process determines which of the export points that correspond to the generated short key (if any) has the longest pathname prefix matching the pathname in the mount request.
- a client requests to mount /vol/volY/dir1, which is not an export point.
- /vol/volY is the export point that has the longest matching pathname prefix.
- an exported pathname may exactly match the pathname in the mount request in its entirety; in that event, the entire pathname of the export is considered to be the matching “prefix” for purposes of 804 .
- the access permissions for that request will be determined from the permissions of the export point that has the longest matching pathname prefix, if any.
- the process looks up the permissions for the requesting client for the export point with the longest matching prefix. The process then determines at 807 whether the client has permissions to access the export point. If the client does not have permission to access the export point, then the process returns an error message to the client at 815 , and the process ends. If the client does have permission, than the process next determines at 808 whether the pathname in the request exactly matches the pathname of the corresponding export point in the export of the table. If there is an exact match, then at 809 the process returns the filehandle of the export point (as specified in the exports table) to the requesting client, and the process ends.
- this sub-process is carried out as follows. After determining that there is no exact match with the pathname in the exports table ( 808 ), the process determines at 810 whether the export point has an -actual path specified in the exports table. If the export point does not have an -actual path in the exports table, then the process next assigns a pathname variable, tpath, the pathname in the mount request at 814 . The process then requests the filehandle for tpath from the file system at 812 , and returns that filehandle to the requesting client at 813 , after which the process ends.
- the process then requests the filehandle for tpath from the file system at 812 , and returns that filehandle to the requesting client at 813 , after which the process ends.
- the third major process performed by a filer 2 is the process of responding to an NFS request (e.g., a read or write request) from a client.
- an NFS request e.g., a read or write request
- FIG. 9 shows an example of such process according to some features.
- the filer 2 receives an NFS request from a client 1 .
- the request includes a pathname and the filehandle of the resource which the client 1 is attempting to read or write.
- the process hashes the filehandle request to produce a short key. If there is at least one entry in the exports table which matches the filehandle short key ( 903 ), the process continues from 904 . Otherwise, the process generates returns an error message to the client at 908 , and the process then ends.
- the process next determines at 904 whether any of the matching entries in the exports table has a pathname that matches the pathname in the NFS request. If there is no matching entry, the process returns an error message to the client at 908 , and the process ends. If there is a matching entry, then the process looks up the permissions for the matching entry in the exports table at 905 . If the requesting client has permission to access the resource, then the process causes the filer to execute the requested operation (read or write) at 907 , and the process then ends. Otherwise, the process returns an error message to the client at 908 , and the process then ends.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- Databases & Information Systems (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Data Mining & Analysis (AREA)
- Health & Medical Sciences (AREA)
- Bioethics (AREA)
- General Health & Medical Sciences (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Software Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
A request is received, by a storage server, to access a resource based on a filehandle for the resource. A determination is made of whether an entry of a plurality of entries in an exports table has a filehandle that matches the filehandle for the resource. The entry includes a physical path of the resource that is different than an advertised path of the resource, in response to the filehandle in the entry retrieved using the physical path. In response to determining that the filehandle in the entry matches the filehandle for the resource, a determination is made of whether a pathname in the entry matches a pathname for the resource. In response to determining that the pathname in the entry matches the pathname for the resource, a determination is made of whether the client has permission to access the resource. The request to access the resource is executed.
Description
- This application is a continuation of and claims the priority benefit of U.S. application Ser. No. 12/901,276 filed Oct. 8, 2010, which is a continuation of and claims the priority benefit of U.S. application Ser. No. 10/837,120 filed Apr. 30, 2004 (U.S. Pat. No. 7,814,131), which claims the benefit of Provisional U.S. Patent Application No. 60/541,512 filed on Feb. 2, 2004.
- Features generally relate to the field of computers, and, more particularly, to aliasing of exported paths in a storage system.
- Modern computer networks can include various types of storage servers. Storage servers can be used for many different purposes, such as to provide multiple users with access to shared data or to back up mission-critical data. A file server is a type of storage server which operates on behalf of one or more clients to store and manage shared files in a set of mass storage devices, such as magnetic or optical storage based disks or tapes. The mass storage devices are typically organized into one or more volumes of Redundant Array of Independent (or Inexpensive) Disks (RAID). A single physical file server may implement multiple independent file systems, sometimes referred to as “virtual filers”.
- One configuration in which a file server can be used is a network attached storage (NAS) configuration. In a NAS configuration, a file server can be implemented in the form of an appliance, called a filer, that attaches to a network, such as a local area network (LAN) or a corporate intranet. An example of such an appliance is any of the Filer products made by Network Appliance, Inc. in Sunnyvale, Calif.
- A storage server can also be employed in a storage area network (SAN). A SAN is a highly efficient network of interconnected, shared storage devices. In a SAN, the storage server (which may be an appliance) provides a remote host with block-level access to stored data, whereas in a NAS configuration, the storage server provides clients with file-level access to stored data. Some storage servers, such as certain Filers from Network Appliance, Inc. are capable of operating in either a NAS mode or a SAN mode, or even both modes at the same time. Such dual-use devices are sometimes referred to as “unified storage” devices. A storage server such as this may use any of various protocols to store and provide data, such as Network File System (NFS), Common Internet File system (CIFS), Internet SCSI (ISCSI), and/or Fibre Channel Protocol (FCP).
- A storage server may use any of various protocols to communicate with its clients, such as Network File System (NFS) and/or Common Internet File system (CIFS). The use of CIFS “shares” allows an advertised resource (e.g., one or more files or a portion thereof) to be moved to a new location on a file server. The client does not have to be informed that the resource has moved, and no state has to change on the client. Hence, if a virtual filer is moved from one location to a new one, it is not necessary to visit each and every client to make changes to the imported resources.
- NFS exports, however, as used by the commonly deployed versions of the NFS protocol, NFS
versions 2 and 3, do not allow for the moving of an advertised resource to a new location on a file server. Clients must be informed that the resource has been moved, and state must be changed on the client. Consequently, when a virtual filer is moved to a new location, it is necessary to visit each and every client to make changes to the imported resources. - A request is received, from a client by a storage server, to access a resource stored in the storage server based on a filehandle for the resource. A determination is made of whether an entry of a plurality of entries in an exports table has a filehandle that matches the filehandle for the resource. The entry includes a physical path of the resource that is different than an advertised path of the resource, in response to the filehandle in the entry retrieved using the physical path. In response to determining that the filehandle in the entry matches the filehandle for the resource, a determination is made of whether a pathname in the entry matches a pathname for the resource. In response to determining that the pathname in the entry matches the pathname for the resource, a determination is made of whether the client has permission to access the resource. In response to determining that the client has permission to access the resource, the request to access the resource is executed.
- A request is received from a client to access a resource based on a filehandle for the resource. A determination is made of whether an entry of a plurality of entries in an exports table has a filehandle that matches the filehandle for the resource. The entry includes a physical path of the resource that is different than an advertised path of the resource, in response to the filehandle in the entry retrieved using the physical path. In response to a determination that the filehandle in the entry matches the filehandle for the resource, a determination is made of whether the client has permission to access the resource. In response to a determination that the client has permission to access the resource, the request to access the resource is executed.
- The present features may be better understood, and numerous objects, features, and advantages made apparent to those skilled in the art by referencing the accompanying drawings.
-
FIG. 1 illustrates a network environment that includes storage systems; -
FIG. 2 is a block diagram of a storage system; -
FIG. 3 is a block diagram of the operating system kernel of a storage system; -
FIG. 4 schematically illustrates a portion of a file system; -
FIG. 5 illustrates a portion an exports table; -
FIG. 6 shows a manner of using a pathname or filehandle to access entries in an exports table; -
FIG. 7 is a flow diagram showing a process of building an exports table; -
FIG. 8 is a flow diagram showing a process of processing a mount request; and -
FIG. 9 is a flow diagram showing a process of processing an NFS request. - A method and apparatus for aliasing exported paths in a storage system are described. The description that follows includes example systems, methods, techniques, instruction sequences and computer program products that embody techniques of the features described herein. However, it is understood that the described features may be practiced without these specific details. In other instances, well-known instruction instances, protocols, structures and techniques have not been shown in detail in order not to obfuscate the description.
- References to “NFS” in this description may be assumed to be referring to
NFS version 2 or 3, unless otherwise specified. With NFS, a file server makes available (i.e., “exports”) certain stored resources (e.g., files) to certain clients. A particular client can request to “mount” an exported resource (i.e., request to be granted the ability to access an exported resource) in NFS by sending a “mount request” to file server. If the client has permission to access the resource, the file server allows the client to “mount” the resource by returning the filehandle of the resource to the client in response to mount request. As used in this description, a filehandle is a compact key, usually with a fixed length and representable as an integer, which a server returns to a client to describe a pathname. - In accordance with some features, and as described in greater detail below, an NFS-compliant storage system such as a filer can export a stored resource to clients by advertising to the clients a different pathname than the actual pathname of the resource. What is meant by “advertising” is that the pathname of a resource available for mounting is made known to clients. This enables the storage system to redirect resource locations. As a result, an administrator can make changes to the client over time and remove the indirection at a later date.
- According to some features, this indirection is created by providing a new option that can be used in an export rule for purposes of exporting NFS resources to clients; the option is referred to herein as an “-actual” directive. The “-actual” directive enables an alias to be provided for an exported pathname. Hence, the basic format of an export rule is as follows:
- advertised_path -actual=physical_path, [attributes]
- For example, the export rule
- /engineering -actual=/vol/vol1/engineering, rw=.eng.netapp.com, anon=0
- states that the physical storage path of /engineering is /vol/vol1/engineering (the “rw” attribute indicates the host(s) (client(s)) with read/write privileges for the pathname). The clients would reference /engineering, but the file server would translate this to /vol/vol1/engineering.
- The “-actual” directive allows migration of storage both on a filer and a virtual filer without reconfiguring all clients which have pathnames coded into automounter and /etc/[v]fstab maps. (An automounter is a client based scheme which automatically scans the list of advertised exports from a host and mounts them, without the user having to manually specify to the client which exports to load. The reference to /etc/[v]fstab is a Sun Microsystems reference to a location where all static mount points to be loaded at boot time are stored in recent versions of Sun's Solaris operating System.) One benefit is that any potential downtime is reduced, because administrators do not have to coordinate changes on multiple clients.
- If a virtual filer is migrated from one physical filer to another, the underlying backing storage may change, i.e., it might be stored in filerA:/vol/vol17/vfiler13 and moved to filerB:/vol/vol3/vfiler13a on another filer. It might be that there is no corresponding volume or the path is already in use. Once “-actual” path directives have been added, the advertised paths can stay the same even after the virtual filer has been moved.
- Note that a filer, as described herein, differs from traditional server architectures, such as servers running the UNIX operating system, when they are used to perform file-serving. Whereas a traditional server associates file systems with regions of a local file system name hierarchy for the purpose of making files accessible by user programs running locally on the server, a filer has no such user programs, and thus, has no need to maintain data structures to provide such local access. Within such a traditional server architecture, this redirection problem may be solved by the creation of a symbolic link from the physical storage path to the advertised path.
- The use of the “-actual” directive has two main advantages over that approach:
- 1) The advertised path does not have to exist anywhere in the physical storage of the filer's file system. That is, with this approach the advertised path does not consume an Mode.
- 2) Each time a redirection is encountered via the “-actual” directive, it is not necessary to load an Mode file and perform the redirection. All processing can be handled in the mounted thread layer and bypass potential disk accessing.
-
FIG. 1 illustrates an example of a network environment in accordance with some features. The system ofFIG. 1 includes a number ofstorage servers 2, each coupled locally to a set of mass storage devices 4, and through an interconnect 3 to a set ofclients 1. A path aliasing technique in accordance with some features can be implemented in each of thestorage servers 2. Eachstorage server 2 may be, for example, an NFS-enabled filer, as is henceforth assumed in this description. Eachfiler 2 receives various read and write requests from theclients 1 and accesses data stored in the mass storage devices 4 to service those requests. - Each of the
clients 1 may be, for example, a conventional personal computer (PC), workstation, or the like. The mass storage devices 4 may be, for example, conventional magnetic tapes or disks, optical disks such as CD-ROM or DVD based storage, magneto-optical (MO) storage, or any other type of non-volatile storage devices suitable for storing large quantities of data, or a combination thereof. The mass storage devices 4 may be organized into one or more volumes of Redundant Array of Independent Disks (RAID). The interconnect 3 may be essentially any type of computer network, such as a local area network (LAN), a wide area network (WAN), metropolitan area network (MAN) or the Internet, and may implement the Internet Protocol (IP). -
FIG. 2 is a block diagram showing the architecture of afiler 2, according to some features. Certain standard and well-known components which are not germane to some features may not be shown. Thefiler 2 includes one ormore processors 21 andmemory 22 coupled to abus system 23. Thebus system 23 is an abstraction that represents any one or more separate physical buses and/or point-to-point connections, connected by appropriate bridges, adapters and/or controllers. Thebus system 23, therefore, may include, for example, a system bus, a Peripheral Component Interconnect (PCI) bus, a HyperTransport or industry standard architecture (ISA) bus, a small computer system interface (SCSI) bus, a universal serial bus (USB), or an Institute of Electrical and Electronics Engineers (IEEE) standard 1394 bus (sometimes referred to as “Firewire”). - The
processors 21 are the central processing units (CPUs) of thefiler 2 and, thus, control the overall operation of thefiler 2. According to some features, theprocessors 21 accomplish this by executing software stored inmemory 22. Aprocessor 21 may be, or may include, one or more programmable general-purpose or special-purpose microprocessors, digital signal processors (DSPs), programmable controllers, application specific integrated circuits (ASICs), programmable logic devices (PLDs), or the like, or a combination of such devices. - The
memory 22 represents any form of random access memory (RAM), read-only memory (ROM), flash memory, or the like, or a combination of such devices.Memory 22 stores, among other things, theoperating system 24 of thefiler 2, in which the techniques introduced herein can be implemented. - Also connected to the
processors 21 through thebus system 23 are one or more internal mass storage devices 25, astorage adapter 26 and anetwork adapter 27. Internal mass storage devices 25 may be or include any conventional medium for storing large volumes of data in a non-volatile manner, such as one or more disks. Thestorage adapter 26 allows thefiler 2 to access the external mass storage devices 4 and may be, for example, a Fibre Channel adapter or a SCSI adapter. Thenetwork adapter 27 provides thefiler 2 with the ability to communicate with remote devices such as theclients 1 over a network and may be, for example, an Ethernet adapter. -
Memory 22 and mass storage devices 25 store software instructions and/or data which may include instructions and/or data used to implement the techniques introduced herein. For example, these instructions and/or data may be implemented as part of theoperating system 24 of thefiler 2. - A shown in
FIG. 3 , theoperating system 24 of thefiler 2 has akernel 30 that includes several modules, or layers. These layers include afile system 31, which executes read and write operations on the mass storage devices 4 in response to client requests, maintains directories of stored data, etc. Thekernel 30 further includes a mount deamon (“mountd”)module 36, which implements the mount deamon processes for NFS. Themountd module 36 may also implement the resource exportation algorithms and path aliasing algorithms described further below. - “Under” the file system 31 (logically), the
kernel 30 also includes anetwork layer 32 and an associatedmedia access layer 33, to allow thefiler 2 to communicate over a network (e.g., with clients 1). Thenetwork access 32 layer may implement any of various protocols, such as NFS, CIFS and/or HTTP. Themedia access layer 33 includes one or more drivers which implement one or more protocols to communicate over the network, such as Ethernet. Also logically under thefile system 31, thekernel 30 includes astorage access layer 34 and an associateddriver layer 35, to allow thefiler 2 to communicate with external mass storage devices 4. Thestorage access layer 34 implements a disk storage protocol such as RAID, while thedriver layer 35 implements a lower-level storage device access protocol, such as Fibre Channel Protocol (FCP) or SCSI. The details of the above-mentioned layers of thekernel 30 are not necessary for an understanding of some features and, hence, need not be described herein. - There are three main processes of a
filer 2 which should now be considered with respect to some features: - 1) building an exports table
- 2) processing a mount request from a client
- 3) processing in NFS request from a client
- The list of exports (exported resources) advertised by a
filer 2 are typically stored in an online exports table. An exports table includes permissions for the various clients, with respect to the export points (exported resources) provided by afiler 2. In addition, as described further below, an exports table includes a mapping of filehandle to the advertised pathname and the -actual pathname (if different from advertised pathname), for each export point. An exports table is used by thefiler 2 to process mount requests fromclients 1, i.e., to retrieve the filehandle corresponding to the advertised pathname specified in each mount request. The filehandles are subsequently included in NFS (read/write) requests submitted byclients 1 to thefiler 2. - The “-actual” directive is used when constructing an exports table, i.e., when an export rule is loaded into the exports table. At that time, the filehandle of the physical storage path is mapped to the filehandle that will be returned to the client in response to a mount request. The filehandle which will be returned to the client is stored in the exports table in association with the advertised pathname and the -actual (physical) pathname. If a virtual filer is then migrated or the underlying path to the physical storage is changed, the filehandle cannot change.
- There are two keys to an export point when using NFS: the pathname and filehandle. The pathname is used to process mount requests, and the filehandle is used to process NFS (read/write) requests. The basic process is for a
client 1 to supply a pathname in the mount request and for thefiler 2 then to return the filehandle for use in NFS requests. The filehandle is unique over the lifetime of the export point, but the pathname can be changed. If the pathname is changed, then all clients which do not have the export mounted will have to their automounter maps and static /etc/[v]fstab maps updated to reflect the new value. - As noted above, pathname indirection is created in accordance with some features by providing a new option that can be used when exporting NFS resources to clients, referred to herein as the “-actual” directive. The “-actual” directive maps a virtual export point to a physical export point. Hence, in the export rule
- /vol/vol9/vf1 -actual=/vol/vol3/vf1, rw=host2, anon=0
- the advertised storage path /vol/vol9/vf1 is bound to the physical storage path /vol/vol3/vf1. Note that if the path /vol/vol9/vf1 exists, it is not accessible from outside the
filer 2. - When an
NFS client 1 mounts a resource from afiler 2, a mount request is sent to themountd module 36 on thefiler 2. The request provides a pathname that is desired to be shared by theclient 1. This pathname can be determined either by a previous request to enumerate the advertised exports (via a show mount command) or by running the export command on thefiler 2 to manually determine the set of exports. If the export rule does not contain an “-actual” directive, then the advertised pathname is the physical storage path. For example, in the export rule - /vol/vol8/vf2 -rw=host1, anon=0
- /vol/vol8/vf2 is both the advertised path and the physical storage path. However, if the “-actual” directive is used, then the pathname specified by the -actual directive is the physical storage path. Thus, in response to a mount request, if the pathname provided in the request corresponds to an export which has an “-actual” directive, then the filehandle for the physical storage path determined by the pathname supplied to the “-actual” directive is returned to the client.
- The exports table is indexed by two keys: the filehandle associated with the advertised path and the advertised path. When implementing the “-actual” directive, care should be taken to ensure that the filehandle corresponds to the physical storage path and not the advertised path. When filling the exports table (either from an exports file, typically /etc/exports, or via user-initiated non-persistent exports), the
filer 2 determines that the “-actual” directive is in use and retrieves the filehandle associated with that path. - This mapping is needed because NFS requests strictly utilize the filehandle and not the path. When the filehandle from an NFS request is used to index to the corresponding export entry, the operation must yield the filehandle associated with the physical storage. Thus, the mapping is done for NFS request as the export is loaded into memory, avoiding any translations when processing a request.
- The mapping of the second index occurs when mount requests are sent to the
filer 2. In that case, the requestingclient 1 only knows the advertised path and probably has no knowledge that the underlying physical storage has changed. Once the advertised path has been used to access the correct export entry, thefiler 2 returns the filehandle associated with the “-actual” directive as the filehandle of the mount point. - Refer now to
FIG. 4 which shows a simple example of a portion of a file system in afiler 2. Assume for this example that there are four export points in the file system, having the following four advertised paths, respectively: -
/vol/vol0 /vol/vol0/home /vol/vol1 /foo - The export rules for these export points may be initially obtained from an export file (e.g., /etc/exports), for example, which also specifies permissions of the various clients with respect to these export points. For example, the export file may specify the following information (and other information not shown):
-
/vol/vol0 -rw=host1 /vol/vol0/home -rw=host1 /vol/vol1 -rw=host2 /foo -actual=/vol/vol2, -rw=host1,host2 - Note that the advertised pathname /foo in this example actually corresponds to the physical pathname /vol/vol1, as specified by the “-actual” option in the last export rule.
-
FIG. 5 shows a simplified example of an exports table corresponding to the above-described export file (with non-germane information not shown). The exports table 50 includes an entry for each export point, wherein each entry includes (among other information): the advertised pathname of the export point, the -actual pathname of the export point (if any), the filehandle of the export point, and any client permissions applicable to the export point. - An exports table is used to look up filehandles and to determine client permissions in response to both mount requests and NFS requests, as further illustrated in
FIG. 6 according to some features. In response to a mount request from a client, the pathname in the mount request is input to a pathname hash unit 61, which applies a hashing function to the pathname to generate a short key. The short key is an index, in a corresponding hash table 62, of a pointer that refers to one or more entries in an exports table 66. The hashing function and short key are used to reduce the amount of storage needed in thefiler 2, since multiple pathnames can be associated with the same short key. Any ambiguity thereby introduced is easily removed by subsequently comparing the pathname in the request with the pathnames of any entries in the exports table 66 that correspond to the short key. - Similarly, in response to NFS (read/write) request from a
client 1, the filehandle in the NFS request is input to afilehandle hash unit 63, which applies a hashing function to the filehandle to generate a short key. The short key in this instance is an index, in a corresponding hash table 64, of a pointer that refers to one or more entries in the exports table 66. - Refer now to
FIG. 7 , which shows the process of building an exports table in afiler 2, according to some features. It is assumed, to facilitate description, that the export rules are initially obtained from an export file (e.g., /etc/exports). Initially, the process reads the first rule in the export file at 701. Next, the process determines at 702 whether the rule includes an -actual directive. If the rule does not include an -actual directive, the process branches to 710. - At 710, the process determines whether the pathname of an entry in the exports table matches an -actual pathname loaded into the exports table from a prior export rule. It is necessary to ensure that the advertised path and filehandles are unique. If they are not unique, access permissions cannot be deterministically checked on every request. Hence, if there is such a match at 710, then the process generates an error message at 711, and the process then ends. If there is no such match, then the process uses the pathname to make a call to the file system at 712 to look up the filehandle corresponding to the pathname. The process then proceeds to 707, as described below.
- Referring again to 702, if the rule includes an “-actual” directive, then the process determines at 703 whether the pathname referenced by the -actual directive exists. As a byproduct, this check disallows nested loops of the form:
-
/vol/volA -actual=/vol/volB /vol/volB -actual=/vol/volC /vol/volC -actual=/vol/volA - when /vol/volA is not a real storage path. If the pathname referenced by the actual directive does not exist, then the process generates an error message at 711, and the process then ends.
- If the pathname does exist, then the process determines at 704 whether the -actual pathname corresponds to the advertised pathname of any other resource. Consider the following:
-
/vol/volX -rw /mapped -actual=/vol/volX,ro - The advertised path and filehandle are unique in the exports tables, so that access permissions can be deterministically checked on every request. If the actual path corresponds to that of an export already loaded, the duplication rules in force by the operating system are used, which may mean overwriting the export already loaded. Referring back to
FIG. 7 , therefore, if the -actual pathname is determined at 704 to correspond to the advertised pathname of another resource, then the process generates an error message at 711, and the process then ends. - If the -actual pathname does not correspond to the advertised pathname of any other resource at 704, then the process determines at 705 whether any loops would be formed if the -actual directive is used. Consider the following example:
-
/vol/volY -actual=/vol/volZ,rw /vol/volZ -actual=/vol/volY,ro - The first export rule should be loaded successfully, because there is no loop. When the second export rule is loaded, the operation should fail because it sets up a loop.
- With just one layer of indirection and the rule that the “-actual” directive must point to real storage, a loop such as above is only confusing for administrators and users; it does not pose any problems in code. As shown earlier, the loop
-
/vol/volA -actual=/vol/volB /vol/volB -actual=/vol/volC /vol/volC -actual=/vol/volA - is also problematic only for human understanding, if the “-actual” directive is restricted to real storage and all exports are not considered when doing the determination of real storage for /vol/volC. In other words, if all export rules are first loaded and then an attempt is made to determine storage paths based on all available mappings, an infinite loop could result.
- To avoid this problem, only one level of indirection is evaluated, and all target paths of the “-actual” directive are forced to have corresponding physical storage.
- Referring again to
FIG. 7 , therefore, if any loops would be formed by using the -actual directive (705), then the process generates an error message at 711, and the process then ends. If no loops would be formed, then at 706 the process makes a call to thefile system 31 to look up the filehandle corresponding to the -actual pathname. - At 707, after the filehandle is received from the file system, the process stores the filehandle in the entry in the exports table for the particular export point, in association with the advertised pathname and the -actual pathname (if any). Following 707, if there are additional rules in the export file remaining to be processed (709), then the process accesses the next rule in the export file at 708, and the entire process repeats, until all of the export rules have been processed.
- The second major process performed by a
filer 2 is the process of responding to a mount request from a client. Refer now toFIG. 8 , which shows an example of such process according to some features. Initially, a mount request is received from a client at 801. The process then hashes the pathname in the mount request at 802 to produce a short key. The process then determines at 803 whether any entry in the exports table matches the short key. If there is no matching entry, then the process returns an error message to the client at 815, and the process then ends. - If there is a matching entry, then at 804 the process determines which of the export points that correspond to the generated short key (if any) has the longest pathname prefix matching the pathname in the mount request. Some additional explanation may be useful here. Assume the export points in a file system are:
-
/vol/volX /vol/volY /vol/volZ - Assume further that a client requests to mount /vol/volY/dir1, which is not an export point. In this example, /vol/volY is the export point that has the longest matching pathname prefix. (Of course, in some cases an exported pathname may exactly match the pathname in the mount request in its entirety; in that event, the entire pathname of the export is considered to be the matching “prefix” for purposes of 804.) Accordingly, in cases where the pathname in the mount request only partially matches the pathname of any export point (i.e., a matching prefix), the access permissions for that request will be determined from the permissions of the export point that has the longest matching pathname prefix, if any.
- Referring again to
FIG. 8 , therefore, if no pathname in the exports table has a pathname prefix that matches the pathname in the request (804), then the process returns an error message to the client at 815, and the process then ends. If there is a matching prefix in the exports table, then the process continues from 806. - At 806 the process looks up the permissions for the requesting client for the export point with the longest matching prefix. The process then determines at 807 whether the client has permissions to access the export point. If the client does not have permission to access the export point, then the process returns an error message to the client at 815, and the process ends. If the client does have permission, than the process next determines at 808 whether the pathname in the request exactly matches the pathname of the corresponding export point in the export of the table. If there is an exact match, then at 809 the process returns the filehandle of the export point (as specified in the exports table) to the requesting client, and the process ends.
- If, however, the pathname in the request does not exactly match that the pathname of the export point in the exports table, then the process continues with 810, as described below. First, though, some additional explanation may be useful. Assume, for example, the following set of exports and permissions:
-
/vol/volX -actual=/vol/volY/flow, rw=h1:h2 /vol/volX/dir1 -actual=/vol/volY/flow/dir1, rw=h3:h4 /vol/volY -rw - Assume further that a host, h1, requests to mount the following paths:
-
ID Path Filehandle 1 /vol/volX 67 2 /vol/volX/dir1 79 3 /vol/volX/dir2 73 4 /vol/volX/dir1/sub1 1033 - The first two cases above result in exact matches in 808, and the corresponding filehandles are returned to the client at 809. In case 3, however, there is a match on the prefix “/vol/volX”, but if the file system is asked to return a filehandle for the entire pathname, i.e. “/vol/volX/dir2”, the result would be either the wrong filehandle in the case of an existing /vol/volX or a “ENOENT” (“no entry”) error if the path does not exist. Therefore, the longest matching prefix is replaced with the -actual path, yielding “/vol/volY/flow/dir2”. The resulting filehandle that is returned is, therefore, 73. The same procedure is used in case 4 (after adding host h1 to the permissions list), yielding a path of “/vol/volY/flow/dir1/sub1” and a filehandle of 1033.
- Referring again to
FIG. 8 , therefore, this sub-process is carried out as follows. After determining that there is no exact match with the pathname in the exports table (808), the process determines at 810 whether the export point has an -actual path specified in the exports table. If the export point does not have an -actual path in the exports table, then the process next assigns a pathname variable, tpath, the pathname in the mount request at 814. The process then requests the filehandle for tpath from the file system at 812, and returns that filehandle to the requesting client at 813, after which the process ends. - If, however, the export point does have an -actual path (810) specified in the exports table, then at 811 the process assigns tpath a value as follows:
- tpath=actual path=(requested path−longest matching prefix)
- The process then requests the filehandle for tpath from the file system at 812, and returns that filehandle to the requesting client at 813, after which the process ends.
- The third major process performed by a
filer 2 is the process of responding to an NFS request (e.g., a read or write request) from a client. Refer now toFIG. 9 , which shows an example of such process according to some features. Initially, at 901 thefiler 2 receives an NFS request from aclient 1. The request includes a pathname and the filehandle of the resource which theclient 1 is attempting to read or write. At 902 the process hashes the filehandle request to produce a short key. If there is at least one entry in the exports table which matches the filehandle short key (903), the process continues from 904. Otherwise, the process generates returns an error message to the client at 908, and the process then ends. - If there is at least one matching entry, then the process next determines at 904 whether any of the matching entries in the exports table has a pathname that matches the pathname in the NFS request. If there is no matching entry, the process returns an error message to the client at 908, and the process ends. If there is a matching entry, then the process looks up the permissions for the matching entry in the exports table at 905. If the requesting client has permission to access the resource, then the process causes the filer to execute the requested operation (read or write) at 907, and the process then ends. Otherwise, the process returns an error message to the client at 908, and the process then ends.
- While the features are described with reference to various configurations and exploitations, it will be understood that these descriptions are illustrative and that the scope of the features is not limited to them. In general, techniques for atomic operations using write-back caching in a distributed storage system as described herein may be implemented with facilities consistent with any hardware system or hardware systems. Many variations, modifications, additions, and improvements are possible.
- Plural instances may be provided for components, operations or structures described herein as a single instance. Finally, boundaries between various components, operations and data stores are somewhat arbitrary, and particular operations are illustrated in the context of specific illustrative configurations. Other allocations of functionality are envisioned and may fall within the features described herein. In general, structures and functionality presented as separate components in the example configurations may be implemented as a combined structure or component. Similarly, structures and functionality presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements may fall within the features described herein.
Claims (20)
1. A method comprising:
receiving, from a client by a storage server, a request to access a resource stored in the storage server based on a filehandle for the resource;
determining whether an entry of a plurality of entries in an exports table has a filehandle that matches the filehandle for the resource, wherein the entry comprises,
a physical path of the resource that is different than an advertised path of the resource, in response to the filehandle in the entry retrieved using the physical path,
determining, in response to determining that the filehandle in the entry matches the filehandle for the resource, whether a pathname in the entry matches a pathname for the resource;
determining, in response to determining that the pathname in the entry matches the pathname for the resource, whether the client has permission to access the resource; and
executing, in response to determining that the client has permission to access the resource, the request to access the resource.
2. The method of claim 1 , further comprising:
hashing at least one of the filehandle or the pathname to produce a key; and
determining whether the entry of the plurality of entries in the exports table has the filehandle that matches the filehandle for the resource based on matching the key to the entry.
3. The method of claim 1 , wherein the entry of the exports table further includes access privileges for the resource.
4. The method of claim 3 , wherein determining whether the client has permission to access the resource is based on the access privileges for the resource in the entry.
5. The method of claim 1 , wherein the request to access the resource comprises a Network File System (NFS) request.
6. The method of claim 1 , further comprising:
outputting an error to deny access the resource, in response to determining that the filehandle in the entry does not match the filehandle for the resource.
7. A non-transitory machine readable medium having stored thereon instructions comprising machine executable code which when executed by at least one machine, causes the at least one machine to:
receive, from a client, a request to access a resource stored in a storage server based on a filehandle for the resource;
determine whether an entry of a plurality of entries in an exports table has a filehandle that matches the filehandle for the resource, wherein the entry comprises,
a physical path of the resource that is different than an advertised path of the resource, in response to the filehandle in the entry retrieved using the physical path,
determine, in response to a determination that the filehandle in the entry matches the filehandle for the resource, whether the client has permission to access the resource; and
execute, in response to a determination that the client has permission to access the resource, the request to access the resource.
8. The non-transitory machine readable medium of claim 7 , wherein the physical path of the resource is not different from the advertised path of the resource, in response to the filehandle in the entry retrieved based on the advertising path.
9. The non-transitory machine readable medium of claim 7 , wherein the instructions comprising machine executable code which when executed by the at least one machine, causes the at least one machine to:
hash the filehandle to produce a key; and
determine whether the entry of the plurality of entries in the exports table has the filehandle that matches the filehandle for the resource based on a match of the key to the entry.
10. The non-transitory machine readable medium of claim 7 , wherein the entry of the exports table further includes access privileges for the resource.
11. The non-transitory machine readable medium of claim 10 , wherein the machine executable code which when executed by the at least one machine causes the at least one machine to determine whether the client has permission to access the resource is based on the access privileges for the resource in the entry.
12. The non-transitory machine readable medium of claim 7 , wherein the request to access the resource comprises a Network File System (NFS) request.
13. The non-transitory machine readable medium of claim 7 , wherein the instructions comprising machine executable code which when executed by the at least one machine, causes the at least one machine to:
output an error to deny access the resource, in response to a determination that the filehandle in the entry does not match the filehandle for the resource.
14. An apparatus comprising:
a processor; and
a computer readable storage medium having program instructions embodied therewith, the program instructions executable by the processor to cause the apparatus to,
receive, from a client, a request to access a resource based on a filehandle for the resource;
determine whether an entry of a plurality of entries in an exports table has a filehandle that matches the filehandle for the resource, wherein the entry comprises,
a physical path of the resource that is different than an advertised path of the resource, in response to the filehandle in the entry retrieved using the physical path,
determine, in response to a determination that the filehandle in the entry matches the filehandle for the resource, whether the client has permission to access the resource; and
execute, in response to a determination that the client has permission to access the resource, the request to access the resource.
15. The apparatus of claim 14 , wherein the physical path of the resource is not different from the advertised path of the resource, in response to the filehandle in the entry retrieved based on the advertising path.
16. The apparatus of claim 14 , wherein the program instructions executable by the processor comprise program instructions executable by the processor to cause the apparatus to:
hash the filehandle to produce a key; and
determine whether the entry of the plurality of entries in the exports table has the filehandle that matches the filehandle for the resource based on a match of the key to the entry.
17. The apparatus of claim 14 , wherein the entry of the exports table further includes access privileges for the resource.
18. The apparatus of claim 17 , wherein the program instructions executable by the processor to cause the apparatus to determine whether the client has permission to access the resource is based on the access privileges for the resource in the entry.
19. The apparatus of claim 14 , wherein the request to access the resource comprises a Network File System (NFS) request.
20. The apparatus of claim 14 , wherein the program instructions executable by the processor comprise program instructions executable by the processor to cause the apparatus to:
output an error to deny access the resource, in response to a determination that the filehandle in the entry does not match the filehandle for the resource.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/286,645 US20140259123A1 (en) | 2004-02-02 | 2014-05-23 | Aliasing of exported paths in a storage system |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US54151204P | 2004-02-02 | 2004-02-02 | |
US10/837,120 US7814131B1 (en) | 2004-02-02 | 2004-04-30 | Aliasing of exported paths in a storage system |
US12/901,276 US8762434B1 (en) | 2004-02-02 | 2010-10-08 | Aliasing of exported paths in a storage system |
US14/286,645 US20140259123A1 (en) | 2004-02-02 | 2014-05-23 | Aliasing of exported paths in a storage system |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/901,276 Continuation US8762434B1 (en) | 2004-02-02 | 2010-10-08 | Aliasing of exported paths in a storage system |
Publications (1)
Publication Number | Publication Date |
---|---|
US20140259123A1 true US20140259123A1 (en) | 2014-09-11 |
Family
ID=42831011
Family Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/837,120 Active 2026-03-18 US7814131B1 (en) | 2004-02-02 | 2004-04-30 | Aliasing of exported paths in a storage system |
US12/901,276 Active 2025-04-24 US8762434B1 (en) | 2004-02-02 | 2010-10-08 | Aliasing of exported paths in a storage system |
US14/286,645 Abandoned US20140259123A1 (en) | 2004-02-02 | 2014-05-23 | Aliasing of exported paths in a storage system |
Family Applications Before (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/837,120 Active 2026-03-18 US7814131B1 (en) | 2004-02-02 | 2004-04-30 | Aliasing of exported paths in a storage system |
US12/901,276 Active 2025-04-24 US8762434B1 (en) | 2004-02-02 | 2010-10-08 | Aliasing of exported paths in a storage system |
Country Status (1)
Country | Link |
---|---|
US (3) | US7814131B1 (en) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130198262A1 (en) * | 2010-02-04 | 2013-08-01 | St-Ericsson Sa | Management of communications between a client equipment and a server equipment providing to the client equipment computer resources represented according to a file system |
US20170192979A1 (en) * | 2015-12-30 | 2017-07-06 | Alibaba Group Holding Limited | Methods and apparatuses for accessing cloud storage service by using traditional file system interface |
US20200174679A1 (en) * | 2018-11-29 | 2020-06-04 | Intuit Inc. | Systems and methods for storing object state on hash chains |
US11003653B2 (en) * | 2018-05-31 | 2021-05-11 | Intuit Inc. | Method and system for secure digital documentation of subjects using hash chains |
US11537555B2 (en) | 2020-12-15 | 2022-12-27 | EMC IP Holding Company LLC | Managing network shares utilizing filesystem snapshots comprising metadata characterizing network shares |
Families Citing this family (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20160041996A1 (en) | 2014-08-11 | 2016-02-11 | Netapp, Inc. | System and method for developing and implementing a migration plan for migrating a file system |
US10860529B2 (en) * | 2014-08-11 | 2020-12-08 | Netapp Inc. | System and method for planning and configuring a file system migration |
WO2015183301A1 (en) * | 2014-05-30 | 2015-12-03 | Hitachi Data Systems Corporation | Metadata favored replication in active topologies |
US9996541B2 (en) | 2016-02-10 | 2018-06-12 | Red Hat, Inc. | Hash-based mount point lookup in virtual file systems |
US11704300B2 (en) * | 2017-06-23 | 2023-07-18 | Charter Communications Operating, Llc | Apparatus and methods for packetized data management and delivery in a digital content distribution network |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5566328A (en) * | 1995-01-23 | 1996-10-15 | Tandem Computers Incorporated | Reconstructing directory pathnames from file handles in a computer system |
US20040117599A1 (en) * | 2002-12-12 | 2004-06-17 | Nexsil Communications, Inc. | Functional-Level Instruction-Set Computer Architecture for Processing Application-Layer Content-Service Requests Such as File-Access Requests |
US6760065B1 (en) * | 2000-03-24 | 2004-07-06 | Eastman Kodak Company | Imaging table of contents |
US20040243544A1 (en) * | 1999-10-05 | 2004-12-02 | Hipp Burton A. | Dynamic symbolic link resolution |
US7272654B1 (en) * | 2004-03-04 | 2007-09-18 | Sandbox Networks, Inc. | Virtualizing network-attached-storage (NAS) with a compact table that stores lossy hashes of file names and parent handles rather than full names |
US7428751B2 (en) * | 2002-12-05 | 2008-09-23 | Microsoft Corporation | Secure recovery in a serverless distributed file system |
Family Cites Families (31)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5001628A (en) * | 1987-02-13 | 1991-03-19 | International Business Machines Corporation | Single system image uniquely defining an environment for each user in a data processing system |
US5560008A (en) * | 1989-05-15 | 1996-09-24 | International Business Machines Corporation | Remote authentication and authorization in a distributed data processing system |
US5371885A (en) * | 1989-08-29 | 1994-12-06 | Microsoft Corporation | High performance file system |
JPH0778776B2 (en) * | 1991-09-24 | 1995-08-23 | インターナショナル・ビジネス・マシーンズ・コーポレイション | Access method and network for distributed resource part |
US5452447A (en) * | 1992-12-21 | 1995-09-19 | Sun Microsystems, Inc. | Method and apparatus for a caching file server |
WO1995029444A1 (en) * | 1994-04-25 | 1995-11-02 | Sony Corporation | Information memory processor |
US5742817A (en) * | 1995-12-08 | 1998-04-21 | Emc Corporation | Method and apparatus for file server addressing |
US5778384A (en) * | 1995-12-22 | 1998-07-07 | Sun Microsystems, Inc. | System and method for automounting and accessing remote file systems in Microsoft Windows in a networking environment |
US5737523A (en) * | 1996-03-04 | 1998-04-07 | Sun Microsystems, Inc. | Methods and apparatus for providing dynamic network file system client authentication |
US5819296A (en) * | 1996-10-31 | 1998-10-06 | Veritas Software Corporation | Method and apparatus for moving large numbers of data files between computer systems using import and export processes employing a directory of file handles |
US5946685A (en) * | 1997-06-27 | 1999-08-31 | Sun Microsystems, Inc. | Global mount mechanism used in maintaining a global name space utilizing a distributed locking mechanism |
US6163806A (en) * | 1997-06-30 | 2000-12-19 | Sun Microsystems, Inc. | System and method for transparent, global access to physical devices on a computer cluster |
US6901400B2 (en) * | 1998-07-28 | 2005-05-31 | Northrop Grumman Corporation | Method and apparatus for retrieving and converting remotely stored non-standard graphic images and storing the converted images in a database |
US6321219B1 (en) * | 1998-08-14 | 2001-11-20 | Microsoft Corporation | Dynamic symbolic links for computer file systems |
US7089281B1 (en) * | 2000-12-08 | 2006-08-08 | Sun Microsystems, Inc. | Load balancing in a dynamic session redirector |
US7383288B2 (en) * | 2001-01-11 | 2008-06-03 | Attune Systems, Inc. | Metadata based file switch and switched file system |
US8195760B2 (en) * | 2001-01-11 | 2012-06-05 | F5 Networks, Inc. | File aggregation in a switched file system |
US6687701B2 (en) * | 2001-09-25 | 2004-02-03 | Hewlett-Packard Development Company, L.P. | Namespace management in a distributed file system |
JP2003131924A (en) * | 2001-10-19 | 2003-05-09 | Fujitsu Ltd | Remote access program, program for processing of remote access request and client computer |
JP4087097B2 (en) * | 2001-11-12 | 2008-05-14 | 株式会社日立製作所 | Data relocation method and data relocation method considering database management system information |
US7024427B2 (en) * | 2001-12-19 | 2006-04-04 | Emc Corporation | Virtual file system |
US6968345B1 (en) * | 2002-02-27 | 2005-11-22 | Network Appliance, Inc. | Technique to enable support for symbolic link access by windows clients |
US6980994B2 (en) * | 2002-07-08 | 2005-12-27 | International Business Machines Corporation | Method, apparatus and computer program product for mapping file handles |
US6947940B2 (en) * | 2002-07-30 | 2005-09-20 | International Business Machines Corporation | Uniform name space referrals with location independence |
US7103638B1 (en) * | 2002-09-04 | 2006-09-05 | Veritas Operating Corporation | Mechanism to re-export NFS client mount points from nodes in a cluster |
JP4567293B2 (en) * | 2003-01-21 | 2010-10-20 | 株式会社日立製作所 | file server |
US7117303B1 (en) * | 2003-03-14 | 2006-10-03 | Network Appliance, Inc. | Efficient, robust file handle invalidation |
US7849112B2 (en) * | 2003-09-03 | 2010-12-07 | Emc Corporation | Using a file handle for associating the file with a tree quota in a file server |
US7739301B2 (en) * | 2004-03-17 | 2010-06-15 | Netapp, Inc. | Method and apparatus for improving file system proxy performance and security by distributing information to clients via file handles |
US7809675B2 (en) * | 2005-06-29 | 2010-10-05 | Oracle International Corporation | Sharing state information among a plurality of file operation servers |
US20070088702A1 (en) | 2005-10-03 | 2007-04-19 | Fridella Stephen A | Intelligent network client for multi-protocol namespace redirection |
-
2004
- 2004-04-30 US US10/837,120 patent/US7814131B1/en active Active
-
2010
- 2010-10-08 US US12/901,276 patent/US8762434B1/en active Active
-
2014
- 2014-05-23 US US14/286,645 patent/US20140259123A1/en not_active Abandoned
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5566328A (en) * | 1995-01-23 | 1996-10-15 | Tandem Computers Incorporated | Reconstructing directory pathnames from file handles in a computer system |
US20040243544A1 (en) * | 1999-10-05 | 2004-12-02 | Hipp Burton A. | Dynamic symbolic link resolution |
US6760065B1 (en) * | 2000-03-24 | 2004-07-06 | Eastman Kodak Company | Imaging table of contents |
US7428751B2 (en) * | 2002-12-05 | 2008-09-23 | Microsoft Corporation | Secure recovery in a serverless distributed file system |
US20040117599A1 (en) * | 2002-12-12 | 2004-06-17 | Nexsil Communications, Inc. | Functional-Level Instruction-Set Computer Architecture for Processing Application-Layer Content-Service Requests Such as File-Access Requests |
US7272654B1 (en) * | 2004-03-04 | 2007-09-18 | Sandbox Networks, Inc. | Virtualizing network-attached-storage (NAS) with a compact table that stores lossy hashes of file names and parent handles rather than full names |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130198262A1 (en) * | 2010-02-04 | 2013-08-01 | St-Ericsson Sa | Management of communications between a client equipment and a server equipment providing to the client equipment computer resources represented according to a file system |
US9215294B2 (en) * | 2010-02-04 | 2015-12-15 | St-Ericsson Sa | Management of communications between a client equipment and a server equipment providing to the client equipment computer resources represented according to a file system |
US20170192979A1 (en) * | 2015-12-30 | 2017-07-06 | Alibaba Group Holding Limited | Methods and apparatuses for accessing cloud storage service by using traditional file system interface |
WO2017117350A1 (en) * | 2015-12-30 | 2017-07-06 | Alibaba Group Holding Limited | Methods and apparatuses for accessing cloud storage service by using traditional file system interface |
CN106933872A (en) * | 2015-12-30 | 2017-07-07 | 阿里巴巴集团控股有限公司 | A kind of method and device that cloud storage service is accessed by traditional file systemses interface |
US11003653B2 (en) * | 2018-05-31 | 2021-05-11 | Intuit Inc. | Method and system for secure digital documentation of subjects using hash chains |
US20200174679A1 (en) * | 2018-11-29 | 2020-06-04 | Intuit Inc. | Systems and methods for storing object state on hash chains |
US10824345B2 (en) * | 2018-11-29 | 2020-11-03 | Intuit Inc. | Systems and methods for storing object state on hash chains |
US11537555B2 (en) | 2020-12-15 | 2022-12-27 | EMC IP Holding Company LLC | Managing network shares utilizing filesystem snapshots comprising metadata characterizing network shares |
Also Published As
Publication number | Publication date |
---|---|
US7814131B1 (en) | 2010-10-12 |
US8762434B1 (en) | 2014-06-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8762434B1 (en) | Aliasing of exported paths in a storage system | |
US7937453B1 (en) | Scalable global namespace through referral redirection at the mapping layer | |
JP4547264B2 (en) | Apparatus and method for proxy cache | |
JP4547263B2 (en) | Apparatus and method for processing data in a network | |
US7587426B2 (en) | System and method for virtualizing a distributed network storage as a single-view file system | |
US7007024B2 (en) | Hashing objects into multiple directories for better concurrency and manageability | |
EP1329812B1 (en) | Architecture for creating and maintaining virtual servers on a server | |
JP3968242B2 (en) | Method and apparatus for accessing shared data | |
US7107385B2 (en) | Storage virtualization by layering virtual disk objects on a file system | |
US7743038B1 (en) | Inode based policy identifiers in a filing system | |
RU2302034C2 (en) | Multi-protocol data storage device realizing integrated support of file access and block access protocols | |
US6530036B1 (en) | Self-healing computer system storage | |
US8601220B1 (en) | Transparent data migration in a storage system environment | |
US9152776B2 (en) | Secure access-based enumeration of a junction or mount point on a clustered server | |
US20070088702A1 (en) | Intelligent network client for multi-protocol namespace redirection | |
US8266136B1 (en) | Mechanism for performing fast directory lookup in a server system | |
US20070055703A1 (en) | Namespace server using referral protocols | |
US20070038697A1 (en) | Multi-protocol namespace server | |
US20050273451A1 (en) | Method, system, and program for maintaining a namespace of filesets accessible to clients over a network | |
US7877411B1 (en) | System and method for duplication of virtual private server files | |
US20060224843A1 (en) | Migrating a traditional volume to a virtual volume in a storage system | |
JPH1031612A (en) | Advanced file server | |
WO2008042283A2 (en) | Write-in-place within a write-anywhere filesystem | |
US8627446B1 (en) | Federating data between groups of servers | |
US8380806B2 (en) | System and method for absolute path discovery by a storage virtualization system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |