Patent Publication Number: US-8996490-B1

Title: Managing logical views of directories

Description:
BACKGROUND 
     1. Technical Field 
     This application relates to managing logical views of directories. 
     2. Description of Related Art 
     Computer systems may include different resources used by one or more host processors. Resources and host processors in a computer system may be interconnected by one or more communication connections. These resources may include, for example, data storage devices such as those included in the data storage systems manufactured by EMC Corporation. These data storage systems may be coupled to one or more servers or host processors and provide storage services to each host processor. Multiple data storage systems from one or more different vendors may be connected and may provide common data storage for one or more host processors in a computer system. 
     A host processor may perform a variety of data processing tasks and operations using the data storage system. For example, a host processor may perform basic system I/O operations in connection with data requests, such as data read and write operations. 
     Host processor systems may store and retrieve data using a storage device containing a plurality of host interface units, disk drives, and disk interface units. The host systems access the storage device through a plurality of channels provided therewith. Host systems provide data and access control information through the channels to the storage device and the storage device provides data to the host systems also through the channels. The host systems do not address the disk drives of the storage device directly, but rather, access what appears to the host systems as a plurality of logical disk units. The logical disk units may or may not correspond to the actual disk drives. Allowing multiple host systems to access the single storage device unit allows the host systems to share data in the device. In order to facilitate sharing of the data on the device, additional software on the data storage systems may also be used. 
     In data storage systems where high-availability is a necessity, system administrators are constantly faced with the challenges of preserving data integrity and ensuring availability of critical system components. One critical system component in any computer processing system is its file system. File systems include software programs and data structures that define the use of underlying data storage devices. File systems are responsible for organizing disk storage into files and directories and keeping track of which part of disk storage belong to which file and which are not being used. 
     Additionally, the need for high performance, high capacity information technology systems is driven by several factors. In many industries, critical information technology applications require outstanding levels of service. At the same time, the world is experiencing an information explosion as more and more users demand timely access to a huge and steadily growing mass of data including high quality multimedia content. The users also demand that information technology solutions protect data and perform under harsh conditions with minimal data loss and minimum data unavailability. Computing systems of all types are not only accommodating more data but are also becoming more and more interconnected, raising the amounts of data exchanged at a geometric rate. 
     To address this demand, modern data storage systems (“storage systems”) are put to a variety of commercial uses. For example, they are coupled with host systems to store data for purposes of product development, and large storage systems are used by financial institutions to store critical data in large databases. For many uses to which such storage systems are put, it is highly important that they be highly reliable and highly efficient so that critical data is not lost or unavailable. 
     File systems typically include metadata describing attributes of a file system and data from a user of the file system. A file system contains a range of file system blocks that store metadata and data. A user of a filesystem access the filesystem using a logical address (a relative offset in a file) and the file system converts the logical address to a physical address of a disk storage that stores the file system. Further, a user of a data storage system creates one or more files in a file system. Every file includes an index node (also referred to simply as “inode”) that contains the metadata (such as permissions, ownerships, timestamps) about that file. The contents of a file are stored in a collection of data blocks. An inode of a file defines an address map that converts a logical address of the file to a physical address of the file. Further, in order to create the address map, the inode includes direct data block pointers and indirect block pointers. A data block pointer points to a data block of a file system that contains user data. An indirect block pointer points to an indirect block that contains an array of block pointers (to either other indirect blocks or to data blocks). There may be many levels of indirect blocks arranged in an hierarchy depending upon the size of a file where each level of indirect blocks includes pointers to indirect blocks at the next lower level. An indirect block at the lowest level of the hierarchy is known as a leaf indirect block. 
     Generally, a file system includes a directory at the top level of a file system hierarchy which is known as the root directory for the file system. The root directory may optionally include one or more directories. A directory is a location on a storage device that is used for storing information about files included in the directory in an hierarchical manner. Thus, a directory enables a user to organize files into logical groups and place each related logical group into a separate directory. A directory may include another directory (also referred to as “lower-level directory”) which is known as a subdirectory. 
     A file may be replicated by using a snapshot copy facility that creates one or more replicas (also referred to as “snapshot copies”) of the file. A replica of a file is a point-in-time copy of the file. Further, each replica of a file is represented by a version file that includes an inheritance mechanism enabling metadata (e.g., indirect blocks) and data (e.g., direct data blocks) of the file to be shared across one or more versions of the file. Snapshot copies are in widespread use for on-line data backup. If a file becomes corrupted, the file is restored with its most recent snapshot copy that has not been corrupted. 
     A file system based snapshot copy facility is described in Bixby et al. U.S. Patent Application Publication 2005/0065986 published Mar. 24, 2005, incorporated herein by reference. When a snapshot copy of a file is initially created, it includes only a copy of the file. Therefore the snapshot copy initially shares all of the data blocks as well as any indirect blocks of the file. When the file is modified, new blocks are allocated and linked to the file to save the new data, and the original data blocks are retained and linked to the inode of the snapshot copy. The result is that disk space is saved by only saving the difference between two consecutive versions of the file. 
     The sharing of file system data blocks conserves data storage for storing files in a data storage system. The snapshot copy facility is a space saving technology that enables sharing of file system data blocks among versions of a file. 
     A file system namespace is a point-in-time collection of files. A file system namespace presents a collection of files as a single virtual file system to a user such that the user may access a file and/or directory from the collection of files irrespective of a physical location of the file or directory. Files in a file system namespace are arranged in a hierarchy that is similar to a file system hierarchy in such a way that a user can create and remove files, move a file from one directory to another, or rename a file within the file system namespace. A file system namespace separates the details of physical address of a file system stored on a disk device from the logical representation of the file system to clients of a data storage system. A file system namespace allows a storage administrator of a data storage system to manage a file system without affecting how users view or access files within the file system. 
     Thus, a file system namespace enables users (or clients) to access shared file systems without requiring the users to maintain knowledge of where a physical file system of the shared file systems is located or how to access files of the physical file system through alternate paths in case of a change or failure. A file system namespace enables storage administrators to add new capacity, bring new servers online, improve reliability of access, and manage load balancing and migration of files, backup files, migrate files from old technology to new technology without interrupting access of users or changing an addressing scheme used by the users. 
     While namespace have helped make data management much easier, they also come with a number of challenges, especially when creating a directory level namespace view and a snapshot copy of the directory level namespace view. It may be difficult or impossible for the conventional snapshot utility to create a version of a file system namespace view that is based on a file directory. 
     SUMMARY OF THE INVENTION 
     A method is used in managing logical views of directories. A directory logical view is created from a primary logical view. The primary logical view includes a set of storage objects. The directory logical view includes a subset of the set of storage objects. A root of the directory logical view indicates a file directory. The file directory includes the subset of the set of storage objects in a hierarchy. A mapping object is created for the directory logical view. The mapping object manages access to the subset of the set of storage objects. The mapping object for the directory logical view is a version of a mapping object for the primary logical view. Information is removed from the mapping object for the directory logical view. Information remained in the mapping object after removing the information is associated with the file directory. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Features and advantages of the present invention will become more apparent from the following detailed description of exemplary embodiments thereof taken in conjunction with the accompanying drawings in which: 
         FIG. 1  is an example of an embodiment of a computer system that may utilize the techniques described herein; 
         FIGS. 2-19  are diagrams illustrating in more detail components that may be used in connection with techniques herein; 
         FIG. 20-23  are flow diagrams illustrating processes that may be used in connection with techniques herein. 
     
    
    
     DETAILED DESCRIPTION OF EMBODIMENT(S) 
     Described below is a technique for use in managing logical views of directories, which technique may be used to provide, among other things, creating a directory logical view from a primary logical view, where the primary logical view includes a set of storage objects, where the directory logical view includes a subset of the set of storage objects, where a root of the directory logical view indicates a file directory, where the file directory includes the subset of the set of storage objects in a hierarchy, creating a mapping object for the directory logical view, where the mapping object manages access to the subset of the set of storage objects, where the mapping object for the directory logical view is a version of a mapping object for the primary logical view, and removing information from the mapping object for the directory logical view, where information remained in the mapping object after removing the information is associated with the file directory. 
     In at least one storage system implementation as described below, managing logical views of directories includes creating a directory namespace view by creating a snapshot copy of a logical namespace view such that the directory namespace view includes a subset of a set of files included in the logical namespace view in such a way that the subset of the set of files are arranged in a file directory hierarchy where the directory at the top of the file directory hierarchy is the root directory for the directory namespace view. 
     Generally, a namespace (also referred to herein as “namespace view”, “logical view” or simply as “view”) is a point-in-time logical collection of storage objects such as files, and directories. Thus, a namespace view may be a collection of files and/or directories selected from a file system at a point in time such that a user of the namespace view may access contents of files and/or directories included in the namespace instead of viewing or accessing the entire contents of the file system. Typically, each file of a file system is represented by an inode. Thus a namespace including a set of files may be organized as a collection of inodes in such a way that an actual location of a file of the set of files may change on a storage device. However, a hierarchical structure represented by the namespace remains intact and does not change. Further, a namespace may be a collection of storage objects such as logical volumes. 
     Typically, a logical view includes a metadata object such as a namespace inode that stores information regarding collection of inodes in an inode file. Thus, a logical view includes a namespace inode for storing an inode file. A namespace inode defines a logical view and virtualizes the real inode of each file included in the logical view. Further, an inode file created for a logical view includes a mapping for each file included in the logical view such that the mapping associates a real inode of a file to a virtual inode number of the file. A namespace inode for an inode file of a namespace view differs from a traditional inode of a file such that leaf-level indirect blocks of the namespace inode points to inodes of files included in the namespace view instead of file system data blocks. Further, a logical block offset (also referred to as “logical block number” or simply as “LBN”) within a leaf level indirect block of a namespace inode indicates a virtual inode number of a file associated with a real inode number stored at the logical block offset within the leaf level indirect block. 
     Further, inodes of files included in a primary namespace view (also referred to herein as “working file namespace view”) are shared between the primary namespace view and a snapshot copy (also referred to herein as “version”) of the primary namespace view by creating an inode file that virtualizes the inodes of the files included in the namespace. Typically, a snapshot copy facility creates a replica of a file by creating a version of the file using a delegated reference counting mechanism. The delegated reference counting mechanism is described in U.S. Pat. No. 8,032,498 for “Delegated reference count base file versioning” issued Oct. 4, 2011, which is incorporated herein by reference. Similarly, a snapshot copy facility creates versions of an inode file using the delegated reference counting mechanism. 
     Thus, a snapshot copy of a primary namespace view is created by creating a version of a namespace inode of the primary namespace view using the delegated reference counting mechanism. Thus, an inode of a file is shared among a primary namespace view and a snapshot copy of the primary namespace view such that the file is accessed by a virtual inode number instead of a real inode number (also referred to as “physical inode”) where the real inode number indicates a fixed location on a storage device. Further, a virtual inode number of a file remains the same when the file is shared among a primary namespace view and snapshot copies of the primary namespace view. Additionally, a file handle that is used to access a file of a namespace view includes a virtual inode number of the file, and a file system identifier of the namespace view such that the file may be shared among versions of the namespace view where a real inode number of a file or a version of the file on a storage device may change but the virtual inode number remains same. Thus, a virtual inode number of a file virtualizes the real inode of the file such that the file or a version of the file may be accessed from a namespace view or a snapshot copy of the namespace view by using the virtual inode number. Further, a storage object is accessed by a mapping (e.g. a double mapping) where a virtual inode of a file is mapped to a real inode of the file, and the real inode is used to access contents of the file. Further, upon modification of a file, the inode of the file is “split” among a namespace view and snapshot copies of the namespace views by using the delegated reference counting mechanism. 
     Conventionally, a version file supports sharing of indirect blocks and data blocks by maintaining reference counts for these blocks. Thus, in such a conventional system, the delegated reference counting mechanism is used to track block usage and sharing of indirect blocks and data blocks of a file when data blocks and indirect blocks of the file are shared across versions of the file. Further, in such a conventional system, an inode of a file is shared among a primary namespace view and a snapshot copy of the primary namespace view by using a namespace inode such that the file is accessed by a virtual inode number of the file instead of a real inode number of the file. However, in such a conventional system, creating a snapshot copy of a logical view includes creating a version of a namespace inode of the logical view such that each file of a set of files included in the logical view is shared between the logical view and the snapshot copy of the logical view by using the namespace inode. As a result, contents of a version of a namespace inode is same as contents of the namespace inode. Thus, in such a conventional system, it is difficult or impossible for a snapshot facility to create a version of the namespace inode such that only a subset of a set of files of a logical view can be shared with a snapshot copy of the logical view where the subset of the set of files are based on a file directory hierarchy. 
     By contrast, in at least some implementations in accordance with the current technique as described herein, a directory logical view is created by creating a version of a namespace inode of a logical view such that the version of the namespace inode includes a subset of a set of files included in the logical view where a snapshot copy facility removes information from the version of the namespace inode in such a way that the information remained in the version of the namespace inode is associated with the subset of the set of files that is based on a file directory hierarchy. Further, in at least one embodiment of the current technique, information that is not associated with a file directory hierarchy indicated by a directory namespace view is removed from a directory namespace inode by using metadata (e.g., a parent virtual inode number) associated with the directory namespace inode for the directory namespace view. 
     In at least some implementations in accordance with the technique as described herein, the use of the managing logical views of directories technique can provide one or more of the following advantages: enabling a user of a data storage system to create a directory namespace view from a logical view based on a file directory hierarchy, lowering storage cost by removing or reducing the need to maintain information in a namespace inode of a directory view for each file of a set of files of a logical view, reducing the amount of storage required for managing logical views of directories by maintaining information for a file in a namespace inode of a directory view only if the file belongs to a file directory hierarchy associated with the directory view, and improving memory and storage utilization by creating a directory view and snapshot copies of the directory view based on a file directory hierarchy. 
     Referring now to  FIG. 1 , shown is an example of an embodiment of a data storage system that may be used in connection with performing the technique or techniques described herein. The data storage system  10  includes a data network  20  interconnecting clients  21 ,  22  and servers such as a network file server  23  (also referred to simply as “file server”). The data network  20  may include any one or more of network connection technologies, such as Ethernet, and communication protocols, such as TCP/IP. The clients  21 ,  22 , for example, are workstations such as personal computers. The workstations are operated by users  24 ,  25 . The user  25  is a system administrator having sufficient privileges for configuring the network file server  23  and for receiving status and error messages from the network file server. Clients  21 ,  22  may access the network file server  23 , for example, in performing input/output (I/O) operations, data requests, and other operations. 
     Various aspects of the network file server  23  are further described in Vahalia et al., U.S. Pat. No. 5,893,140 issued Apr. 6, 1999, incorporated herein by reference, Xu et al., U.S. Pat. No. 6,324,581, issued Nov. 27, 2002, incorporated herein by reference, Vahalia et al., U.S. Pat. No. 6,389,420, incorporated herein by reference, Jiang et al., U.S. Patent Application Publication 2005/0240628, published Oct. 27, 2005, incorporated herein by reference, and Jiang et al., U.S. Patent Application Publication 2004/0059822-A1 published Mar. 25, 2004, incorporated herein by reference. 
     The network file server  23  includes at least one data processor  26  and a cached disk array  19 . The data processor  26 , for example, is a commodity computer. The cached disk array  19  includes multiple disk drives, a high-speed random-access cache memory, and a logical-to-physical mapping between the cache memory and the disk drives. 
     The data processor  26  has a network interface  30  for communication of data packets over the data network  20  via a data transmission protocol such as TCP/IP. The data processor  26  is programmed with a Network File System (NFS) module  41  for supporting communication with network clients over the data network  20  using the NFS file access protocol, and a Common Internet File System (CIFS) module  42  for supporting communication with network clients over the data network using the CIFS file access protocol. The NFS module  41 , and the CIFS module  42  are layered over a Common File System (CFS) module  44 , and the CFS module is layered over a Virtual File System (VFS) module  45 . The VFS module  45  is layered over a Universal File System (UxFS) module. The UxFS module is a file system manager  46  for managing a file system such as a UNIX-based file system. The CFS module  44  provides higher-level functions common to NFS  41  and CIFS  42 . 
     The file system manager  46  accesses data organized into logical volumes defined by a logical volume layer module  47 . Each logical volume maps to contiguous logical storage addresses in the cached disk array  19 . The logical volume layer module  47  is layered over a storage driver  48  such as a Fibre-Channel (FC), a Small Computer System Interface (SCSI), and an Internet SCSI (iSCSI) driver. The data processor  26  sends storage access requests through a host bus adapter  49  using a storage protocol such as the FC, SCSI, or iSCSI used by the storage driver  48 , depending on the physical data link  50  between the data processor  26  and the cached disk array  19 . 
     Referring again to  FIG. 1 , the CFS module  44 , the VFS module  45 , the file system manager  46 , the logical volume layer  47 , and the storage driver  48  are modules of an operating system program executing on file server  23 . The NFS module  41 , and CIFS module  42  are internal application programs supported by the operating system. The data processor  26  is programmed with additional internal application programs including a snapshot copy facility  52 . 
     The snapshot copy facility  52  performs a copy-on-first-write to each block in a production volume, in order to save an old version (“before image”) of the changed block in a snapshot volume. Details regarding such a snapshot copy facility  52  are found in the following patent publications: Armangau et al., “Instantaneous restoration of a production copy from a snapshot copy in a data storage system,” U.S. Pat. No. 6,957,362 issued Oct. 18, 2005; Raman et al., “Replication of Remote Copy Data for Internet Protocol (IP) Transmission,” U.S. Patent Application Publication No. US 2003/0217119 A1, published Nov. 20, 2003; Armangau et al., Replication of a Snapshot Using a File System Copy Differential,” U.S. Patent Application Publication No. US 2004/0267836 published Dec. 30, 2004; Armangau et al., Data Recovery with Internet Protocol Replication With or Without Full Resync,” U.S. Patent Application Publication No. US 2005/0015663 A1, published Jan. 20, 2005; and John Hayden et al., “Internet Protocol Based Disaster Recovery of a Server,” U.S. Published Patent Application No. 2005-0193245 published Sep. 1, 2005; all of which are incorporated herein by reference. 
     The data network  20  may be any one or more of a variety of networks or other type of communication connections as known to those skilled in the art. For example, the data network  20  may be the Internet, an intranet, network or other wireless or other hardwired connection(s) by which the clients  21 ,  22  may access and communicate with the network file server  23 , and may also communicate with other components (not shown) that may be included in the network file server  23 . Each of clients  21 ,  22  and the network file server  23  may be connected to the data network  20  by any one of a variety of connections as may be provided and supported in accordance with the type of data network  20 . 
     The processors included in the clients  21 ,  22  and data processor  26  may be any one of a variety of proprietary or commercially available single or multiprocessor system, such as an Intel-based processor, or other type of commercially available processor able to support traffic in accordance with each particular embodiment and application. 
     It should be noted that the particular examples of the hardware and software that may be included in the network file server  23  are described herein in more detail, and may vary with each particular embodiment. Each of the clients  21 ,  22  and the network file server  23  may all be located at the same physical site, or, alternatively, may also be located in different physical locations. Some or all of the connections by which the clients  21 - 22  and the network file server  23  may be connected may pass through other communication devices, such as a Connectrix or other switching equipment that may exist such as a phone line, a repeater, a multiplexer or even a satellite. 
     Each of the clients  21 ,  22  may perform different types of data operations in accordance with different types of tasks. In the embodiment of  FIG. 1 , any one of the clients  21 ,  22  may issue a data request to the network file server  23  to perform a data operation. For example, an application executing on one of the clients  21 ,  22  may perform a read or write operation resulting in one or more data requests to the network file server  23 . 
     An embodiment of the data storage system  10  may include one or more network file servers. Each of the network file server may include one or more data storage devices, such as disks. Each of the network file server included in data storage system  10  may be inter-connected (not shown). Additionally, the network file servers may also be connected to the clients through any one or more communication connections that may vary with each particular embodiment and device in accordance with the different protocols used in a particular embodiment. The type of communication connection used may vary with certain system parameters and requirements, such as those related to bandwidth and throughput required in accordance with a rate of I/O requests as may be issued by the clients, for example, to the network file server  23 . 
     It should be noted that each of the network file server may operate stand-alone, or may also included as part of a storage area network (SAN) that includes, for example, other components such as other network file servers. 
     Each of the network file servers of element  10  may include a plurality of disk devices or volumes. The particular network file server and examples as described herein for purposes of illustration should not be construed as a limitation. Other types of commercially available data storage systems, as well as processors and hardware controlling access to these particular devices, may also be included in an embodiment. 
     Clients, such as 21, 22, provide data and access control information through channels to the storage systems, and the storage systems may also provide data to the clients also through the channels. The clients do not address the disk drives of the storage systems directly, but rather access to data may be provided to one or more clients from what the clients view as a plurality of file systems. A file system is created from a logical device or logical volume. The logical volume may or may not correspond to an actual disk drive. For example, one or more logical volumes may reside on a single physical disk drive. Data in a single storage system may be accessed by multiple clients allowing the clients to share the data residing therein. A LUN (logical unit number) may be used to refer to one of the foregoing logically defined devices or volumes. 
     In such an embodiment in which element  10  of  FIG. 1  is implemented using one or more data storage systems, each of the data storage systems may include code thereon for performing the techniques as described herein. In following paragraphs, reference may be made to a particular embodiment such as, for example, an embodiment in which element  10  of  FIG. 1  includes a single data storage system, multiple data storage systems, a data storage system having multiple data processors, and the like. However, it will be appreciated by those skilled in the art that this is for purposes of illustration and should not be construed as a limitation of the techniques herein. As will be appreciated by those skilled in the art, the network file server  23  may also include other components than as described for purposes of illustrating the techniques herein. 
     As shown in the data storage system  10  in  FIG. 1 , a file system stored on a storage device is organized as a hierarchy. At the top of the hierarchy is a hierarchy of the directories  65  in the file system. Inodes of data files  66  depend from the file system directory hierarchy  65 . Indirect blocks of data files  67  depend from the inodes of the data files  66 . Data block metadata  68  and data blocks of data files  69  depend from the inodes of data files  66  and from the indirect blocks of data files  67 . Specific examples of this hierarchy are further described below with reference to  FIG. 5 . File systems typically include metadata describing attributes of a file system and data from a user of the file system. A file system contains a range of file system blocks that store metadata and data. In at least some embodiments of the current technique, the file system block may be 8 kilobytes (KB) in size. Further, a user of data storage system  10  creates files in a file system. In at least one embodiment of the current technique, snapshot copy facility  52  interacts with logical view management logic  63  for managing logical views of directories, and creating versions of a namespace view based on a file directory hierarchy. 
     Referring to  FIG. 2 , shown is an illustration of an example representing a hierarchy of storage objects that may be included in an embodiment using the techniques described herein. In at least one embodiment of the current technique, a set of storage objects (e.g. files, logical volumes) may be organized as a hierarchy with a root object  70  at the top of the hierarchy. Root object  70  may include object-2  71  and object-1  72 . Object-2  71  may further include object-5  73  and object-6  74 . Similarly, object-1  72  may include object-3  75  and object-4  76 . Additionally, object-5  73  may include object-7  77 . For example, in  FIG. 2 , object-2  71  indicates a file directory hierarchy such that object-2  71  indicates a root directory for the file directory hierarchy which includes onject-5  73 , object-6  74 , and object-7  77 . Further, in such a case, another file directory may include object-5  73  as a root directory for the other file system directory hierarchy that also includes file object-7  77 . 
     Referring to  FIG. 3 , shown is an illustration of an example representing a first logical view of the hierarchy of storage objects of  FIG. 2  that may be included in an embodiment using the techniques described herein. For example, in at least one embodiment of the current technique, a logical view named “A” may include a subset of storage objects from the set of storage objects shown in  FIG. 2 . Thus, in at least one embodiment of the current technique, for example, the logical view “A” may be a point-in-time collection of storage objects such as root object  70 , object-2  71 , object-1  72 , and object-3  73  such that a user of the logical view “A” may access contents of storage objects included in the logical view “A” as shown in  FIG. 3  instead of viewing or accessing the entire storage hierarchy shown in  FIG. 2 . 
     Referring to  FIG. 4 , shown is an illustration of an example representing a second logical view of the hierarchy of storage objects of  FIG. 2  that may be included in an embodiment using the techniques described herein. For example, in at least one embodiment of the current technique, a logical view named “B” may include a subset of storage objects from the set of storage objects shown in  FIG. 2 . Thus, in at least one embodiment of the current technique, for example, the logical view “B” may be a point-in-time collection of storage objects such as root object  70 , object-2  71 , object-1  72 , object-5  75 , and object-6  76  such that a user of the logical view “B” may access contents of storage objects included in the logical view “B” instead of viewing or accessing the entire storage hierarchy shown in  FIG. 2 . Conventionally, for example, it is difficult or impossible for a conventional snapshot copy facility to create a directory namespace view from a logical view B such that a snapshot copy of the logical view B includes a file directory hierarchy which includes object-2  71 , object-5  73 , and object-6  74 . 
     A file system includes one or more file system blocks. Some of the file system blocks are data blocks, some file system blocks may be indirect block, as described above, or some file system blocks are free blocks that have not yet been allocated to any file in the file system. In an indirect mapping protocol, such as the conventional indirect mapping protocol of a UNIX-based file system, the indirect mapping protocol permits any free block of the file system to be allocated to a file of the file system and mapped to any logical block of a logical extent of the file. This unrestricted mapping ability of the conventional indirect mapping protocol of a UNIX-based file system is a result of the fact that metadata for each file includes a respective pointer to each data block of the file of the file system, as described below. Each file of the file system includes an inode containing attributes of the file and a block pointer array containing pointers to data blocks of the file. There is one inode for each file in the file system. Each inode can be identified by an inode number. Several inodes may fit into one of the file system blocks. The inode number can be easily translated into a block number and an offset of the inode from the start of the block. Each inode of a file contains metadata of the file. Some block pointers of a file point directly at data blocks, other block pointers of the file points at blocks of more pointers, known as an indirect block. There are at least fifteen block pointer entries in a block pointer array contained in an inode of a file. The first of up to twelve entries of block pointers in the inode directly point to the first of up to twelve data blocks of the file. If the file contains more than twelve data blocks, then the thirteenth entry of the block pointer array contains an indirect block pointer pointing to an indirect block containing pointers to one or more additional data blocks. If the file contains so many data blocks that the indirect block becomes full of block pointers, then the fourteenth entry of the block pointer array contains a double indirect block pointer to an indirect block that itself points to an indirect block that points to one or more additional data blocks. If the file is so large that the indirect block becomes full of block pointers and its descendant indirect blocks are also full of block pointers, then the fifteenth entry of the block pointer array includes another level of indirection where the block pointer entry contains a triple indirect block pointer to an indirect block that points to an indirect block that points to an indirect block that points to one or more additional data blocks. Similarly there exists fourth and fifth level of indirections. Once the indirect blocks at last level of indirection and its descendant indirect blocks become full of pointers, the file contains a maximum permitted number of data blocks. Further, an indirect block at the last level of indirection is also referred to as a leaf indirect block. However, it should be noted that there may either be less than fifteen block pointer entries or more than fifteen block pointer entries. 
     Further, it should be noted that a file system may be organized based on any one of the known mapping techniques such as an extent based binary tree mapping mechanism, and a mapping technique that does not include data block pointers. 
     Referring to  FIG. 5 , shown is a representation of an inode of a file that may be included in an embodiment using the techniques described herein. A file includes an inode  81  containing attributes  82  of the file, and a block pointer array  83 . The block pointer array  83  has seventeen block pointer array entries BPA(0) to BPA(14). The first of up to twelve entries BPA(0) to BPA(11) directly point to the first of up to twelve data blocks (e.g.,  84 ,  85 ,  86 ). of the file. If the file contains more than twelve data blocks, then the thirteenth entry of the block pointer array  83  contains an indirect block pointer BPA(12) pointing to an indirect block  87  containing pointers to one or more additional data blocks (e.g.,  91 ,  92 ). If the file contains so many data blocks that the indirect block  87  becomes full of block pointers, then the fourteenth entry of the block pointer array  83  contains a double indirect block pointer BPA(13) to an indirect block  88  that itself points to an indirect block  93  that points to one or more additional data blocks (e.g.,  94 ,  95 ). If the file is so large that the indirect block  88  becomes full of block pointers and its descendant indirect blocks are also full of block pointers, then the fifteenth entry of the block pointer array  83  contains a triple indirect block pointer BPA(14) to an indirect block  89  that points to an indirect block  96  that points to an indirect block  97  that points to one or more additional data blocks (e.g.,  98 ,  99 ). Similarly the file may include fourth (BPA(15)) and fifth (BPA(16)) level of indirections indicated by indirect blocks  100 - 103  and data blocks  104 - 105 . 
     In at least one embodiment of the current technique, the inode  81  of a file includes a distributed weight  106  that indicates a sum of delegated reference counts (also referred to as “weight”) of the real inode associated with each version of the file shared among a namespace view and snapshot copies of the namespace view. Further, in at least one embodiment of the current technique, inode  81  of a file includes a virtual parent inode number  107  indicating an inode number of a storage object (e.g. file, directory) under which the file is organized in a hierarchy structure. 
     Generally, each file system data block of a file is associated with a respective mapping pointer. A mapping pointer of a file system block points to the file system block and includes metadata information for the file system block. A file system block associated with a mapping pointer may be a data block or an indirect data block which in turn points to other data blocks or indirect blocks. A mapping pointer includes information that help map a logical offset of a file system block to a corresponding physical block address of the file system block. Further, a mapping pointer of a file system block includes metadata information for the file system block such as a weight that indicates a delegated reference count for the mapping pointer. The delegated reference count is used by the snapshot copy facility  52  when a replica of a file is created. Mapping pointers of the inode of the file are copied and included in the inode of the replica of the file. Mapping pointers of the inode may include mapping pointers pointing to direct data blocks and mapping pointers pointing to indirect data blocks. The delegated reference count values stored in the mapping pointers of the file and the replica of the file are updated to indicate that the file and the replica of the file share data blocks of the file. 
     With reference also to  FIG. 1 , as introduced above herein, the file-system based snapshot copy facility  52  needs a way of maintaining block ownership information for indicating whether or not each indirect block or data block of a file or a snapshot copy (“replica” or “version”) of the file is shared with another version of the file. This block ownership information is accessed each time that the snapshot copy facility  52  writes new data to a file, and each time that the snapshot copy facility  52  deletes a snapshot copy. Further, as introduced above, files in the data storage system  10  are organized as a hierarchy of file system blocks including inodes, indirect blocks, and data blocks. The hierarchy of file system blocks includes a parent-child block relationship between a parent object that points to a child object. For example, if the mapping pointer of the inode of a file points to a data block, the association between the mapping pointer of the inode and the data block may be viewed as a parent-child block relationship. Similarly, for example, if the mapping pointer of an indirect block of a file points to a data block, the association between the mapping pointer of the indirect block and the data block may be viewed as a parent-child block relationship. Block ownership information for a snapshot copy facility  52  is maintained by storing respective reference counts for the file system indirect blocks and file system data blocks in the file system block hierarchy, and by storing respective delegated reference counts for the parent-child block relationships in the file system block hierarchy. For each parent-child block relationship, a comparison of the respective delegated reference count for the parent-child relationship to the reference count for the child block indicates whether or not the child block is either shared among parent blocks or has a single, exclusive parent block. For example, if the respective delegated reference count is equal to the respective reference count, then the child block is not shared, and the parent block is the exclusive parent of the child block. Otherwise, if the respective delegated reference count is not equal to the respective reference count, then the child block is shared among parent blocks. 
     As shown in  FIG. 6 , for example, a production file inode  110  (also referred to as “working file”) includes a mapping pointer field  111  containing a delegated reference count  112  and a block pointer  113  pointing to a first file system data block  114 . The block pointer  114  is a file system block number of the first data block  114 . The first data block  114  has associated per-block metadata  115  including a reference count  116 . The per-block metadata  115  of the first data block  114 , for example, is organized as table separate from the first data block  114  and indexed by the block number of the first data block  114 . 
     In the example of  FIG. 6 , the delegated reference count  112  is associated with the parent-child block relationship indicated by the block pointer  113  by storing the delegated reference count in one or more bytes of the mapping block pointer field  111 . The delegated reference count  112 , however, could be associated with the parent-child block relationship in other ways. For example, the delegated reference count could be stored in a metadata table of the production file inode  110 . 
     In the example of  FIG. 6 , the delegated reference count  112  has an initial full-weight value of 1,000, and the reference count  116  in the per-block metadata  115  of the first data block  114  also has an initial full-weight value of 1,000. In other words, the initial full-weight value of 1,000 should be understood as representing a full ownership interest (i.e., a 100% ownership interest) of the file system data block. The snapshot copy facility  52  delegates a partial ownership interest to a snapshot copy when sharing occurs between a snapshot copy and a production file. 
     As shown in  FIG. 7 , when the snapshot copy facility  52  creates a first snapshot copy of the production file, the snapshot copy facility allocates an inode  117  for the snapshot copy, and copies the content of the production file inode  110  into the snapshot copy inode  117 . Then the snapshot copy facility  52  decrements the delegated reference count  112  in the mapping block pointer field  111  of the production file inode  110  by a partial-weight value of 10, and sets the delegated reference count  119  in the mapping block pointer field  118  of the snapshot inode  117  to the same partial-weight value of 10. Block pointer  120  of the mapping pointer  118  in snapshot inode  117  of the snapshot copy of production file now points to the same file system data block  114  and thus indicates that file system data block  114  is shared by the production file and the snapshot copy of the production file. 
     Although in general a partial-weight value is simply smaller than a full-weight value, in most cases the ratio of the full-weight value to the partial-weight value may be greater than the maximum number of snapshot copies of a production file. For some applications, a relatively small partial weight in relationship to a limited number of snapshot copies would also permit identification of child blocks exclusively owned or shared only among snapshot files, permitting a rapid delete of all snapshot copies simply by scanning for file system blocks having a reference count value below a certain threshold, and de-allocating all such blocks. 
     As shown in  FIG. 8 , when the snapshot copy facility  52  creates a second snapshot copy of the production file, the snapshot copy facility  52  allocates an inode  121  for the second snapshot copy, and copies the content of the production file inode  110  into the second snapshot copy inode  121 . Then the snapshot copy facility  52  decrements the delegated reference count  112  in the mapping block pointer field  111  of the production file inode  110  by a partial-weight value of 10, and sets the delegated reference count  123  in the mapping block pointer field  122  of the second snapshot inode  121  to the same partial-weight value of 10. Thus, block pointer  124  of the mapping pointer field  122  in the second snapshot copy of the production file now points to the same file system data block  114  and indicates that file system data block  114  is now shared by the production file, the first snapshot copy and the second snapshot copy. 
     As shown in  FIG. 9 , with reference also to  FIG. 8 , when the snapshot copy facility  52  writes to the first data block of the production file, it allocates a new data block  125  and writes to the new data block  125  and sets the reference count  127  in the per-block metadata  126  of the new data block  125  to a full-weight value of 1,000, and decrements the reference count  116  in the per-block metadata  115  of the old data block  114  by the delegated reference count  112  associated with the mapping pointer of the old data block  114  (resulting in a decremented reference count of 20), and changes the block pointer  113  to point to the new data block  125 , and resets the delegated reference count  112  to a full-weight value of 1,000. Thus, file system data block  114  no longer remains shared between the production file and snapshot copies of the production file. 
     In general, the delegated reference counting mechanism as shown in  FIGS. 6-9  results in the reference count in the per-block metadata of a child block of a file system being equal to the sum of all the delegated reference counts associated with all of the child&#39;s parent blocks in the file system block hierarchy of the file system. The block sharing caused by creation of snapshot copies does not change the reference count in the per-block metadata of a child block, but the deletion of the production file or a snapshot copy will decrement the reference count in the per-block metadata of a child block by a full weight or a partial weight depending on whether or not the deleted version did not share the child block with a related version or did share the child block with a related version. 
     In at least one embodiment of the current technique, a logical view (also referred to herein as “primary namespace view”) of a set of files is created by creating a primary namespace inode (“also referred to herein as “working file namespace inode”) that includes a mapping of a real inode for each file of the set of files of the logical view to a virtual inode of each file. An indirect block pointer of the primary namespace inode points to an indirect block containing an inode file where each entry of the inode file corresponds to each file of the set of files of the primary namespace view. A logical block offset (“LBN”) of the indirect block of the primary namespace inode is mapped to a real inode number (“RIN”) of a file of the set of files included in the primary namespace view. A logical block offset mapped to a real inode of a file is used as a virtual inode number (VIN) for that file. Thus, each entry of the inode file of the primary namespace inode is mapped to a real inode of each file of the set of files of the primary namespace view. Further, the real inode of each file of the set of files of the primary namespace view is updated to include a parent virtual inode number. A parent virtual inode number for a file indicates the virtual inode number of a directory under which the file is stored or organized. Further, in at least one embodiment of the current technique, each entry of an indirect block of a primary namespace inode of a logical view includes a parent virtual inode number for a file associated with the indirect block entry. Initially, a fully weighted reference count is assigned to the indirect block of the primary namespace inode. Indirect blocks of the primary namespace inode are owned by the primary namespace inode indicating that no sharing relationship exists at the time the primary namespace view is created. Consequently, initially a fully weighted reference count is assigned to each entry of the indirect block of the primary namespace inode such that the distributed weight in the real inode of a file associated with each indirect block entry is equivalent to the initial delegated reference count stored in the indirect block entry associated with the real inode of the file. Further, in order to share contents of each file of the set of files between the primary namespace view and a snapshot copy of the primary namespace view, initially a fully weighted reference count is assigned to each block pointer field in the real inode of a file and each indirect block of the file and to the metadata of each indirect block of the file and each file system data block of the file based on the delegated reference counting mechanism. 
     It should be noted that there may not be a 1-1 correspondence between a logical offset and a logical block number (“LBN”). Thus, it should be noted that there may not be a 1-1 correspondence between a virtual inode number and a logical block number. Depending on the implementation, a logical block number may include more than one logical offset and thus may include more than one virtual inode number. 
     Referring to  FIG. 10 , shown is an illustration of an example representing a primary namespace view including a set of files that may be included in an embodiment using the techniques described herein. For example, in at least one embodiment, a primary (or “working”) namespace view includes a set of files such as file-1  135 , file-2  136 , and file-n  137  (files between files-2 and file-n are not shown). A namespace inode  130  is created for the primary namespace view. The primary namespace inode  130  includes a delegated reference count for each indirect block pointer of namespace inode  130 , information regarding whether an indirect block pointed to by each indirect block pointer is shared by snapshot copies of the primary namespace view. For example, indirect block-0 pointer  133  of namespace inode  130  for the primary namespace view includes a delegated reference count  131  associated with the parent-child relationship indicated by the indirect block pointer  133  and indirect block  134 . In the example of  FIG. 10 , delegated reference count  131  has an initial full-weight value of 1,000. Indirect block  134  pointed to by indirect block-0 pointer  133  associated with an inode file that stores information regarding the set of files included in the primary namespace view. Initially, at the time of creation of the primary namespace view, indirect blocks of the primary namespace inode  130  for the primary namespace view are owned by the primary namespace inode  130  indicating that no sharing relationship exists at that point in time. Thus, metadata  160  for indirect block  134  includes delegated weight  161  with initial full-weight value of 1,000. Further, shared information  132  for indirect block-0 pointer  133  indicates that the indirect block-0  134  is owned by the primary namespace inode  130  for the primary namespace view and is not shared by any other view. Each entry of the indirect block-0  134  associated with the inode file includes information for a file of the set of files included in the primary namespace view. For example, an entry  138  at the logical block offset “1” stores information regarding file-1  135 . A logical block offset within the indirect block-0  134  indicates a virtual inode number (“VIN”) for a file. Thus, the virtual inode number associated with a real inode number (“RIN”) of file-1  135  is 1. Indirect block entry  138  includes a delegated reference count for the inode of file-1  135  where the distributed weight included in the real inode of file-1  135  is equivalent to the initial delegated reference count stored in indirect block-0 entry  138  associated with the real inode of the file-1  135 . In the example of  FIG. 10 , the delegated reference count for file-1  135  has an initial full-weight value of 1,000. Thus, metadata  162  of file-1  135  includes delegated weight  163  that has initial full-weight value of 1,000. Further, indirect block entry  138  includes a parent virtual inode number for file-1  135  such that the parent virtual inode indicates the virtual inode number of a directory under which file-1  135  is stored or organized. Similarly, an indirect block entry  139  at the logical block offset of 2 stores information regarding file-2  136 . Indirect block entry  139  includes a delegated reference count for the inode of file-2  136 . In the example of FIG.  10 , the delegated reference count for file-2  136  has an initial full-weight value of 1,000. Also, the virtual inode number associated with a real inode number of file-2  136  is the logical block offset value of 2. Thus, metadata  164  of file-2  136  includes delegated weight  165  that has initial full-weight value of 1,000. Further, indirect block entry  139  includes a parent virtual inode number for file-2  136  such that the parent virtual inode indicates the virtual inode number of a directory under which file-2  136  is stored or organized. Similarly, an indirect block entry  140  at the logical block offset of n stores information regarding file-n  137 . Indirect block entry  140  includes a delegated reference count for the inode of file-n  137 . In the example of  FIG. 10 , the delegated reference count for file-n  137  has an initial full-weight value of 1,000. Also, the virtual inode number associated with a real inode number of file-n  137  is the logical block offset value of n. Thus, metadata  166  of file-n  137  includes delegated weight  167  that has initial full-weight value of 1,000. Further, indirect block entry  140  includes a parent virtual inode number for file-n  137  such that the parent virtual inode indicates the virtual inode number of a directory under which file-n  137  is stored or organized. Additionally, it should be noted that column “shared” of the indirect block-0  134  shown in  FIG. 10  is only for the purpose of illustration for indicating that inodes of files included in the inode file  134  of the primary namespace inode  130  are not shared at the time the primary namespace inode  130  is created for the primary namespace view. In at least one embodiment of the current technique, when the primary namespace inode of a primary namespace view is shared by a snapshot copy of the primary namespace view by creating a version of the primary namespace inode, the entire hierarchy of parent-child relationships starting from the primary namespace inode is assumed to inherit the sharing status indicated by sharing information stored in the primary namespace inode. 
     In at least one embodiment of the current technique, the delegated reference counting mechanism when enhanced to create a version of a namespace inode of a logical view results in the reference count in the per-block metadata of a child block of a storage hierarchy indicated by an inode file (e.g. real inode of a file) being equal to the sum of all the delegated reference counts associated with all of the child&#39;s parent blocks in the storage hierarchy (e.g. namespace inode). 
     Referring to  FIG. 11 , shown is an illustration of an example representing a snapshot copy of the primary namespace view of  FIG. 10  that may be included in an embodiment using the techniques described herein. With reference also to  FIG. 10 , a snapshot copy of the primary namespace view is created by creating a snapshot copy of the primary namespace inode  130  using the delegated reference counting mechanism described above herein. When the snapshot copy facility  52  creates a first snapshot copy of the primary namespace view, the snapshot copy facility  52  allocates a snapshot namespace inode  142  for the snapshot copy, and copies the contents of the primary namespace inode  130  into the snapshot namespace inode  142 . Then, the snapshot copy facility  52  decrements the delegated reference count  131  in the indirect block-0 pointer field of the primary namespace inode  130  by a partial-weight value of 10, and sets the delegated reference count  143  in the indirect block-0 pointer field of the snapshot namespace inode  142  to the same partial-weight value of 10. Thus, delegated weight  161  of indirect block-0  134  which is total of the delegated reference count  131  of the primary namespace inode  130  and delegated reference count  143  of the snapshot namespace inode  142  stays same with value of 1,000. Indirect block-0 pointer  145  in snapshot namespace inode  142  for the snapshot copy of the primary namespace view is updated to point to the same indirect block-0  134 , and thus indicates that inode file for the primary namespace view included in the indirect block-0  134  is shared by the primary namespace view and the snapshot copy of the primary namespace view. Further, sharing information  132  in the primary namespace inode  130  is updated to indicate that the inode file for the primary namespace inode  130  is shared by the primary namespace view and the snapshot copy of the primary namespace view, which in turns implies that the set of files included in the primary namespace view are shared by the primary namespace view and the snapshot copy of the primary namespace view. 
     As a result of the sharing relationship of the inode file included in the indirect block-0  134  of the primary namespace inode  130 , each entry in a hierarchical structure of the primary namespace inode  130  implicitly indicates that the inodes of the files included in the inode file for the primary namespace view are shared between the primary namespace view and the snapshot copy of the primary namespace view. Further, indirect blocks of a file of the set of files included in the primary namespace view are implicitly shared as well between the primary namespace view and the snapshot copy of the primary namespace view. 
     Generally, a write split operation based on the delegated reference counting mechanism is invoked upon receiving a write I/O request for a data block. The write split operation evaluates the shared bit stored in the mapping pointer for a data block to check whether the data block has been shared after application of the snapshot copy facility  52 . If the shared bit indicates that the data block has been shared among versions of a file, the write split operation breaks the sharing relationship of the data block and allocates a new data block for the write I/O request. If the mapping pointer that points to the data block resides in a shared indirect block, the sharing relationship of the indirect block is also broken. In such a case, the write split operation causes a new indirect block to be allocated and mapping pointers for all data blocks not involved in the write operation are copied to the new indirect block. The process of copying mapping pointers to the new indirect block includes distributing the delegated reference count values of mapping pointers between the original shared indirect block and the newly allocated indirect block. In addition to the distribution of the delegated reference count values, the shared bits of the copied mapping pointers are updated to indicate that the sharing relationship has been broken. Any reference to the old data block is released and the mapping pointer of the new data block is updated to point to the newly allocated data block. If the shared bit of the data block indicates that the data block has not been shared among versions of a file, contents of the data block are updated according to the write I/O request and the write I/O requests completes. 
     Referring to  FIG. 12 , shown is an illustration of an example representing a write operation on a file shared between the primary namespace view and the snapshot copy of the primary namespace view of  FIG. 11  that may be included in an embodiment using the techniques described herein. A write operation directed to a file of a primary namespace where the file is shared by the primary namespace and a snapshot copy of the primary namespace results into a change in the contents and/or metadata of the file. Thus, in order to preserve the sharing relationship of the file and other files included in the primary namespace view, an operation known as “inode split” is performed. Similar to the “write split” operation performed on a data block or an indirect block of a file as described herein, the “inode split” operation creates a snapshot copy (or “version”) of the inode file included in the primary namespace inode for the primary namespace view using the delegated reference counting mechanism. Further, the inode split operation creates a new real inode for the file on a storage disk. The snapshot copy of the primary namespace inode file becomes the inode file for the primary namespace inode. Further, the inode split operation preserves a file handle structure that is used to access a file by not changing the virtual inode number associated with the file when creating the new real inode for the file. 
     Thus, in at least one embodiment of the current technique, a write I/O operation directed to a file results in creating a snapshot copy or version of a file of the primary namespace view which includes creating a new real inode and allocating the newly allocated real inode to the file. Contents of the old inode of the file is copied to the newly allocated inode for the file. An indirect block entry associated with the file in the inode file of the primary namespace inode is updated to point to the newly allocated real inode for the file. However, the virtual inode number associated with the file remains same. The delegated reference count in the indirect block entry of the primary namespace inode is updated to indicate that the inode of the file is no longer shared between the primary namespace view and the snapshot copy of the primary namespace view. Further, the sharing relationship information in indirect block entry of the indirect block of the primary namespace inode is updated to indicate that the inode of the file included in the primary namespace view is no longer shared by the snapshot namespace view. The write I/O operation is performed on the file referred to by the real inode in the indirect block entry of the primary namespace inode. 
     In at least one embodiment of the current technique, the inode split operation is performed on an inode of a file in a similar way as the write operation is performed on an indirect block. Referring back to  FIG. 12 , for example, in at least one embodiment of the current technique, upon receiving a write I/O request for a file (e.g., file-2  136 ) included in the primary namespace view, the inode split operation creates a version of the inode file of the primary namespace inode  130  for the primary namespace view by creating a version of indirect block-0  134  of primary namespace inode  130  using the delegated reference counting mechanism. Indirect block-0 pointer  133  of the primary namespace inode  130  is updated to point to the indirect block-0′  150  which is a version or snapshot copy of the indirect block-0  134  of the primary namespace inode  130 . A new real inode  151  for file-2  136  is created. Indirect block entry  153  of indirect block-0′  150  of the primary namespace inode  130  is updated to point to the newly allocated real inode  151  (indicated as RIN′ in  FIG. 12 ) associated with file-2′  151  where file-2′ is a version of the file-2  136 . The delegated reference count in indirect block entry  153  of indirect block-0′  150  is updated to indicate that file-2′  151  is a version of file-2  136 . Further, file-2′  151  is viewed by a user of the primary namespace view as a working-file and file-2  136  is viewed as a point-in-time snapshot copy of the working-file file-2′  151 . Further, the primary namespace inode  130  and the snapshot namespace inode  142  structures are updated to indicate that the inode file  134  for the primary namespace view is no longer shared between the primary namespace view and the snapshot copy of the primary namespace view. However, the sharing relationships of other files such as file-1  135 , file-n  137  (and other files not shown) is preserved by sharing the inodes of such files. Thus, delegated weights of indirect blocks of the primary namespace inode  130  and snapshot namespace inode  142 , files  135 ,  151 ,  137 ,  136  are distributed to indicate the inode split operation described above herein. For example, in at least one embodiment as shown in  FIG. 12 , delegated weight  170  included in metadata  169  of indirect block-0′  150  is set to 990 and delegated weight  161  included in metadata  160  of indirect block-0  134  is set to 10. Similarly, delegated weight  172  included in metadata  171  of File-2′  151  is set to initial full-weight value of 1,000 and delegated weight  165  included in metadata  164  of file-2  136  is set to 500. Additionally, indirect block entry  152  of indirect block-0′  150  of the primary namespace inode  130  is updated to include delegated reference count of 990 to indicate that file-1  135  pointed to by the entry  152  is shared with snapshot namespace inode file  142 . Similarly, indirect block entry  154  of indirect block-0′  150  of the primary namespace inode  130  is updated to include delegated reference count of 990 to indicate that file-n  137  pointed to by the entry  154  is shared with snapshot namespace inode file  142 . Correspondingly, entries  138 ,  139 ,  140  of indirect block-0  134  of the snapshot namespace inode  142  are each updated to include delegated reference count of 10 to indicate the sharing relationship of files  135 ,  136 ,  137  with the primary namespace inode  130 . The sharing relationship information in the indirect block of the primary namespace inode is updated to indicate that the inode file of the primary namespace view is no longer shared with the snapshot namespace inode for the snapshot namespace view. 
     Referring to  FIG. 13 , shown is a representation of a container file system including a set of logical views that may be included in an embodiment using the current techniques described herein. A file system such as a container file system  350  may include a primary file system namespace  352 , a first snapshot copy of the primary file system namespace  354 , a second snapshot copy of the primary file system namespace  356 , and a directory namespace view  355 . The container file system  350  acts as a pool of storage for a user  357  of data storage system  12  such that the user  357  may create a set of logical views of storage objects, create snapshot copies of a logical view, and create a directory namespace view based on the set of logical views or any one of the snapshot copies of the logical view. 
     Referring to  FIG. 14 , shown is an illustration of an example representing a hierarchy of storage objects that may be included in an embodiment using the techniques described herein. In at least one embodiment of the current technique, a set of storage objects (e.g. files, directories, logical volumes) may be organized as a hierarchy in a namespace view with a root object  400  at the top of the hierarchy. Root object  400  may include file named “dummy”  402  and lower level directory (also referred to herein as “sub-directory”) named “foo”  402 . Sub-directory “foo” may further include file named “bar”  403 . 
     Referring to  FIG. 15 , shown is an illustration of an example representing a primary namespace view including a set of files that may be included in an embodiment using the techniques described herein. With reference also to  FIG. 14 , for example, in at least one embodiment, a primary (or “working”) namespace view  410  includes a set of files and directories such as directory “root”  400 , file “dummy”  401 , sub-directory “foo”  402 , and file “bar”  403 . A namespace inode  412  is created for the primary namespace view  410 . In the example of  FIG. 15 , delegated reference count  415  for namespace inode  412  has an initial full-weight value of 1,000. Indirect block  420  pointed to by indirect block-0 pointer  417  is associated with an inode file that stores information regarding the set of files included in the primary namespace view  410 . Further, shared information  416  for indirect block-0 pointer  417  indicates that the indirect block-0  420  is owned by the primary namespace inode  412  for the primary namespace view  410  and is not shared by any other view. Each entry of the indirect block-0  420  associated with the inode file includes information for a file of the set of files included in the primary namespace view  410 . For example, an entry  421  at the logical block offset “1” stores information regarding directory “root”  400 . In the example of  FIG. 15 , the delegated reference count for directory “root”  400  has an initial full-weight value of 1,000. Also, the virtual inode number associated with a real inode number of directory “root”  400  is the logical block offset value of 1. Further, indirect block entry  421  includes a parent virtual inode number for directory “root”  400  such that the parent virtual inode indicates the virtual inode number of a directory under which directory “root”  400  is stored or organized. But, in  FIG. 14 , directory “root” is at the top level of the hierarchy under which the set of files and directories included in the namespace view  410  are organized. Thus, the parent virtual inode number in indirect block entry  421  is marked as an empty entry. Similarly, an indirect block entry  422  at the logical block offset of 2 stores information regarding sub-directory “foo”  402 . Indirect block entry  422  includes a delegated reference count for the inode of sub-directory “foo”  402 . In the example of  FIG. 15 , the delegated reference count for sub-directory “foo”  402  has an initial full-weight value of 1,000. Also, the virtual inode number associated with a real inode number of sub-directory “foo”  402  is the logical block offset value of 2. Further, indirect block entry  139  includes a parent virtual inode number for sub-directory “foo”  402  such that the parent virtual inode indicates the virtual inode number of a directory under which sub-directory “foo”  402  is stored or organized. Thus, sub-directory “foo”  402  has the parent virtual inode number of “1” which is the virtual inode number of directory “root”  400  because “foo”  402  is organized under directory “root”  400 . Similarly, an indirect block entry  423  at the logical block offset of 3 stores information regarding file “bar”  403 . In the example of  FIG. 15 , the delegated reference count for file “bar”  403  has an initial full-weight value of 1,000. Also, the virtual inode number associated with a real inode number of file “bar”  403  is the logical block offset value of 3. Further, indirect block entry  423  includes a parent virtual inode number for file “bar”  403  such that the parent virtual inode indicates the virtual inode number of a directory under which file “bar”  403  is stored or organized. Thus, file “bar”  403  has the parent virtual inode number of “2” which is the virtual inode number of sub-directory “foo”  402  because “bar”  403  is organized under directory sub-directory “foo”  402 . Similarly, an indirect block entry  424  at the logical block offset of 4 stores information regarding file “dummy”  401 . In the example of  FIG. 15 , the delegated reference count for file “dummy”  401  has an initial full-weight value of 1,000. Also, the virtual inode number associated with a real inode number of file “dummy”  401  is the logical block offset value of 4. Further, indirect block entry  424  includes a parent virtual inode number for file “dummy”  401  such that the parent virtual inode indicates the virtual inode number of a directory under which file “dummy”  401  is stored or organized. Consequently, file “dummy”  401  has the parent virtual inode number of “1” which is the virtual inode number of directory “root”  400  because “dummy”  401  is organized under directory “root”  400 . 
     Further, in at least one embodiment of the current technique, a root virtual inode of a namespace view indicates a virtual inode of an object (e.g., directory) that exists at the top level of a hierarchy under which a set of objects included in the namespace view are organized. For example, in  FIG. 15 , root virtual inode  411  of namespace view  410  is 1 which is the virtual inode number of directory “root”  400  under which each object of the namespace view  410  is organized. 
     Referring to  FIG. 16 , shown is an illustration of an example representing a hierarchy of storage objects that may be included in an embodiment using the techniques described herein. In at least one embodiment of the current technique, a set of storage objects (e.g. files, logical volumes) of a directory namespace view may be organized as a file directory hierarchy. For example, in  FIG. 16 , sub-directory “foo”  402  is at the top of the file directory hierarchy for the directory namespace view that includes sub-directory “foo”  402  and file “bar”  403 . 
     Referring to  FIG. 17 , shown is an illustration of an example representing a directory namespace view based on the primary namespace view of  FIG. 15  that may be included in an embodiment using the techniques described herein. In at least one embodiment of the current technique, a directory namespace view is created from a namespace view in two phases. The first phase includes creating a snapshot copy of the namespace view by creating a version of a namespace inode of the namespace view. The version of the namespace inode indicates a directory namespace inode for the directory namespace view. The directory namespace inode for the directory namespace view includes a state that indicates a phase of a process which creates the directory namespace view. During the first phase, the state of the directory namespace inode for the directory namespace view indicates that a trimming operation is pending. At the end of the first phase, the namespace inode for the namespace view is shared between the namespace view and the directory namespace view. The second phase performs the trimming operation which includes performing an inode file split operation, and removing information for a file or directory from the directory namespace inode of the directory namespace view such that the file is not associated with a file directory hierarchy indicated by the directory namespace view. Thus, at the end of the second phase, the directory namespace inode for the directory namespace view includes information for only such files that are part of the file directory hierarchy indicated by the directory namespace view. Further, the state of the directory namespace inode for the directory namespace view is updated to indicate that the trimming operation has been completed. 
     With reference also to  FIGS. 14-16 , for example, a directory namespace view  430  is created such that the directory namespace view  430  indicates a file directory hierarchy which includes sub-directory “foo”  402  at the top of the file directory hierarchy and file “bar”  403  organized under the sub-directory “foo”  402 .  FIG. 17  illustrates the first phase of a process that creates directory namespace view  430 . During the first phase, a snapshot copy of the primary namespace view  410  is created by creating a version of the primary namespace inode  420  using the delegated reference counting mechanism described above herein. The snapshot copy facility  52  allocates a directory namespace inode  432  for the directory namespace view  430 , and copies the contents of the primary namespace inode  412  into the directory namespace inode  432 . Then, the snapshot copy facility  52  decrements the delegated reference count  415  in the indirect block-0 pointer field of the primary namespace inode  412  by a partial-weight value of 10, and sets the delegated reference count  433  in the indirect block-0 pointer field of the directory namespace inode  432  to the same partial-weight value of 10. Thus, delegated weight  426  of indirect block-0  420  which is total of the delegated reference count  415  of the primary namespace inode  412  and delegated reference count  433  of the directory namespace inode  432  stays same with value of 1,000. Indirect block-0 pointer  435  in directory namespace inode  432  is updated to point to the same indirect block-0  420 , and thus indicates that during the first phase inode file for the primary namespace view  410  included in the indirect block-0  420  is shared by the primary namespace view  410  and the directory namespace view  430 . Further, sharing information  415  in the primary namespace inode  410  is updated to indicate that the inode file for the primary namespace inode  412  is shared by the primary namespace view  410  and the directory namespace view  430 , which in turns implies that the set of files and directories included in the primary namespace view  410  are shared by the primary namespace view  410  and the directory namespace view  430 . Further, state  431  of the directory namespace view  430  is updated to indicate that the trimming operation is pending. Further, root virtual inode  431  for the directory namespace view  430  is set to 2 indicating the virtual inode number of sub-directory “foo”  402  that is organized at the top level of the file directory hierarchy represented by the directory namespace view  430 . 
     Referring to  FIG. 18 , shown is an illustration of an example representing a directory namespace view that may be included in an embodiment using the techniques described herein.  FIG. 18  illustrates the second phase of the process for creating directory namespace view  430 . With reference also to  FIG. 17 , the second phase performs an “inode file split” operation similar to the “write split” operation performed on a data block or an indirect block of a file and similar to the “inode split” operation performed on a real inode of a file of a namespace view as described herein. The “inode file split” operation creates a snapshot copy (or “version”) of the inode file included in a primary namespace inode for a primary namespace view using the delegated reference counting mechanism. The indirect block pointer of a directory namespace view is updated to point to the newly created version of the inode file of the primary namespace inode. Further, the inode file split operation preserves a file handle structure that is used to access a file by not changing the virtual inode number associated with the file. Further, the inode file split operation does not create a new version of the real inode of the file on a storage disk unlike an inode split operation. 
     In at least one embodiment of the current technique, the inode file split operation is performed on an inode file of a primary namespace view in a similar way as the write operation is performed on an indirect block. Referring back to  FIG. 18 , for example, in at least one embodiment of the current technique, during the second phase, the inode file split operation creates a version of the inode file of the primary namespace inode  412  for the primary namespace view  410  by creating a version of indirect block-0  420  of primary namespace inode  412  using the delegated reference counting mechanism. Indirect block-0′ pointer  435  of the directory namespace inode  432  is updated to point to the indirect block-0′  460  which is the newly created version or snapshot copy of the indirect block-0  420  of the primary namespace inode  412 . Further, the primary namespace inode  412  and the directory namespace inode  432  structures are updated to indicate that the inode file  420  for the primary namespace view  410  is no longer shared between the primary namespace view  410  and the directory namespace view  431 . However, the sharing relationships of files such as “dummy”  401 , “bar”  403 , “foo”  402 , and “root”  400  is preserved by sharing the inodes of such files. Thus, delegated weights of indirect blocks of the primary namespace inode  412  and directory namespace inode  432  are distributed in accordance with the delegated reference counting mechanism to indicate the inode file split operation described above herein. For example, in at least one embodiment as shown in  FIG. 18 , delegated weight  426  included in metadata  425  of indirect block-0  420  is set to 990. The second phase then performs the trimming operation which removes information regarding file “dummy”  401  and directory “root”  400  from the indirect block-0′  460  of the directory namespace inode  432  because the file directory hierarchy indicated by the directory namespace view  430  does not include such files. As a result, information regarding directory “root”  400  is removed from the logical offset 1 of the indirect block-0′  460  and information regarding file “dummy”  401  is removed from the logical offset 4 of the indirect block-0′  460 . 
     Further, in at least one embodiment of the current technique, the state  431  of the directory namespace view  430  is updated to indicate that the trimming operation has finished successfully. Further, in at least one embodiment of the current technique, information from the inode file  460  of directory namespace view  430  is removed by traversing each entry of indirect block-0′  460  such that a parent virtual inode number of each entry is compared with the root virtual inode number of the directory namespace view  430  in order to determine whether the entry belongs to the file directory hierarchy indicated the directory namespace view  430 . Thus, at the end of the second phase, the directory namespace view  430  only shares those files with primary namespace view  410  that are included in the file directory hierarchy indicated by the directory namespace view  430 . 
     Additionally, indirect block entry  422  of indirect block-0  420  of the primary namespace inode  410  is updated to include delegated reference count of 990 to indicate that sub-directory “foo”  402  pointed to by the entry  422  is shared with directory namespace inode file  432 . Similarly, indirect block entry  423  of indirect block-0  420  of the primary namespace inode  410  is updated to include delegated reference count of 990 to indicate that file “bar”  403  pointed to by the entry  423  is shared with directory namespace inode file  432 . Correspondingly, entries  464 ,  465  of indirect block-0′  460  of the directory namespace inode  432  are each updated to include delegated reference count of 10 to indicate the sharing relationship of file “bar”  403  and sub-directory “foo”  402  with the primary namespace inode  412 . Further, entries  421 ,  424  of indirect block-0  420  of primary namespace inode  412  is updated to indicate that the directory “root”  400  and file “dummy”  401  is no longer shared between the primary namespace view  410  and the directory namespace view  430 . The sharing relationship information in the indirect block  416  of the primary namespace inode  412  is updated to indicate that the inode file of the primary namespace view  410  is no longer shared with the directory namespace inode  432  for the directory namespace view  430 . Similarly, the sharing relationship information in the indirect block  434  of the directory namespace inode  432  is updated to indicate that the inode file of the directory namespace view  430  is no longer shared with the primary namespace inode  412  for the primary namespace view  410 . 
     Referring to  FIG. 19 , shown is an illustration of an example representing a snapshot copy of the directory namespace view of  FIG. 18  that may be included in an embodiment using the techniques described herein. With reference also to  FIG. 18 , a snapshot copy of the directory namespace view  430  may be created by creating a snapshot copy of the directory namespace inode  432  using the delegated reference counting mechanism described above herein. The snapshot copy facility  52  allocates a snapshot namespace inode  472  for the snapshot copy  470 , and copies the contents of the directory namespace inode  432  into the snapshot namespace inode  472 . Then, the snapshot copy facility  52  decrements the delegated reference count  433  in the indirect block-0 pointer field of the directory namespace inode  432  by a partial-weight value of 10 to 990, and sets the delegated reference count  475  in the indirect block-0 pointer field of the snapshot namespace inode  472  to the same partial-weight value of 10. Indirect block-0 pointer  473  in snapshot namespace inode  472  for the snapshot copy of the directory namespace view  430  is updated to point to the same indirect block-0′  460 , and thus indicates that inode file for the directory namespace view  430  included in the indirect block-0′  435  is shared by the directory namespace view  430  and the snapshot copy of the directory namespace view. Further, sharing information  434  in the directory namespace inode  432  is updated to indicate that the inode file for the directory namespace inode  432  is shared by the directory namespace view  430  and the snapshot copy of the directory namespace view  430 , which in turns implies that the set of files and directories included in the directory namespace view  430  is shared by the directory namespace view  430  and the snapshot copy of the directory namespace view  430 . 
     Referring to  FIG. 20 , shown is a flow diagram illustrating a flow of data in the data storage system. With reference also to  FIGS. 14-19 , managing logical views of directories in a data storage system  10  includes creating a directory namespace view based on a primary namespace view or a snapshot copy of the namespace view (step  500 ). In at least one embodiment of the current technique, the snapshot copy facility  52  working in conjunction with logical view management logic  63  creates a directory namespace view from a primary namespace view by creating a directory namespace inode using the delegated reference counting mechanism described above herein such that that the directory namespace inode is a version of the primary namespace inode of the primary namespace view (step  502 ). The directory namespace view represents a file directory hierarchy such that files and/or directories included in the file directory hierarchy are subset of files and/or directories included in the primary namespace view. The directory namespace inode includes a root virtual inode number which is updated to the virtual inode number of a directory that is at the top level of the file directory hierarchy represented by the directory namespace view (step  504 ). The state of the directory namespace inode is updated to indicate that a trimming operation is pending for the directory namespace inode (step  506 ). The trimming operation may be performed as a background process (step  508 ). 
     Referring to  FIG. 21 , shown is a flow diagram illustrating a flow of data in the data storage system. With reference also to  FIGS. 14-20 , the trimming operation includes creating a version of a namespace inode file shared between the directory namespace view and the primary namespace view using the delegated reference counting mechanism described above herein (step  510 ). The indirect block pointer of the directory namespace inode is updated to point to the newly created version of the indirect block of the directory namespace inode (step  512 ). The sharing relationship information in the indirect block of the primary namespace inode is updated to indicate that the namespace inode file of the primary namespace view is no longer shared with the directory namespace view (step  514 ). Each entry of the indirect block of the directory namespace inode is evaluated and processed by the trimming operation (step  516 ). 
     Referring to  FIG. 22 , shown is a flow diagram illustrating a flow of data in the data storage system. With reference also to  FIGS. 14-21 , the trimming operation process each entry of the indirect block of the directory namespace inode for the directory namespace view (step  516 ). An entry of the indirect block is read from the directory namespace inode (step  518 ). A determination is made as to whether the virtual inode number of the entry is same as the root virtual inode number for the directory namespace inode (step  520 ). If the virtual inode number of the entry is same as the root virtual inode number for the directory namespace inode, the information stored in that entry can not be removed because the entry specifies information regarding the directory that is at the top level of the file directory hierarchy represented by the directory namespace inode. Thus, the trimming operation proceeds to read a next entry of the indirect block of the directory namespace inode (step  522 ). If the virtual inode number of the entry that is being processed is different from the root virtual inode number of the directory namespace inode, a determination is made as to whether the entry includes a parent virtual inode number (step  524 ). If the entry includes the parent virtual inode number, the trimming operations locates a parent entry associated with the parent virtual inode number in the inode file of the directory namespace inode and reads information regarding the parent entry from the inode file (step  526 ). The virtual inode number of the parent entry is then compared with the root virtual inode of the directory namespace view (step  520 ). In effect, the trimming operation attempts to follow a directory hierarchy by looking up a parent virtual inode number of a file indicated by an entry of an indirect block of a directory namespace inode until the virtual inode number of an entry matches with the root virtual inode of the directory namespace view or the entry does not indicate a parent virtual inode. Thus, the trimming operation attempts to traverse the file directory hierarchy by finding a directory at the top level under which a file associated with an entry of the indirect block of the directory namespace view is organized. If the virtual number of the directory at the top level is different from the root virtual inode number for the directory namespace inode, the trimming operation removes information regarding the directory and files and sub-directories organized under the directory that has been traversed by the trimming operation from the directory namespace inode. 
     Referring back to  FIG. 22 , if at step  524 , the entry that is being processed by the trimming operation does not include the parent virtual inode number indicating that the entry is not part of the file directory hierarchy, the trimming operation removes information regarding the entry from the indirect block of the directory namespace inode (step  528 ). Further, the trimming operation removes information regarding files and/or sub-directories that are traversed by the trimming operation in order to evaluate the entry indicating that the files and/or sub-directories are not part of the file directory hierarchy indicated by the directory namespace view. Further, the delegated reference count in the indirect block entry of the directory namespace inode is updated to indicate that the inode of the file indicated by the entry is no longer shared between the directory namespace view and the primary namespace view (step  530 ). The trimming operation proceeds to read a next entry of the indirect block of the directory namespace inode (step  522 ). 
     For example, referring back to  FIG. 18 , the trimming operation first evaluates the first entry  463  of indirect block-0′  460  of directory namespace inode  432 . The entry  463  stores information regarding directory “root”  400 . The virtual inode number of “root”  400  is compared with the root virtual inode number for directory namespace view  430 . The trimming operation removes information regarding “root”  40  from entry  463  of indirect block-0′  460  because the virtual inode number (e.g., value “1”) of “root”  400  is not same as the root virtual inode number (e.g., value “2”) for directory namespace view  430  and “root”  400  does not include a parent virtual inode number. The trimming operation then proceeds to evaluate entry  464  that stores information regarding “foo”  402 ″. The virtual inode number of “foo”  400  (e.g., value “2”) is compared with the root virtual inode number (e.g., value “2”) for directory namespace view  430 . The trimming operation retains the information in entry  464  and proceeds to evaluate the next entry  465  because the virtual inode number of “foo”  400  is same as the root virtual inode number for directory namespace view  430 . Then, the entry  465  is evaluated such that the virtual inode number of “bar”  403  (e.g., value “3”) stored in entry  465  is compared with the root virtual inode number (e.g., value “2”) for directory namespace view  430 . The trimming operation then evaluates parent virtual inode number for “bar”  403  because the virtual inode number for “bar”  403  is not same as the root virtual inode number. The trimming operation locates the entry  464  because the virtual inode number of the entry  464  is same as the parent virtual inode number for “bar”  403 . The trimming operation compares the virtual inode number of the entry  464  (“foo”  402 ) with the root virtual inode number and proceeds to evaluate the next entry  466  upon finding that the virtual inode number of entry  465  is same as the root virtual inode number. Thus, the trimming operation retains the information in entry  465 . Entry  466  stores information regarding file “dummy”  401 . The virtual inode number of “dummy”  401  (e.g., value “4”) is compared with the root virtual inode number (e.g., value “2”) for directory namespace view  430 . The trimming operation then evaluates parent virtual inode number for “dummy”  401  because the virtual inode number for “dummy”  401  is not same as the root virtual inode number. The trimming operation determines that the directory “root” is associated with the parent virtual inode number for “dummy”  401  which is not part of the file directory hierarchy. Thus, the trimming operation removes information from the entry  466 . 
     Referring to  FIG. 23 , shown is a flow diagram illustrating a flow of data in the data storage system. With reference also to  FIGS. 14-22 , snapshot copy facility  52  creates a snapshot copy of a directory namespace view (step  540 ). A determination is made as to whether the snapshot copy facility is attempting to create a first version (or “copy”) of the directory namespace view (step  542 ). If the snapshot copy facility is attempting to create a first snapshot copy of the directory namespace view, the snapshot copy facility must wait until the trimming operation on the directory namespace inode for the directory namespace view is finished such that the directory namespace view includes information for a file directory hierarchy represented by the directory namespace view (step  544 ). If the snapshot copy facility is not attempting to create a first snapshot copy of the directory namespace view or the trimming operation has been finished for the directory namespace view, the snapshot copy of the directory namespace view is created by creating a version of the directory namespace inode for the directory namespace view using the delegated reference counting mechanism (step  546 ). Contents of the directory namespace inode structure are copied to the newly created snapshot namespace inode. Relevant metadata structures are updated to indicate the sharing relationship of the file directory hierarchy of the directory namespace view (step  548 ). Further, indirect blocks of a file of the file directory hierarchy indicated by the directory namespace view are implicitly shared as well between the directory namespace view and the snapshot copy of the directory namespace view. 
     While the invention has been disclosed in connection with preferred embodiments shown and described in detail, their modifications and improvements thereon will become readily apparent to those skilled in the art. Accordingly, the spirit and scope of the present invention should be limited only by the following claims.