US20070100855A1 - Computer method and apparatus for handling private process state in a stacking file system - Google Patents
Computer method and apparatus for handling private process state in a stacking file system Download PDFInfo
- Publication number
- US20070100855A1 US20070100855A1 US11/254,987 US25498705A US2007100855A1 US 20070100855 A1 US20070100855 A1 US 20070100855A1 US 25498705 A US25498705 A US 25498705A US 2007100855 A1 US2007100855 A1 US 2007100855A1
- Authority
- US
- United States
- Prior art keywords
- directory
- filesystem
- subject
- operations
- stacking
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/18—File system types
- G06F16/188—Virtual file systems
- G06F16/192—Implementing virtual folder structures
Definitions
- a file system is the mechanism that defines the storage, hierarchical organization, access and operations for retrieval and manipulation of data on a storage device or medium (e.g., a hard disk or a CD-ROM).
- Computer systems using UNIX or Linux operating systems require a file system called the “root filesystem”.
- the root filesystem includes programs and information to start up and manage the subject computer system.
- the root filesystem is formed of a hierarchical tree of directories 91 and files 89 where the root 93 of this tree is referred to as “root” and denoted by “/”.
- FIG. 1 shows a typical UNIX root filesystem 87 .
- a “regular” file commonly called “file” is a named container of information stored in a directory.
- a “directory” file is a container of directory entries, for each file in the subject directory. Each directory entry includes a name and a set of attributes that point to a file (for example its inode, see below).
- a “symbolic link” is a file containing a pointer to a different file which can be used through the symbolic link. This file type serves to overcome the limitations of hard links which are discussed later.
- a “Block and character oriented device file” is not a container of sorts but rather an interface to an I/O device that can be accessed directly through the file.
- “Special” files (pipes and sockets) are files used for interprocess communication and networking.
- directories are files that contain directory entries that point to an inode. As a consequence, one file on a disk may be pointed to by different directory entries. It is said that this file has different hard links.
- a link counter In order to maintain multiple hard links, for each inode there is a link counter. The link counter is decremented each time a hard link is deleted and incremented when a hard link is created. Only when the link counter reaches zero are actual data blocks on disk released.
- Hard links are subject to some restrictions. First, users are not allowed to create hard links to directories. Secondly, users are not allowed to create hard links that cross filesystems. This is because in the directory entry the inode number is used as a pointer to the inode, and inode numbers are only unique within one filesystem.
- FIG. 2 shows the root filesystem 93 from FIG. 1 after a CD-ROM (separate filesystem 77 ) has been mounted to the mount point labeled /mnt/cdrom 95 . As long as the CD-ROM 77 is mounted, the information stored on it will be available there and accessible through mnt/cdrom.
- VFS virtual filesystem
- Virtual Filesystem Switch is a software layer handling the generic tasks involved in the use of a filesystem. These generic tasks include error checking, caching VFS objects, doing the required locking and communicating with user space. Once the generic tasks are completed, the VFS passes the operation on to the specific layer, where it may be completed or again passed on to a next lower layer.
- FIG. 3 shows the relation between the generic VFS layer 71 and a specific filesystem layer 73 .
- the superblock object this object holds all data relevant to a mounted filesystem 77 .
- Disk-based filesystems usually store a copy of this object on disk.
- the inode object stores information on a file located within a filesystem, such as size, permissions or access time. Most important, it holds the inode number which is used to uniquely identify a file within a filesystem. Disk-based filesystems usually store a copy of this object.
- the dentry object represents a link from a directory entry to an inode. This is necessary because one file can be represented by several hard links.
- the VFS 71 caches the dentry objects in order to speed up lookup operations.
- Each of these objects has a set of operations associated with it which can be defined by a specific filesystem 73 . These operations are implemented as a set of function pointers which are used by the VFS 71 to call the appropriate function of the specific filesystem 73 .
- the separation of generic and specific layers shown in FIG. 3 is achieved where the VFS 71 is able to call the appropriate function of a specific filesystem 73 without having to know any specific detail on how the data is stored in that filesystem 73 .
- filesystems are mainly implemented in kernel space where debugging is difficult and small bugs may crash a whole computer system. Also filesystems tend to consist of large amounts of code that, due to the nature of operating system kernels, is fairly complex. Therefore, changing and extending existing functionality is difficult.
- FIG. 4 shows the relationship between the VFS 71 , a stackable filesystem 75 and the lower (specific) filesystem 73 .
- the VFS layer 71 that handles the generic actions involved in a filesystem 73 operation remains at the top of this hierarchy. When these actions have been completed, the subject function is called for the next lower level.
- the VFS 71 as a generic layer does not need to know what type of filesystem the lower layer is and will simply call the appropriate function via the VFS-object function pointers. This enables a new layer to be introduced, the new layer being the stackable filesystem layer 75 .
- the stackable filesystem 75 is mounted on top of a mounted filesystem and accessed through the new mount point.
- the new stackable filesystem layer 75 has to behave differently from traditional filesystems. As lower layers 73 do not have any knowledge about their caller, the stackable layer 75 needs to present itself in two different manners: to the lower level as the VFS and to the higher as a traditional filesystem.
- VFS 71 calls a function of the stackable layer 75
- generic tasks are first performed as done previously by the VFS 71 but for the stackable filesystem 75 .
- the stackable file system layer 75 invokes zero or more functions (as object methods) on the layer 73 beneath it. When the call returns to the stackable filesystem layer 75 , the result is handled accordingly and then returned to the VFS 71 .
- Linux kernels do not have a UNIX System V release 4 (SVR4)-style vnode interface. Instead Linux kernels have a different interface spread among several distinct object types and operation vectors.
- SVR4 UNIX System V release 4
- inodes struct inode and inode_operations
- directory cache entries dentries or dcache entries, struct dentry
- open-file objects struct file and file_operations
- address space objects struct super_block and super_operations
- super blocks struct super_block and super_operations
- a stacking file system can establish a per-process root context for file operations. On an SVR4 system this can be done by issuing a hidden chroot to a special vnode in the stacking file system. This special vnode then serves as the starting point for pathnames beginning with “/”. VOP_LOOKUP( ) invoked on this vnode may return vnode objects from the original root file system, e.g. looking up “etc” returns the original root file system's vnode representing “/etc”. As lookups continue down the name tree and encounter another mounted file system instance from the stacking file system, the context can be found from the process's root directory vnode. The stacking file system then returns results consistent with its design.
- the Linux kernel requires file systems to use the directory name cache (dentry) structures instead of vnodes for many of its file operations. Most of the Linux kernel's namespace-related file operations operate on dentries. Many other kernel operations use dentries to hold references to files (most notably the current directory and process root directory).
- Each separately-mounted file system has a separate dentry tree. Within each mounted file system, these structures are linked in a hierarchical tree structure reflecting the namespace of the file system. The root of the tree is the root of the file system's name space. When a mount-point is encountered, the mounted-over dentry and the mounted-over file system structure (vfsmnt) are used as hash keys to find the new file system's root dentry and file system structure.
- the present invention addresses the problems of the prior art.
- the present invention utilizes directory names in the namespace of a subject filesystem without interference from the virtual directory names of the stacking filesystem.
- a computer method and apparatus handle directory names as follows. Given a computer system, there is a subject filesystem and a corresponding stacking filesystem.
- the present invention method and apparatus obtain directory trees of the subject filesystem. Each directory tree has a root directory entry and plural directory entries linked together in a hierarchical manner. Each directory entry has a respective directory name. For each directory entry, there is a respective filesystem object representing the directory entry.
- the file system objects in the stacking filesystem have respective virtual directory names.
- the invention uses the directory trees of the subject filesystem to process operations such that operations are processed using directory names in a name space of the subject filesystem free of interference from the virtual directory name of the stacking filesystem.
- the present invention further employs one or more alias directory entries.
- Each alias directory entry has a respective support structure that defines a private state and that provides a pointer to a root directory entry of one of the directory trees of the subject filesystem. Further the invention method/system substitutes a new inode operations vector for an inode operations vector of the root directory entry.
- FIG. 1 is a schematic diagram of a typical UNIX root filesystem.
- FIG. 2 is a schematic diagram of the root filesystem of FIG. 1 after mounting a CD (the mounted filesystem).
- FIG. 3 is a block diagram of a Virtual Filesystem Switch.
- FIG. 4 is a block diagram of a stacking filesystem.
- FIG. 5 is a schematic view of one embodiment of the present invention.
- FIG. 6 is a block diagram detailing handling of a dentry of FIG. 5 .
- FIG. 7 is a schematic view of a computer network environment in which embodiments of the present invention may be deployed.
- FIG. 8 is a block diagram of one computer node in the FIG. 7 network environment.
- FIG. 9 is a flow diagram of software or method embodiments of the present invention as implemented in FIGS. 7 and 8 .
- FIG. 5 Illustrated in FIG. 5 is a subject filesystem 19 such as in the Linux operating system of interest to the present invention.
- the subject filesystem 19 has root 21 and dentries 23 linked in a hierarchical tree structure.
- An example dentry is /etc 23 b which is further described in FIG. 6 (discussed below) demonstrating principles of the present invention.
- At 25 is a mount point for a mounted file system 27 .
- Mounted filesystem 27 has a separate dentry tree (illustrated at continuation A) formed of respective dentries, files, root 29 and the like.
- the root 29 dentry of mounted filesystem 27 is found by matching the mount-over dentry 25 (e.g., “dentry 4 ”) and the mount-over file system 19 (e.g., terminal A) in a hash table.
- the present invention uses the system's dentry trees (e.g., from roots 21 , 29 and the like) for all filesystem objects not contained in the stacking filesystem 33 .
- This allows the subject filesystem 19 to process file operations on real objects without interference from the stacking filesystem 33 , resulting in more reliable and correct filesystem operations.
- a key consideration with this approach is to set up the process environment to have a reliable inheritance of the stacking filesystem's 33 root context to new processes and use the subject filesystem's 19 (vfsmnt, dentry) for most lookups. This is done by setting the process root to be
- the present invention hides the context in the dentry operations vector 41 . That is, in the present invention d_ops is made to point to a working structure 43 that contains not only the dentry operations vector 41 ′ but also a private state 45 (current stacking filesystem context 36 , a reference to the stacking filesystem's 33 mount point, and a pointer 47 to the real root 21 dentry). This would be sufficient except that any lookups in the VFS 39 dcache would have the parent link set to an alias dentry 35 , not the real dentry 21 , resulting in an isolated duplicate dentry tree in the stacking filesystem 33 . Any mountpoint crossings into the subject filesystems 19 , 33 , at the same name as dentry 25 , would fail to find the target mounts because of the duplicate dentries.
- the present invention replaces the inode operations vector 40 in the root inode 37 with a respective lookup vector 49 , and saves the original vector pointer 51 .
- a lookup routine of the present invention is called for all lookups in/(e.g., real root 21 ), even for processes not using the stacking filesystem 33 .
- the Linux kernel calls the inode's lookup method as such:
- the invention routine 15 checks this parent dentry field to see if it is an alias dentry 35 . If it is not one of the subject aliases 35 , then the routine 15 calls the real lookup method via saved pointer 51 and saved original operations 40 , and returns its results (as described in FIG. 4 ).
- the invention method and apparatus 15 unwraps to the real root dentry 21 (from the alias dentry's extended operation vector 41 ′ in structure 43 and pointer 47 ), then calls back into the Linux kernel's dcache (via the lookup_hash( ) function) to look up the prospective new dentry 23 name as a child of the original root 21 directory entry. If the cache misses, the root inodes 37 lookup ( ) routine as substituted by the present invention lookup method at 49 is called again, this time passing a new prospective dentry 13 whose parent is the subject file system's dentry 21 . In response, the lookup method behaves as above returning the real inode routine's 40 results.
- FIG. 6 shows the corresponding dentry object 23 b and associated inode object 38 (holding /etc's unique inode number in filesystem 19 ) used by the VFS 39 and stacking filesystem 33 methods.
- /etc′ 13 is used in the stacking filesystem 33 name space.
- the present invention uses /etc′′ 53 and sets the process root to alias dentry 35 .
- a call to the inode lookup method is then
- the root inode 37 lookup routine 49 determines the parent of the dentry parameter is the real root dentry 21 .
- the routine 15 invokes old inode operations vector 40 and returns the respective /etc dentry 23 b (i.e., the link from directory entry 23 b to the corresponding inode 38 ) as described above.
- FIG. 7 illustrates a computer network or similar digital processing environment in which the present invention may be implemented.
- Client computer(s)/devices 50 and server computer(s) 60 provide processing, storage, and input/output devices executing application programs and the like.
- Client computer(s)/devices 50 can also be linked through communications network 70 to other computing devices, including other client devices/processes 50 and server computer(s) 60 .
- Communications network 70 can be part of a remote access network, a global network (e.g., the Internet), a worldwide collection of computers, Local area or Wide area networks, and gateways that currently use respective protocols (TCP/IP, Bluetooth, etc.) to communicate with one another.
- Other electronic device/computer network architectures are suitable.
- FIG. 8 is a diagram of the internal structure of a computer (e.g., client processor/device 50 or server computers 60 ) in the computer system of FIG. 7 .
- Each computer 50 , 60 contains system bus 79 , where a bus is a set of hardware lines used for data transfer among the components of a computer or processing system.
- Bus 79 is essentially a shared conduit that connects different elements of a computer system (e.g., processor, disk storage, memory, input/output ports, network ports, etc.) that enables the transfer of information between the elements.
- Attached to system bus 79 is I/O device interface 82 for connecting various input and output devices (e.g., keyboard, mouse, displays, printers, speakers, etc.) to the computer 50 , 60 .
- Network interface 86 allows the computer to connect to various other devices attached to a network (e.g., network 70 of FIG. 7 ).
- Memory 90 provides volatile storage for computer software instructions 92 and data 94 used to implement an embodiment of the present invention (e.g., routine/method 15 described and exemplified in FIGS. 5 and 6 above and further outlined in FIG. 9 below).
- Disk storage 95 provides non-volatile storage for computer software instructions 92 and data 94 used to implement an embodiment of the present invention.
- Central processor unit 84 is also attached to system bus 79 and provides for the execution of computer instructions.
- the processor routines 92 and data 94 are a computer program product (generally referenced 92 ), including a computer readable medium (e.g., a removable storage medium such as one or more DVD-ROM's, CD-ROM's, diskettes, tapes, etc.) that provides at least a portion of the software instructions for the invention system.
- Computer program product 92 can be installed by any suitable software installation procedure, as is well known in the art.
- at least a portion of the software instructions may also be downloaded over a cable, communication and/or wireless connection.
- the invention programs are a computer program propagated signal product 107 embodied on a propagated signal on a propagation medium (e.g., a radio wave, an infrared wave, a laser wave, a sound wave, or an electrical wave propagated over a global network such as the Internet, or other network(s)).
- a propagation medium e.g., a radio wave, an infrared wave, a laser wave, a sound wave, or an electrical wave propagated over a global network such as the Internet, or other network(s).
- Such carrier medium or signals provide at least a portion of the software instructions for the present invention routines/program 92 .
- the propagated signal is an analog carrier wave or digital signal carried on the propagated medium.
- the propagated signal may be a digitized signal propagated over a global network (e.g., the Internet), a telecommunications network, or other network.
- the propagated signal is a signal that is transmitted over the propagation medium over a period of time, such as the instructions for a software application sent in packets over a network over a period of milliseconds, seconds, minutes, or longer.
- the computer readable medium of computer program product 92 is a propagation medium that the computer system 50 may receive and read, such as by receiving the propagation medium and identifying a propagated signal embodied in the propagation medium, as described above for computer program propagated signal product.
- carrier medium or transient carrier encompasses the foregoing transient signals, propagated signals, propagated medium, storage medium and the like.
- FIG. 9 is a flow diagram that further outlines the present invention process/methods 15 .
- the present invention 15 hides the process context 36 in private state 45 of combined structure 43 .
- the process state is defined by d-ops which points to a dentry operations vector 41 inside a private structure 43 (step 103 ) of a respective alias dentry 35 .
- step 105 the invention system 15 replaces root inode operations vector 40 with a new inode operations vector 49 .
- Step 105 /system 15 also saves the original vector pointer 51 .
- step 107 all lookups are from root inode 37 . That is, if the process root dentry is subject root dentry 21 , then in step 108 the operating system kernel calls the inode's lookup method passing the directory inode and the name of a prospective new dentry 23 . If the process root dentry is an alias dentry 35 , then in step 109 the operating system kernel calls the inode lookup method with the directory inode and dentry 53 .
- step 110 checks the parent dentry of the passed dentry 23 , 53 . If the parent dentry is not one of the alias dentries 35 , then step 111 calls the subject lookup method (found via pointer 51 and inode operations 40 ) and returns results (i.e., dentries 23 in the filesystem tree 19 ).
- step 112 follows the respective structure 43 of the alias dentry 35 to obtain real root dentry 21 .
- step 112 calls the lookup_hash function of the operating system kernel's dcache to lookup the name listed in alias dentry 53 as a child of the original root dentry 21 . If the cache misses (i.e., finds no entry for the name in the hash table), then step 112 calls back to step 108 . This time the real root dentry 21 is passed as a parameter instead of the alias dentry 35 .
- steps 110 and 111 proceed as described above and return results of the root inode's 37 lookup routine.
- step 112 ultimately returns lookup results (dentries 23 ) in terms of real dentry tree at roots 21 , 29 of filesystem 19 .
- the present invention is a technique to keep using the existing filesystem 19 but enables hanging some additional state information (at 43 for example) necessary for process context.
- the present invention makes processes use the original virtual filesystem and original inodes/dentries to get the behavior desired, whereas techniques and methods in the prior art hide the original virtual filesystem and its data structures from processes.
- the present invention deals with in-memory virtual filesystem data structures and per process state.
- the present invention deals with virtual filesystem data for the root file system of a system image, not data storage volumes.
- the present invention does not directly layer multiple filesystem objects, but rather it modifies an existing file system's in-memory structures to provide a mechanism for private per process state while reusing all the same filesystem objects of the original filesystem and sharing them between all processes.
- the invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements.
- the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc.
- the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system.
- a computer-usable or computer readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
- the medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium.
- Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk.
- Current examples of optical disks include compact disk—read only memory (CD-ROM), compact disk—read/write (CD-R/W) and DVD.
- a data processing system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus.
- the memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.
- I/O devices including but not limited to keyboards, displays, pointing devices, etc.
- I/O controllers can be coupled to the system either directly or through intervening I/O controllers.
- Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks.
- Modems, cable modem and Ethernet cards are just a few of the currently available types of network adapters.
Abstract
Description
- Generally speaking, in the computer arts, a file system is the mechanism that defines the storage, hierarchical organization, access and operations for retrieval and manipulation of data on a storage device or medium (e.g., a hard disk or a CD-ROM). Computer systems using UNIX or Linux operating systems require a file system called the “root filesystem”. The root filesystem includes programs and information to start up and manage the subject computer system. The root filesystem is formed of a hierarchical tree of directories 91 and
files 89 where theroot 93 of this tree is referred to as “root” and denoted by “/”.FIG. 1 shows a typical UNIXroot filesystem 87. - In UNIX and Linux terminology there are several file types, namely, “regular”, “directory”, “symbolic link”, “block and character oriented device file” and “special”. A “regular” file, commonly called “file” is a named container of information stored in a directory. A “directory” file is a container of directory entries, for each file in the subject directory. Each directory entry includes a name and a set of attributes that point to a file (for example its inode, see below). A “symbolic link” is a file containing a pointer to a different file which can be used through the symbolic link. This file type serves to overcome the limitations of hard links which are discussed later. A “Block and character oriented device file” is not a container of sorts but rather an interface to an I/O device that can be accessed directly through the file. “Special” files (pipes and sockets) are files used for interprocess communication and networking.
- As mentioned above, directories are files that contain directory entries that point to an inode. As a consequence, one file on a disk may be pointed to by different directory entries. It is said that this file has different hard links. In order to maintain multiple hard links, for each inode there is a link counter. The link counter is decremented each time a hard link is deleted and incremented when a hard link is created. Only when the link counter reaches zero are actual data blocks on disk released.
- Hard links are subject to some restrictions. First, users are not allowed to create hard links to directories. Secondly, users are not allowed to create hard links that cross filesystems. This is because in the directory entry the inode number is used as a pointer to the inode, and inode numbers are only unique within one filesystem.
- In many cases, access to a certain filesystem located on a device different from the device containing the root filesystem may be required. This separate location may be a different partition on the same hard drive, a CD in a CD-ROM drive or a network filesystem. In order to access the filesystem, the operating system needs to be told to take the filesystem and let it appear under a directory of the root filesystem. That directory serves as the so called
mount point 95. This process is called mounting a filesystem.FIG. 2 shows theroot filesystem 93 fromFIG. 1 after a CD-ROM (separate filesystem 77) has been mounted to the mount point labeled /mnt/cdrom 95. As long as the CD-ROM 77 is mounted, the information stored on it will be available there and accessible through mnt/cdrom. - A “virtual filesystem”, also called VFS or Virtual Filesystem Switch is a software layer handling the generic tasks involved in the use of a filesystem. These generic tasks include error checking, caching VFS objects, doing the required locking and communicating with user space. Once the generic tasks are completed, the VFS passes the operation on to the specific layer, where it may be completed or again passed on to a next lower layer.
FIG. 3 shows the relation between thegeneric VFS layer 71 and aspecific filesystem layer 73. - To achieve this strict separation, the so called “common file model” was introduced. This object oriented model defines operations and objects which are common to all file systems. The following objects are defined in the common file model:
- (1) The superblock object: this object holds all data relevant to a mounted
filesystem 77. Disk-based filesystems usually store a copy of this object on disk. - (2) The inode object: this object stores information on a file located within a filesystem, such as size, permissions or access time. Most important, it holds the inode number which is used to uniquely identify a file within a filesystem. Disk-based filesystems usually store a copy of this object.
- (3) The file object: this object is used to store information regarding an open file. It holds information on the file and the processes using it. This object exists only in memory.
- (4) The dentry object: this object represents a link from a directory entry to an inode. This is necessary because one file can be represented by several hard links. The VFS 71 caches the dentry objects in order to speed up lookup operations.
- Each of these objects has a set of operations associated with it which can be defined by a
specific filesystem 73. These operations are implemented as a set of function pointers which are used by the VFS 71 to call the appropriate function of thespecific filesystem 73. Thus, the separation of generic and specific layers shown inFIG. 3 is achieved where the VFS 71 is able to call the appropriate function of aspecific filesystem 73 without having to know any specific detail on how the data is stored in thatfilesystem 73. - As can be seen from the above, filesystems are mainly implemented in kernel space where debugging is difficult and small bugs may crash a whole computer system. Also filesystems tend to consist of large amounts of code that, due to the nature of operating system kernels, is fairly complex. Therefore, changing and extending existing functionality is difficult.
- Stackable or stacking filesystems provide a solution to some of these problems. Instead of modifying an existing filesystem, a new filesystem layer is stacked on top of the existing one. This new layer adds the required functionality in a modular way and therefore can be developed, tested and maintained separately.
FIG. 4 shows the relationship between the VFS 71, astackable filesystem 75 and the lower (specific)filesystem 73. - The VFS
layer 71 that handles the generic actions involved in afilesystem 73 operation remains at the top of this hierarchy. When these actions have been completed, the subject function is called for the next lower level. The VFS 71 as a generic layer does not need to know what type of filesystem the lower layer is and will simply call the appropriate function via the VFS-object function pointers. This enables a new layer to be introduced, the new layer being thestackable filesystem layer 75. Thestackable filesystem 75 is mounted on top of a mounted filesystem and accessed through the new mount point. - Further, the new
stackable filesystem layer 75 has to behave differently from traditional filesystems. Aslower layers 73 do not have any knowledge about their caller, thestackable layer 75 needs to present itself in two different manners: to the lower level as the VFS and to the higher as a traditional filesystem. When theVFS 71 calls a function of thestackable layer 75, generic tasks are first performed as done previously by theVFS 71 but for thestackable filesystem 75. Next the stackablefile system layer 75 invokes zero or more functions (as object methods) on thelayer 73 beneath it. When the call returns to thestackable filesystem layer 75, the result is handled accordingly and then returned to theVFS 71. - Thus, many applications and services employ the use of stacking filesystems because that allows the application or service to intercept filesystem operations and perform their own processing without any modification of the logic of the caller of the filesystem services. However, there are some particular challenges involved in implementing stacking filesystems for Linux systems. Linux kernels do not have a UNIX System V release 4 (SVR4)-style vnode interface. Instead Linux kernels have a different interface spread among several distinct object types and operation vectors. Examples include: inodes (struct inode and inode_operations), directory cache entries (dentries or dcache entries, struct dentry), open-file objects (struct file and file_operations); address space objects (address_space_operations) and super blocks (struct super_block and super_operations). Many operations map straightforwardly between the various Linux kernel operations and either SVR4-style vnode object methods (e.g., VOP_*( ) calls) or file system object methods (e.g., VFS_*( ) calls). The biggest difference that affects stacking filesystems is the way pathnames and lookups are handled.
- To create a per-process private state, a stacking file system can establish a per-process root context for file operations. On an SVR4 system this can be done by issuing a hidden chroot to a special vnode in the stacking file system. This special vnode then serves as the starting point for pathnames beginning with “/”. VOP_LOOKUP( ) invoked on this vnode may return vnode objects from the original root file system, e.g. looking up “etc” returns the original root file system's vnode representing “/etc”. As lookups continue down the name tree and encounter another mounted file system instance from the stacking file system, the context can be found from the process's root directory vnode. The stacking file system then returns results consistent with its design.
- A similar technique can be used with a Linux kernel but because of the difference in how pathnames and lookups are handled, various problems are encountered, particularly at the root of the file name space.
- The Linux kernel requires file systems to use the directory name cache (dentry) structures instead of vnodes for many of its file operations. Most of the Linux kernel's namespace-related file operations operate on dentries. Many other kernel operations use dentries to hold references to files (most notably the current directory and process root directory). Each separately-mounted file system has a separate dentry tree. Within each mounted file system, these structures are linked in a hierarchical tree structure reflecting the namespace of the file system. The root of the tree is the root of the file system's name space. When a mount-point is encountered, the mounted-over dentry and the mounted-over file system structure (vfsmnt) are used as hash keys to find the new file system's root dentry and file system structure.
- If the previous method from SVR4 is adapted to Linux, several of the namespace-modification operations fail in the root directory (e.g., link, unlink, rename). These operations require that the parent directory and object dentries be parent and child in the dentry cache hierarchy. If one uses the same method as above, the dentry for “/” will not be the parent of the dentry for “/etc”, because the “/etc” dentry is from the real file system while the dentry for “/” is from the stacking file system.
- To address this failure, a Linux-specific method has been tried, but it too fails to work properly. This method shadows dentries for all files in the root file system. In this method, lookups of “etc” in “/” result in a dentry from the stacking file system. The stacking file system must simulate behavior of the real “/etc” object by passing on any requests of this virtual dentry to the real file system's dentry. However, certain requests cannot be passed on correctly, such as mount point crossings: the dentries provided by the stacking file system do not match the real ones, so the hash table lookups for dentries when crossing mount points does not work. The stacking file system thus must shadow all dentries in all mounted file systems. This causes a myriad of other problems, such as incorrect results from disk-space statistics queries (e.g. df -k) and improper behavior for socket files.
- The present invention addresses the problems of the prior art. In particular, the present invention utilizes directory names in the namespace of a subject filesystem without interference from the virtual directory names of the stacking filesystem.
- In a preferred embodiment, a computer method and apparatus handle directory names as follows. Given a computer system, there is a subject filesystem and a corresponding stacking filesystem. The present invention method and apparatus obtain directory trees of the subject filesystem. Each directory tree has a root directory entry and plural directory entries linked together in a hierarchical manner. Each directory entry has a respective directory name. For each directory entry, there is a respective filesystem object representing the directory entry. The file system objects in the stacking filesystem have respective virtual directory names. The invention uses the directory trees of the subject filesystem to process operations such that operations are processed using directory names in a name space of the subject filesystem free of interference from the virtual directory name of the stacking filesystem.
- Preferrably, the present invention further employs one or more alias directory entries. Each alias directory entry has a respective support structure that defines a private state and that provides a pointer to a root directory entry of one of the directory trees of the subject filesystem. Further the invention method/system substitutes a new inode operations vector for an inode operations vector of the root directory entry.
- The foregoing and other objects, features and advantages of the invention will be apparent from the following more particular description of preferred embodiments of the invention, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the invention.
-
FIG. 1 is a schematic diagram of a typical UNIX root filesystem. -
FIG. 2 is a schematic diagram of the root filesystem ofFIG. 1 after mounting a CD (the mounted filesystem). -
FIG. 3 is a block diagram of a Virtual Filesystem Switch. -
FIG. 4 is a block diagram of a stacking filesystem. -
FIG. 5 is a schematic view of one embodiment of the present invention. -
FIG. 6 is a block diagram detailing handling of a dentry ofFIG. 5 . -
FIG. 7 is a schematic view of a computer network environment in which embodiments of the present invention may be deployed. -
FIG. 8 is a block diagram of one computer node in theFIG. 7 network environment. -
FIG. 9 is a flow diagram of software or method embodiments of the present invention as implemented inFIGS. 7 and 8 . - Illustrated in
FIG. 5 is asubject filesystem 19 such as in the Linux operating system of interest to the present invention. Thesubject filesystem 19 hasroot 21 anddentries 23 linked in a hierarchical tree structure. An example dentry is /etc 23 b which is further described inFIG. 6 (discussed below) demonstrating principles of the present invention. At 25 is a mount point for amounted file system 27.Mounted filesystem 27 has a separate dentry tree (illustrated at continuation A) formed of respective dentries, files,root 29 and the like. Whenmount point 25 is encountered, theroot 29 dentry of mountedfilesystem 27 is found by matching the mount-over dentry 25 (e.g., “dentry4”) and the mount-over file system 19 (e.g., terminal A) in a hash table. - Continuing with
FIG. 5 , given asubject filesystem 19, the present invention uses the system's dentry trees (e.g., fromroots filesystem 33. This allows thesubject filesystem 19 to process file operations on real objects without interference from the stackingfilesystem 33, resulting in more reliable and correct filesystem operations. A key consideration with this approach is to set up the process environment to have a reliable inheritance of the stacking filesystem's 33 root context to new processes and use the subject filesystem's 19 (vfsmnt, dentry) for most lookups. This is done by setting the process root to be -
- (/-vfsmnt,alias-dentry)
where /-vfsmnt refers to thesubject filesystem 19, and alias-dentry 35 is a special dentry that also points to the real root inode 37 (via the d_inode field) as illustrated inFIG. 6 .
- (/-vfsmnt,alias-dentry)
- To avoid any collision with the
real root filesystem 19 using private data pointers in theroot dentry 21, the present invention hides the context in thedentry operations vector 41. That is, in the present invention d_ops is made to point to a workingstructure 43 that contains not only thedentry operations vector 41′ but also a private state 45 (current stackingfilesystem context 36, a reference to the stacking filesystem's 33 mount point, and apointer 47 to thereal root 21 dentry). This would be sufficient except that any lookups in theVFS 39 dcache would have the parent link set to analias dentry 35, not thereal dentry 21, resulting in an isolated duplicate dentry tree in the stackingfilesystem 33. Any mountpoint crossings into thesubject filesystems dentry 25, would fail to find the target mounts because of the duplicate dentries. - So all the lookup results (dentries) need to be in the real dentry tree (at 19). To do this, the present invention replaces the
inode operations vector 40 in theroot inode 37 with arespective lookup vector 49, and saves theoriginal vector pointer 51. After substituting theinode operations vector 40, a lookup routine of the present invention is called for all lookups in/(e.g., real root 21), even for processes not using the stackingfilesystem 33. - The Linux kernel calls the inode's lookup method as such:
- lookup(struct :node *dir, struct dentry *dent)
- passing the directory inode and a prospective
new dentry 23 with the name filled in. There is no parent dentry passed directly but it can be found from dent->d_parent. Theinvention routine 15 checks this parent dentry field to see if it is analias dentry 35. If it is not one of thesubject aliases 35, then the routine 15 calls the real lookup method via savedpointer 51 and savedoriginal operations 40, and returns its results (as described inFIG. 4 ). - If the parent dentry is a
subject alias 35, the invention method andapparatus 15 unwraps to the real root dentry 21 (from the alias dentry'sextended operation vector 41′ instructure 43 and pointer 47), then calls back into the Linux kernel's dcache (via the lookup_hash( ) function) to look up the prospectivenew dentry 23 name as a child of theoriginal root 21 directory entry. If the cache misses, theroot inodes 37 lookup ( ) routine as substituted by the present invention lookup method at 49 is called again, this time passing a newprospective dentry 13 whose parent is the subject file system'sdentry 21. In response, the lookup method behaves as above returning the real inode routine's 40 results. - With this scheme, all lookups in the stacking
filesystem context 36 use the real dentry trees (atroots 21 and 29) for theroot file system 19, and mountpoint 25 crossings into the stackingfilesystem 33 work correctly (i.e., mismatch free). Operations in the root directory/21 work normally too, because by the time any syscall has gathered its inputs, the system has them asreal inodes dentries 23 in the regular tree, not linked to thealias dentry 35. - In the example dentry /etc 23 b,
FIG. 6 shows thecorresponding dentry object 23 b and associated inode object 38 (holding /etc's unique inode number in filesystem 19) used by theVFS 39 and stackingfilesystem 33 methods. In the stackingfilesystem 33 name space, /etc′ 13 is used and a call to the inode lookup method is -
- Lookup (rootino, etc′—dentry)
Thesystem 15 responds to such a call by determining thatreal root dentry 21 is the parent dentry of /etc′ 13. In turn, the routine 15 calls lookup_hash ( ) to find the result. If the cache misses the name, the system further calls root inode's 37 lookup which invokesinode operations vector 40 and returns the link fromdirectory entry 23 b insubject filesystem 19 to the correspondinginode 38.
- Lookup (rootino, etc′—dentry)
- For
filesystem 19 objects not contained in stackingfilesystem 33, the present invention uses /etc″ 53 and sets the process root toalias dentry 35. A call to the inode lookup method is then -
- Lookup (rootino, etc″—dentry)
Thesystem 15 responds to this call by determining that the parent dentry to /etc″ 53 isalias dentry 35. In turn, the present invention follows the respective state anddentry operations structure 41 ofalias dentry 35. This results in resolving to root dentry 21 (viapointer 47 from structure 43) and calling theroot inodes 37 lookup. Theroot inode 37 lookup uses thenew inode operations 49 which supplant theold inode operations 40. In this root inodes 37 lookup, the system is looking for the name “etc” as a child of theoriginal root 21 directory entry. In particular, a lookup hash function is applied to the operating systems's dcache. If the cache misses, then theroot inode 37 calls its lookup routine again but as - Lookup (rootino, etc′—dentry)
where dentry 13 is passed as a parameter.
- Lookup (rootino, etc″—dentry)
- In response, the
root inode 37lookup routine 49 determines the parent of the dentry parameter is thereal root dentry 21. Next the routine 15 invokes oldinode operations vector 40 and returns the respective /etc dentry 23 b (i.e., the link fromdirectory entry 23 b to the corresponding inode 38) as described above. - Turning now to
FIGS. 7 and 8 ,FIG. 7 illustrates a computer network or similar digital processing environment in which the present invention may be implemented. - Client computer(s)/
devices 50 and server computer(s) 60 provide processing, storage, and input/output devices executing application programs and the like. Client computer(s)/devices 50 can also be linked throughcommunications network 70 to other computing devices, including other client devices/processes 50 and server computer(s) 60.Communications network 70 can be part of a remote access network, a global network (e.g., the Internet), a worldwide collection of computers, Local area or Wide area networks, and gateways that currently use respective protocols (TCP/IP, Bluetooth, etc.) to communicate with one another. Other electronic device/computer network architectures are suitable. -
FIG. 8 is a diagram of the internal structure of a computer (e.g., client processor/device 50 or server computers 60) in the computer system ofFIG. 7 . Eachcomputer O device interface 82 for connecting various input and output devices (e.g., keyboard, mouse, displays, printers, speakers, etc.) to thecomputer Network interface 86 allows the computer to connect to various other devices attached to a network (e.g.,network 70 ofFIG. 7 ).Memory 90 provides volatile storage forcomputer software instructions 92 anddata 94 used to implement an embodiment of the present invention (e.g., routine/method 15 described and exemplified inFIGS. 5 and 6 above and further outlined inFIG. 9 below).Disk storage 95 provides non-volatile storage forcomputer software instructions 92 anddata 94 used to implement an embodiment of the present invention.Central processor unit 84 is also attached to system bus 79 and provides for the execution of computer instructions. - In one embodiment, the
processor routines 92 anddata 94 are a computer program product (generally referenced 92), including a computer readable medium (e.g., a removable storage medium such as one or more DVD-ROM's, CD-ROM's, diskettes, tapes, etc.) that provides at least a portion of the software instructions for the invention system.Computer program product 92 can be installed by any suitable software installation procedure, as is well known in the art. In another embodiment, at least a portion of the software instructions may also be downloaded over a cable, communication and/or wireless connection. In other embodiments, the invention programs are a computer program propagatedsignal product 107 embodied on a propagated signal on a propagation medium (e.g., a radio wave, an infrared wave, a laser wave, a sound wave, or an electrical wave propagated over a global network such as the Internet, or other network(s)). Such carrier medium or signals provide at least a portion of the software instructions for the present invention routines/program 92. - In alternate embodiments, the propagated signal is an analog carrier wave or digital signal carried on the propagated medium. For example, the propagated signal may be a digitized signal propagated over a global network (e.g., the Internet), a telecommunications network, or other network. In one embodiment, the propagated signal is a signal that is transmitted over the propagation medium over a period of time, such as the instructions for a software application sent in packets over a network over a period of milliseconds, seconds, minutes, or longer. In another embodiment, the computer readable medium of
computer program product 92 is a propagation medium that thecomputer system 50 may receive and read, such as by receiving the propagation medium and identifying a propagated signal embodied in the propagation medium, as described above for computer program propagated signal product. - Generally speaking, the term “carrier medium” or transient carrier encompasses the foregoing transient signals, propagated signals, propagated medium, storage medium and the like.
-
FIG. 9 is a flow diagram that further outlines the present invention process/methods 15. Ininitial step 101, thepresent invention 15 hides theprocess context 36 inprivate state 45 of combinedstructure 43. Then on a per process basis, the process state is defined by d-ops which points to adentry operations vector 41 inside a private structure 43 (step 103) of arespective alias dentry 35. - In
step 105, theinvention system 15 replaces rootinode operations vector 40 with a newinode operations vector 49. Step 105/system 15 also saves theoriginal vector pointer 51. - In
step 107, all lookups are fromroot inode 37. That is, if the process root dentry issubject root dentry 21, then instep 108 the operating system kernel calls the inode's lookup method passing the directory inode and the name of a prospectivenew dentry 23. If the process root dentry is analias dentry 35, then instep 109 the operating system kernel calls the inode lookup method with the directory inode anddentry 53. - Following either step 108 or 109, step 110 checks the parent dentry of the passed
dentry alias dentries 35, then step 111 calls the subject lookup method (found viapointer 51 and inode operations 40) and returns results (i.e., dentries 23 in the filesystem tree 19). - If the parent dentry is one of the
alias dentries 35 ofstep 103, then step 112 follows therespective structure 43 of thealias dentry 35 to obtainreal root dentry 21.Next step 112 calls the lookup_hash function of the operating system kernel's dcache to lookup the name listed inalias dentry 53 as a child of theoriginal root dentry 21. If the cache misses (i.e., finds no entry for the name in the hash table), then step 112 calls back tostep 108. This time thereal root dentry 21 is passed as a parameter instead of thealias dentry 35. In turn, steps 110 and 111 proceed as described above and return results of the root inode's 37 lookup routine. Thus step 112 ultimately returns lookup results (dentries 23) in terms of real dentry tree atroots filesystem 19. - As described above, the present invention is a technique to keep using the existing
filesystem 19 but enables hanging some additional state information (at 43 for example) necessary for process context. In a preferred embodiment, the present invention makes processes use the original virtual filesystem and original inodes/dentries to get the behavior desired, whereas techniques and methods in the prior art hide the original virtual filesystem and its data structures from processes. - In particular, the present invention deals with in-memory virtual filesystem data structures and per process state.
- Further the present invention deals with virtual filesystem data for the root file system of a system image, not data storage volumes.
- The present invention does not directly layer multiple filesystem objects, but rather it modifies an existing file system's in-memory structures to provide a mechanism for private per process state while reusing all the same filesystem objects of the original filesystem and sharing them between all processes.
- While this invention has been particularly shown and described with references to preferred embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope of the invention encompassed by the appended claims.
- For example, the invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In a preferred embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc.
- Furthermore, the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
- The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk—read only memory (CD-ROM), compact disk—read/write (CD-R/W) and DVD.
- A data processing system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus. The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.
- Input/output or I/O devices (including but not limited to keyboards, displays, pointing devices, etc.) can be coupled to the system either directly or through intervening I/O controllers.
- Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modem and Ethernet cards are just a few of the currently available types of network adapters.
Claims (20)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/254,987 US7860908B2 (en) | 2005-10-20 | 2005-10-20 | Computer method for handling private process state in a stacking file system |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/254,987 US7860908B2 (en) | 2005-10-20 | 2005-10-20 | Computer method for handling private process state in a stacking file system |
Publications (2)
Publication Number | Publication Date |
---|---|
US20070100855A1 true US20070100855A1 (en) | 2007-05-03 |
US7860908B2 US7860908B2 (en) | 2010-12-28 |
Family
ID=37997807
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/254,987 Expired - Fee Related US7860908B2 (en) | 2005-10-20 | 2005-10-20 | Computer method for handling private process state in a stacking file system |
Country Status (1)
Country | Link |
---|---|
US (1) | US7860908B2 (en) |
Cited By (28)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100174752A1 (en) * | 2009-01-06 | 2010-07-08 | International Business Machines Corporation | Validation and correction in a distributed namespace |
US20150310034A1 (en) * | 2014-04-23 | 2015-10-29 | Qumulo, Inc. | Filesystem hierarchical aggregate metrics |
US10318401B2 (en) | 2017-04-20 | 2019-06-11 | Qumulo, Inc. | Triggering the increased collection and distribution of monitoring information in a distributed processing system |
US20200139471A1 (en) * | 2018-11-02 | 2020-05-07 | Illinois Tool Works Inc. | Systems and methods to design part weld processes using media libraries |
US10860372B1 (en) | 2020-01-24 | 2020-12-08 | Qumulo, Inc. | Managing throughput fairness and quality of service in file systems |
US10877942B2 (en) | 2015-06-17 | 2020-12-29 | Qumulo, Inc. | Filesystem capacity and performance metrics and visualizations |
US10936551B1 (en) | 2020-03-30 | 2021-03-02 | Qumulo, Inc. | Aggregating alternate data stream metrics for file systems |
US10936538B1 (en) | 2020-03-30 | 2021-03-02 | Qumulo, Inc. | Fair sampling of alternate data stream metrics for file systems |
US11132126B1 (en) | 2021-03-16 | 2021-09-28 | Qumulo, Inc. | Backup services for distributed file systems in cloud computing environments |
US11132336B2 (en) | 2015-01-12 | 2021-09-28 | Qumulo, Inc. | Filesystem hierarchical capacity quantity and aggregate metrics |
US11151001B2 (en) | 2020-01-28 | 2021-10-19 | Qumulo, Inc. | Recovery checkpoints for distributed file systems |
US11151092B2 (en) | 2019-01-30 | 2021-10-19 | Qumulo, Inc. | Data replication in distributed file systems |
US11157458B1 (en) | 2021-01-28 | 2021-10-26 | Qumulo, Inc. | Replicating files in distributed file systems using object-based data storage |
US11256682B2 (en) | 2016-12-09 | 2022-02-22 | Qumulo, Inc. | Managing storage quotas in a shared storage system |
US11294604B1 (en) | 2021-10-22 | 2022-04-05 | Qumulo, Inc. | Serverless disk drives based on cloud storage |
US11347699B2 (en) | 2018-12-20 | 2022-05-31 | Qumulo, Inc. | File system cache tiers |
US11354273B1 (en) | 2021-11-18 | 2022-06-07 | Qumulo, Inc. | Managing usable storage space in distributed file systems |
US11360936B2 (en) | 2018-06-08 | 2022-06-14 | Qumulo, Inc. | Managing per object snapshot coverage in filesystems |
US11461241B2 (en) | 2021-03-03 | 2022-10-04 | Qumulo, Inc. | Storage tier management for file systems |
US11567660B2 (en) | 2021-03-16 | 2023-01-31 | Qumulo, Inc. | Managing cloud storage for distributed file systems |
US11599508B1 (en) | 2022-01-31 | 2023-03-07 | Qumulo, Inc. | Integrating distributed file systems with object stores |
US11669255B2 (en) | 2021-06-30 | 2023-06-06 | Qumulo, Inc. | Distributed resource caching by reallocation of storage caching using tokens and agents with non-depleted cache allocations |
US11722150B1 (en) | 2022-09-28 | 2023-08-08 | Qumulo, Inc. | Error resistant write-ahead log |
US11729269B1 (en) | 2022-10-26 | 2023-08-15 | Qumulo, Inc. | Bandwidth management in distributed file systems |
US11734147B2 (en) | 2020-01-24 | 2023-08-22 | Qumulo Inc. | Predictive performance analysis for file systems |
US11775481B2 (en) | 2020-09-30 | 2023-10-03 | Qumulo, Inc. | User interfaces for managing distributed file systems |
US11921677B1 (en) | 2023-11-07 | 2024-03-05 | Qumulo, Inc. | Sharing namespaces across file system clusters |
US11934660B1 (en) | 2023-11-07 | 2024-03-19 | Qumulo, Inc. | Tiered data storage with ephemeral and persistent tiers |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103209127B (en) * | 2012-01-17 | 2016-01-20 | 迈普通信技术股份有限公司 | Virtual flow-line retransmission method and device is realized based on linux system |
KR101977575B1 (en) * | 2012-09-28 | 2019-05-13 | 삼성전자 주식회사 | Apparatus and method for directory entry look up, and recording medium recording the directory entry look up program thereof |
CN104866778A (en) * | 2015-01-30 | 2015-08-26 | 武汉华工安鼎信息技术有限责任公司 | Document safety access control method and device based on Linux kernel |
US9996541B2 (en) | 2016-02-10 | 2018-06-12 | Red Hat, Inc. | Hash-based mount point lookup in virtual file systems |
Citations (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5093779A (en) * | 1987-07-03 | 1992-03-03 | Hitachi, Ltd. | Computer file system |
US5561799A (en) * | 1993-06-17 | 1996-10-01 | Sun Microsystems, Inc. | Extensible file system which layers a new file system with an old file system to provide coherent file data |
US5870734A (en) * | 1994-10-04 | 1999-02-09 | Hewlett-Packard Company | Three-dimensional file system using a virtual node architecture |
US6256031B1 (en) * | 1998-06-26 | 2001-07-03 | Microsoft Corporation | Integration of physical and virtual namespace |
US6697795B2 (en) * | 2001-06-04 | 2004-02-24 | Hewlett-Packard Development Company, L.P. | Virtual file system for dynamically-generated web pages |
US6775679B2 (en) * | 2001-03-20 | 2004-08-10 | Emc Corporation | Building a meta file system from file system cells |
US20050273858A1 (en) * | 2004-06-07 | 2005-12-08 | Erez Zadok | Stackable file systems and methods thereof |
US20050278383A1 (en) * | 2004-05-28 | 2005-12-15 | Network Appliance, Inc. | Method and apparatus for keeping a file system client in a read-only name space of the file system |
US7315860B1 (en) * | 1994-09-01 | 2008-01-01 | Computer Associates Think, Inc. | Directory service system and method with tolerance for data entry storage and output |
US7610329B2 (en) * | 2002-07-30 | 2009-10-27 | Storediq, Inc. | Method and apparatus for managing file systems and file-based data storage |
-
2005
- 2005-10-20 US US11/254,987 patent/US7860908B2/en not_active Expired - Fee Related
Patent Citations (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5093779A (en) * | 1987-07-03 | 1992-03-03 | Hitachi, Ltd. | Computer file system |
US5561799A (en) * | 1993-06-17 | 1996-10-01 | Sun Microsystems, Inc. | Extensible file system which layers a new file system with an old file system to provide coherent file data |
US7315860B1 (en) * | 1994-09-01 | 2008-01-01 | Computer Associates Think, Inc. | Directory service system and method with tolerance for data entry storage and output |
US5870734A (en) * | 1994-10-04 | 1999-02-09 | Hewlett-Packard Company | Three-dimensional file system using a virtual node architecture |
US6256031B1 (en) * | 1998-06-26 | 2001-07-03 | Microsoft Corporation | Integration of physical and virtual namespace |
US6775679B2 (en) * | 2001-03-20 | 2004-08-10 | Emc Corporation | Building a meta file system from file system cells |
US6697795B2 (en) * | 2001-06-04 | 2004-02-24 | Hewlett-Packard Development Company, L.P. | Virtual file system for dynamically-generated web pages |
US7610329B2 (en) * | 2002-07-30 | 2009-10-27 | Storediq, Inc. | Method and apparatus for managing file systems and file-based data storage |
US20050278383A1 (en) * | 2004-05-28 | 2005-12-15 | Network Appliance, Inc. | Method and apparatus for keeping a file system client in a read-only name space of the file system |
US20050273858A1 (en) * | 2004-06-07 | 2005-12-08 | Erez Zadok | Stackable file systems and methods thereof |
Cited By (39)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100174752A1 (en) * | 2009-01-06 | 2010-07-08 | International Business Machines Corporation | Validation and correction in a distributed namespace |
US8195704B2 (en) * | 2009-01-06 | 2012-06-05 | International Business Machines Corporation | Validation and correction in a distributed namespace |
US11461286B2 (en) | 2014-04-23 | 2022-10-04 | Qumulo, Inc. | Fair sampling in a hierarchical filesystem |
US20150310034A1 (en) * | 2014-04-23 | 2015-10-29 | Qumulo, Inc. | Filesystem hierarchical aggregate metrics |
US10459892B2 (en) * | 2014-04-23 | 2019-10-29 | Qumulo, Inc. | Filesystem hierarchical aggregate metrics |
US10095708B2 (en) | 2014-04-23 | 2018-10-09 | Qumulo, Inc. | Data mobility, accessibility, and consistency in a data storage system |
US10860547B2 (en) | 2014-04-23 | 2020-12-08 | Qumulo, Inc. | Data mobility, accessibility, and consistency in a data storage system |
US11132336B2 (en) | 2015-01-12 | 2021-09-28 | Qumulo, Inc. | Filesystem hierarchical capacity quantity and aggregate metrics |
US10877942B2 (en) | 2015-06-17 | 2020-12-29 | Qumulo, Inc. | Filesystem capacity and performance metrics and visualizations |
US11256682B2 (en) | 2016-12-09 | 2022-02-22 | Qumulo, Inc. | Managing storage quotas in a shared storage system |
US10678671B2 (en) | 2017-04-20 | 2020-06-09 | Qumulo, Inc. | Triggering the increased collection and distribution of monitoring information in a distributed processing system |
US10318401B2 (en) | 2017-04-20 | 2019-06-11 | Qumulo, Inc. | Triggering the increased collection and distribution of monitoring information in a distributed processing system |
US11360936B2 (en) | 2018-06-08 | 2022-06-14 | Qumulo, Inc. | Managing per object snapshot coverage in filesystems |
US11648621B2 (en) * | 2018-11-02 | 2023-05-16 | Illinois Tool Works Inc. | Systems and methods to design part weld processes using media libraries |
US20200139471A1 (en) * | 2018-11-02 | 2020-05-07 | Illinois Tool Works Inc. | Systems and methods to design part weld processes using media libraries |
US11347699B2 (en) | 2018-12-20 | 2022-05-31 | Qumulo, Inc. | File system cache tiers |
US11151092B2 (en) | 2019-01-30 | 2021-10-19 | Qumulo, Inc. | Data replication in distributed file systems |
US10860372B1 (en) | 2020-01-24 | 2020-12-08 | Qumulo, Inc. | Managing throughput fairness and quality of service in file systems |
US11294718B2 (en) | 2020-01-24 | 2022-04-05 | Qumulo, Inc. | Managing throughput fairness and quality of service in file systems |
US11734147B2 (en) | 2020-01-24 | 2023-08-22 | Qumulo Inc. | Predictive performance analysis for file systems |
US11151001B2 (en) | 2020-01-28 | 2021-10-19 | Qumulo, Inc. | Recovery checkpoints for distributed file systems |
US11372735B2 (en) | 2020-01-28 | 2022-06-28 | Qumulo, Inc. | Recovery checkpoints for distributed file systems |
US10936538B1 (en) | 2020-03-30 | 2021-03-02 | Qumulo, Inc. | Fair sampling of alternate data stream metrics for file systems |
US10936551B1 (en) | 2020-03-30 | 2021-03-02 | Qumulo, Inc. | Aggregating alternate data stream metrics for file systems |
US11775481B2 (en) | 2020-09-30 | 2023-10-03 | Qumulo, Inc. | User interfaces for managing distributed file systems |
US11157458B1 (en) | 2021-01-28 | 2021-10-26 | Qumulo, Inc. | Replicating files in distributed file systems using object-based data storage |
US11372819B1 (en) | 2021-01-28 | 2022-06-28 | Qumulo, Inc. | Replicating files in distributed file systems using object-based data storage |
US11461241B2 (en) | 2021-03-03 | 2022-10-04 | Qumulo, Inc. | Storage tier management for file systems |
US11132126B1 (en) | 2021-03-16 | 2021-09-28 | Qumulo, Inc. | Backup services for distributed file systems in cloud computing environments |
US11567660B2 (en) | 2021-03-16 | 2023-01-31 | Qumulo, Inc. | Managing cloud storage for distributed file systems |
US11435901B1 (en) | 2021-03-16 | 2022-09-06 | Qumulo, Inc. | Backup services for distributed file systems in cloud computing environments |
US11669255B2 (en) | 2021-06-30 | 2023-06-06 | Qumulo, Inc. | Distributed resource caching by reallocation of storage caching using tokens and agents with non-depleted cache allocations |
US11294604B1 (en) | 2021-10-22 | 2022-04-05 | Qumulo, Inc. | Serverless disk drives based on cloud storage |
US11354273B1 (en) | 2021-11-18 | 2022-06-07 | Qumulo, Inc. | Managing usable storage space in distributed file systems |
US11599508B1 (en) | 2022-01-31 | 2023-03-07 | Qumulo, Inc. | Integrating distributed file systems with object stores |
US11722150B1 (en) | 2022-09-28 | 2023-08-08 | Qumulo, Inc. | Error resistant write-ahead log |
US11729269B1 (en) | 2022-10-26 | 2023-08-15 | Qumulo, Inc. | Bandwidth management in distributed file systems |
US11921677B1 (en) | 2023-11-07 | 2024-03-05 | Qumulo, Inc. | Sharing namespaces across file system clusters |
US11934660B1 (en) | 2023-11-07 | 2024-03-19 | Qumulo, Inc. | Tiered data storage with ephemeral and persistent tiers |
Also Published As
Publication number | Publication date |
---|---|
US7860908B2 (en) | 2010-12-28 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7860908B2 (en) | Computer method for handling private process state in a stacking file system | |
US11556367B2 (en) | Dynamic image composition for container deployment | |
US9087066B2 (en) | Virtual disk from network shares and file servers | |
US6321219B1 (en) | Dynamic symbolic links for computer file systems | |
US5603019A (en) | Takeover technique for networked virtual filesystems | |
US5692180A (en) | Object-oriented cell directory database for a distributed computing environment | |
US5689701A (en) | System and method for providing compatibility between distributed file system namespaces and operating system pathname syntax | |
US5617568A (en) | System and method for supporting file attributes on a distributed file system without native support therefor | |
US7930327B2 (en) | Method and apparatus for obtaining the absolute path name of an open file system object from its file descriptor | |
US7529778B1 (en) | System and method for providing access to consistent point-in-time file versions | |
JP2708331B2 (en) | File device and data file access method | |
KR101159378B1 (en) | System and method for storing and retrieving a field of a user defined type outside of a database store in which the type is defined | |
US8190570B2 (en) | Preserving virtual filesystem information across high availability takeover | |
US11836112B2 (en) | Path resolver for client access to distributed file systems | |
US9021309B2 (en) | Method and system for creating virtual editable data objects by using a read-only data set as baseline | |
JPH0713844A (en) | Method for corresponding of new file system to exiting file system and extensible file system | |
JPH11502963A (en) | Methods for managing globally distributed software components | |
JP2007503658A (en) | Virus detection and alerts in shared read-only file systems | |
WO2008055010A1 (en) | Reverse name mappings in restricted namespace environments | |
Pate | UNIX filesystems: evolution, design, and implementation | |
Kashyap et al. | File system extensibility and reliability using an in-kernel database | |
US20160147547A1 (en) | Metadata-based class loading using a content repository | |
US10606805B2 (en) | Object-level image query and retrieval | |
US20040133554A1 (en) | Efficient file interface and method for providing access to files using a JTRS SCA core framework | |
US20050138034A1 (en) | System and method for sharing resource properties in a multi-user environment |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:KOHL, JOHN T.;REEL/FRAME:016979/0339 Effective date: 20051012 |
|
REMI | Maintenance fee reminder mailed | ||
FPAY | Fee payment |
Year of fee payment: 4 |
|
SULP | Surcharge for late payment | ||
AS | Assignment |
Owner name: LINKEDIN CORPORATION, CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:INTERNATIONAL BUSINESS MACHINES CORPORATION;REEL/FRAME:035201/0479 Effective date: 20140331 |
|
FEPP | Fee payment procedure |
Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
LAPS | Lapse for failure to pay maintenance fees |
Free format text: PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
STCH | Information on status: patent discontinuation |
Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362 |
|
FP | Lapsed due to failure to pay maintenance fee |
Effective date: 20181228 |