US20160231952A1 - Filesystem management - Google Patents
Filesystem management Download PDFInfo
- Publication number
- US20160231952A1 US20160231952A1 US14/616,756 US201514616756A US2016231952A1 US 20160231952 A1 US20160231952 A1 US 20160231952A1 US 201514616756 A US201514616756 A US 201514616756A US 2016231952 A1 US2016231952 A1 US 2016231952A1
- Authority
- US
- United States
- Prior art keywords
- filesystem
- client
- object list
- storage system
- request
- 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
- 238000000034 method Methods 0.000 claims abstract description 42
- 230000004044 response Effects 0.000 claims abstract description 24
- 230000008859 change Effects 0.000 claims description 8
- 238000012217 deletion Methods 0.000 claims description 4
- 230000037430 deletion Effects 0.000 claims description 4
- 238000004590 computer program Methods 0.000 description 7
- 241001475178 Dira Species 0.000 description 5
- 230000015654 memory Effects 0.000 description 5
- 230000004048 modification Effects 0.000 description 5
- 238000012986 modification Methods 0.000 description 5
- LXMSZDCAJNLERA-ZHYRCANASA-N spironolactone Chemical compound C([C@@H]1[C@]2(C)CC[C@@H]3[C@@]4(C)CCC(=O)C=C4C[C@H]([C@@H]13)SC(=O)C)C[C@@]21CCC(=O)O1 LXMSZDCAJNLERA-ZHYRCANASA-N 0.000 description 5
- 241000282326 Felis catus Species 0.000 description 3
- 230000008901 benefit Effects 0.000 description 3
- 230000006870 function Effects 0.000 description 3
- 230000002457 bidirectional effect Effects 0.000 description 2
- 230000008520 organization Effects 0.000 description 2
- 230000008569 process Effects 0.000 description 2
- 230000026676 system process Effects 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 239000000872 buffer Substances 0.000 description 1
- 150000001875 compounds Chemical class 0.000 description 1
- 125000004122 cyclic group Chemical group 0.000 description 1
- 238000000354 decomposition reaction Methods 0.000 description 1
- 230000005294 ferromagnetic effect Effects 0.000 description 1
- 238000001914 filtration Methods 0.000 description 1
- 230000010365 information processing Effects 0.000 description 1
- 230000005291 magnetic effect Effects 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 230000005055 memory storage Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000012913 prioritisation Methods 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 238000009877 rendering Methods 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 230000002123 temporal effect Effects 0.000 description 1
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/13—File access structures, e.g. distributed indices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
- G06F3/0614—Improving the reliability of storage systems
- G06F3/0619—Improving the reliability of storage systems in relation to data integrity, e.g. data losses, bit errors
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
-
- 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/14—Details of searching files based on file metadata
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
- G06F3/0604—Improving or facilitating administration, e.g. storage management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0638—Organizing or formatting or addressing of data
- G06F3/0643—Management of files
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0646—Horizontal data movement in storage systems, i.e. moving data in between storage devices or systems
- G06F3/065—Replication mechanisms
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
- G06F3/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]
Definitions
- Filesystem and operating systems that interface with filesystems generally provide commands for searching and locating files within a tree of a filesystem according to specified criteria.
- search criteria include file name patterns, e.g. ‘xyz*” for searching files starting with xyz, a compound file name pattern, time constrains related to the modification time or access time of the file, size limits, ownership limitation, certain strings within the file content (‘grep’ command-line utility), directories or sub-trees to be searched in, and other criteria.
- the ‘find’ command is considered as a slow command, since it involves massive disk access for reading the relevant parts of the filesystem catalogue (directories and files' metadata).
- NAS Network-Attached Storage
- the latency imposed by the network makes it unreasonably to use the ‘find’ command.
- a method may include: maintaining, by a storage system, a filesystem data structure that may include filesystem pathnames metadata related to a filesystem that is stored in the storage system; receiving, from a client that is coupled to the storage system via a network, a request to obtain a client filesystem object list related to at least a certain portion of the filesystem; generating, in response to the request and in response to the filesystem data structure, the client filesystem object list, wherein the client filesystem object list may include at least one pathname of at least one filesystem object that belongs to the at least certain portion of the filesystem; and sending the client filesystem object list to the client.
- the filesystem pathnames metadata may include pathnames of filesystem objects that belong to the filesystem.
- the filesystem pathnames metadata may include pathname retrieval information that facilitates a retrieval of pathnames of filesystem objects that belong to the filesystem.
- the filesystem data structure further may include filesystem attribute metadata that differs from the filesystem pathnames metadata.
- the filesystem attribute metadata may include attributes of filesystem objects that belong to the filesystem.
- the attribute of a filesystem object of the filesystem objects that belongs to the filesystem may be a size of the filesystem object.
- an attribute of a filesystem object of the filesystem objects that belongs to the filesystem may be a timestamp related to an operation applied on the filesystem object.
- the filesystem attribute metadata may include attributes retrieval information that facilitates a retrieval of attributes of filesystem objects that belong to the filesystem.
- the generating of the client filesystem object list is responsive to client access permissions related to filesystem objects that belong to the at least certain portion of the filesystem.
- the request to obtain the client filesystem object list may include a predefined term that represents the client filesystem object list.
- the method may include storing, in a certain location in the filesystem, an executable file that once executed by the client causes the client to respond to the request to obtain the client filesystem object list related to the at least certain portion of the filesystem by generating the client filesystem object list.
- the maintaining may include updating in real time the filesystem data structure in response to any change in the filesystem that mandates a change in the content of the filesystem data structure.
- the maintaining may include updating in real time the filesystem data structure in response to an addition of any filesystem object to the filesystem, a deletion of any filesystem object of the filesystem, a renaming of any filesystem object of the filesystem and a moving of any file system object of the filesystem.
- the request may be a network-attached storage (NAS) storage read request.
- NAS network-attached storage
- a non-transitory computer readable medium may store instructions that once executed by a storage system cause the storage system to maintain a filesystem data structure that comprises filesystem pathnames metadata related to a filesystem that is stored in the storage system; receive, from a client that is coupled to the storage system via a network, a request to obtain a client filesystem object list related to at least a certain portion of the filesystem; generate, in response to the request and in response to the filesystem data structure, the client filesystem object list, wherein the client filesystem object list comprises at least one pathname of at least one filesystem object that belongs to the at least certain portion of the filesystem; and send the client filesystem object list to the client.
- a storage system may include a controller and an interface, wherein the controller is configured to maintain a filesystem data structure that comprises filesystem pathnames metadata related to a filesystem that is stored in the storage system; wherein the interface is configured to receive, from a client that is coupled to the storage system via a network, a request to obtain a client filesystem object list related to at least a certain portion of the filesystem; wherein the controller is configured to generate, in response to the request and in response to the filesystem data structure, the client filesystem object list, wherein the client filesystem object list comprises at least one pathname of at least one filesystem object that belongs to the at least certain portion of the filesystem; and wherein the interface is configured to send the client filesystem object list to the client.
- FIG. 1 illustrates a storage system, a network and a client according to an embodiment of the invention
- FIG. 2 illustrates a storage system and a client according to an embodiment of the invention
- FIG. 3 illustrates a storage system and a client according to an embodiment of the invention.
- FIG. 4 illustrates a method according to an embodiment of the invention.
- Any reference in the specification to a method should be applied mutatis mutandis to a system capable of executing the method and should be applied mutatis mutandis to a non-transitory computer readable medium that stores instructions that once executed by a computer result in the execution of the method.
- Any reference in the specification to a system should be applied mutatis mutandis to a method that may be executed by the system and should be applied mutatis mutandis to a non-transitory computer readable medium that stores instructions that may be executed by the system.
- Any reference in the specification to a non-transitory computer readable medium should be applied mutatis mutandis to a system capable of executing the instructions stored in the non-transitory computer readable medium and should be applied mutatis mutandis to method that may be executed by a computer that reads the instructions stored in the non-transitory computer readable medium.
- any reference to the terms “comprising”, “comprise”, “comprises” and “including” should also be applied mutatis mutandis to a reference to the terms “consisting” and/or “consisting essentially of”.
- any reference to a method that includes various steps may refer to a method that may include additional steps but may also refer to a method that is limited only (or essentially limited to only) these various steps.
- a file system object may be a file, a directory, a hard link, or any other object that may exist in a file system. For simplicity of explanation it is assumed that the file system object is a file.
- a storage system that is configured to manage filesystem metadata such as a filesystem list file (also referred to as filesystem index file) in a predefined directory of each filesystem.
- filesystem list file includes a list of all the files of the filesystem and at least filesystem pathnames metadata that includes information required to obtain the pathnames (filename and full directory path per each file) of the files within the filesystem tree.
- the storage system may also store other types of filesystem metadata—such as filesystem attribute metadata that may include attributes of the filesystem objects that belong to the filesystem (e.g., inodes and directories information).
- filesystem attribute metadata may include attributes of the filesystem objects that belong to the filesystem (e.g., inodes and directories information).
- the storage system can provide a client filesystem object list that includes pathnames of all or part of the files in the filesystem and optionally, additional attributes of each file.
- the filesystem list file is updated, for example: (i) A new entry for a new file is added to the filesystem list file upon creation of a new file; (ii) An entry is deleted from the list file upon file deletion, and (iii) an entry is changed upon file rename or move (from directory to another directory) so as to reflect the new name or new path of the file.
- the filesystem list file may include a reference for each file in the filesystem.
- the reference may include a full pathname, an inode number or any other pointer to the file's metadata, both inode and full pathname, etc.
- the filesystem list file facilitates building a client filesystem object list, which is provided to the client upon request.
- the client filesystem object list includes at least pathnames for files in the filesystem.
- the client filesystem object list has a predefined (well-known) name that is published to the client, for example, the client filesystem object list may be named ‘indexFile’.
- the file named ‘indexFile’ is a virtual file that does not really exist, as it is built upon request.
- the client When a client that is connected to the storage system needs to perform a ‘find’ command or a ‘locate’ command, the client first needs to read the client filesystem object list, using a read-request for the client list-file, wherein the read request is a command provided by the operating-system (OS) of the client, e.g., by using the Linux command: ‘cat/myfilesystem/indexFile’, wherein ‘myfilesystem’ is a name of a mount point previously established for gaining access to the requested filesystem within the storage system.
- OS operating-system
- the client can use the command: ‘cat indexFile’ (without the prefix ‘myfilesystem/’) if the requested filesystem (‘myfilesystem’) was previously set as a default path for access (e.g., by using the change directory (cd) command).
- the above example refers to cases where the client needs to receive a list of all the files in the filesystem and therefore the read-request specifies the path of the root of the filesystem (e.g., ‘/’, or myfilesystem/’).
- the client requests to receive a subset of the filesystem's files, e.g., a list of the files under a certain sub-tree, the client can specify the path to the subtree, preceding the name of the index file. For example, the client can request only the files under the directory dirB that is under a directory dirA that is under the root, by using the command: ‘cat /dirA/dirB/indexFile’.
- the Linux command is then translated into a NAS read command, e.g., NFS-READ (which may be preceded by NFS-LOOKUP command(s)).
- NFS-READ which may be preceded by NFS-LOOKUP command(s)
- the storage system Upon receiving a read request (e.g., NFS-READ) to read the client filesystem object list, the storage system creates the client filesystem object list based on the filesystem list file of the requested filesystem.
- the building may include selecting among the entire filesystem's files only requested files and/or only allowed files and obtaining required file's attributes.
- the obtained file's attributes includes at least the pathnames, but may include additional attributes, such as size and timestamps.
- the filesystem list file includes inode numbers (or other pointers to file's metadata) as file references
- the full pathnames of the files are obtained based on the inode numbers.
- Other file attributes may also be obtained from the inode table and written to the client filesystem object list along with the file's pathname, for example: size, modified time, etc.
- ACLs Access Control Lists
- any other permission object associated with the files can be checked for access permission granted to the client that sent the read-request and only files that are permitted to be read by the client will be included in the client filesystem object list. If a certain sub-tree is not permitted to be accessed by the client, then none of the files or directories within the certain sub-tree will be included in the client filesystem object list. Similarly, if certain files are not permitted to be accessed by the client, then none of the certain files will be included in the client filesystem object list.
- the client specifies a path preceding the name of the client filesystem object list (e.g., VdirA/indexFile')
- a path preceding the name of the client filesystem object list e.g., VdirA/indexFile'
- the prefix of the path to each file in the filesystem is compared to the specified path and only if the specified path is identified in the prefix of the file's pathname, the file will be included in the response. For example: if the requested client filesystem object list was indicated as ‘/dirA/indexFile’, a file under the path ‘/’ or under ‘/dirB/ will be omitted, while files under e.g., /dirA/’ or under /dirA/dirB/’ will be included.
- the content of the filesystem list file can be sent without changes or filtering, in cases where all the following conditions are fulfilled: (i) authentication/permission check is not required, (ii) the client provided the root as the path, (iii) the filesystem list file includes all the information required for the client, for example, the filesystem list file may include full pathnames while full pathnames are the only required information.
- the client upon receiving the client filesystem object list, can perform the UNIX find/locate command or any similar simple text search on the received client filesystem object list.
- the storage system can receive the NAS find-command and perform the search on the filesystem list file.
- the storage system may provide a find-utility, e.g. an executable file under a specific directory-path.
- the name of the find-utility and its pathname are published to the client.
- the client can execute the find-utility, i.e., type the execute command in the command-line of the client Operating-System (OS), the OS will read the executable file from the storage system and execute it at the client side on the client filesystem object list which is also read from the storage system and transferred to the client.
- OS Operating-System
- FIG. 1 illustrates a storage system 100 , a client 130 and a network 90 coupled between the storage system 100 and the client 130 according to an embodiment of the invention.
- the network may be a NAS network.
- the client sends a client read request (denoted “read client index file”) to the storage system.
- the request refers to files that belong to at least certain portion of filesystem 120 .
- the storage system 100 stores filesystem 120 .
- File system 120 includes files 121 (including data and metadata of the files) and a filesystem data structure that is illustrated as including filesystem index file 110 and pathnames 140 .
- File system index file 110 includes pathname retrieval information such as pointers File-ref 111 ( 1 )-( n ) that enable a retrieval of pathnames, paths 141 ( 1 )- 141 ( m ) from pathnames 140 .
- the storage system sends to the client a client index-file 150 with pathnames (paths 151 ( 1 )- 151 ( m )) of files that belong to the at least certain portion of the filesystem.
- the storage system may store additional filesystem metadata (not shown)—such as but not limited to filesystem attribute metadata that include attributes (other than pathnames) of the files that belong to the filesystem.
- additional filesystem metadata may be for example, inodes, directories information, etc.
- FIG. 2 illustrates a storage system 100 and a client 130 according to an embodiment of the invention.
- the network that couples the storage system to the client was omitted for clarity of explanation.
- file system index file 110 ′ that includes pathname retrieval information such as pointers (denoted inode-pointers 121 ( 1 )- 121 ( n )) that points to inodes 125 ( 1 )- 125 ( n ) of inode table 126 . These pointers are also referred to as inode numbers.
- Inode table stores filesystem pathnames metadata or metadata that enables constructing pathnames, as well as filesystem attribute metadata that may include, for example, a size of the files of the filesystem.
- the response sent to the client is shown as including pathnames path 151 ( 1 )- 151 ( m ) and size information, size 152 ( 1 )- 152 ( m ).
- FIG. 3 illustrates a storage system 100 and a client 130 according to an embodiment of the invention.
- the network that couples the storage system to the client was omitted for clarity of explanation.
- the storage system is shown as storing file system index file 110 ′′ that includes the full pathnames 141 ( 1 )- 141 ( n ).
- FIG. 4 illustrates method 200 according to an embodiment of the invention.
- Method 200 may start by stages 210 and 220 .
- Stage 210 may be executed in a continuous manner or in real time or at least on a very high frequency.
- Stage 210 may include maintaining, by a storage system, a filesystem data structure that may include filesystem pathnames metadata related to a filesystem that is stored in the storage system. Stage 210 may include updating the filesystem data structure whenever a file system operation that should affect the filesystem data structure is executed.
- stage 210 may include updating in real time the filesystem data structure in response to an addition of any filesystem object to the filesystem, a deletion of any filesystem object of the filesystem, a renaming of any filesystem object of the filesystem and a moving of any file system object of the filesystem.
- the maintaining may include updating in real time the filesystem data structure in response to any change in the filesystem that mandates a change in the content of the filesystem data structure.
- the filesystem data structure may include filesystem metadata about objects included the filesystem.
- file system metadata may include:
- Stage 220 may include receiving, from a client that is coupled to the storage system via a network, a request to obtain a client filesystem object list related to at least a certain portion of the filesystem.
- Stage 220 may include receiving a request that includes a predefined term that represents the client filesystem object list.
- Stage 220 may be followed by stage 230 of generating, in response to the request and in response to the filesystem data structure, the client filesystem object list, wherein the client filesystem object list may include at least one pathname of at least one filesystem object that belongs to the at least certain portion of the filesystem.
- Stage 230 may be followed by stage 240 of sending the client filesystem object list to the client.
- Method 200 may include stage 280 of storing, in a certain location in the filesystem, an executable file that once executed by the client causes the client to respond to the request to obtain the client filesystem object list related to the at least certain portion of the filesystem by generating the client filesystem object list.
- the invention may also be implemented in a computer program for running on a computer system, at least including code portions for performing steps of a method according to the invention when run on a programmable apparatus, such as a computer system or enabling a programmable apparatus to perform functions of a device or system according to the invention.
- a computer program is a list of instructions such as a particular application program and/or an operating system.
- the computer program may for instance include one or more of: a subroutine, a function, a procedure, an object method, an object implementation, an executable application, an applet, a servlet, a source code, an object code, a shared library/dynamic load library and/or other sequence of instructions designed for execution on a computer system.
- the computer program may be stored internally on a non-transitory computer readable medium. All or some of the computer program may be provided on computer readable media permanently, removably or remotely coupled to an information processing system.
- the computer readable media may include, for example and without limitation, any number of the following: magnetic storage media including disk and tape storage media; optical storage media such as compact disk media (e.g., CD-ROM, CD-R, etc.) and digital video disk storage media; nonvolatile memory storage media including semiconductor-based memory units such as FLASH memory, EEPROM, EPROM, ROM; ferromagnetic digital memories; MRAM; volatile storage media including registers, buffers or caches, main memory, RAM, etc.
- a computer process typically includes an executing (running) program or portion of a program, current program values and state information, and the resources used by the operating system to manage the execution of the process.
- An operating system is the software that manages the sharing of the resources of a computer and provides programmers with an interface used to access those resources.
- An operating system processes system data and user input, and responds by allocating and managing tasks and internal system resources as a service to users and programs of the system.
- the computer system may for instance include at least one processing unit, associated memory and a number of input/output (TO) devices.
- TO input/output
- the computer system processes information according to the computer program and produces resultant output information via IO devices.
- connections as discussed herein may be any type of connection suitable to transfer signals from or to the respective nodes, units or devices, for example via intermediate devices. Accordingly, unless implied or stated otherwise, the connections may for example be direct connections or indirect connections.
- the connections may be illustrated or described in reference to being a single connection, a plurality of connections, unidirectional connections, or bidirectional connections. However, different embodiments may vary the implementation of the connections. For example, separate unidirectional connections may be used rather than bidirectional connections and vice versa.
- plurality of connections may be replaced with a single connection that transfers multiple signals serially or in a time multiplexed manner. Likewise, single connections carrying multiple signals may be separated out into various different connections carrying subsets of these signals. Therefore, many options exist for transferring signals.
- Each signal described herein may be designed as positive or negative logic.
- the signal In the case of a negative logic signal, the signal is active low where the logically true state corresponds to a logic level zero.
- the signal In the case of a positive logic signal, the signal is active high where the logically true state corresponds to a logic level one.
- any of the signals described herein may be designed as either negative or positive logic signals. Therefore, in alternate embodiments, those signals described as positive logic signals may be implemented as negative logic signals, and those signals described as negative logic signals may be implemented as positive logic signals.
- assert or “set” and “negate” (or “deassert” or “clear”) are used herein when referring to the rendering of a signal, status bit, or similar apparatus into its logically true or logically false state, respectively. If the logically true state is a logic level one, the logically false state is a logic level zero. And if the logically true state is a logic level zero, the logically false state is a logic level one.
- logic blocks are merely illustrative and that alternative embodiments may merge logic blocks or circuit elements or impose an alternate decomposition of functionality upon various logic blocks or circuit elements.
- architectures depicted herein are merely exemplary, and that in fact many other architectures may be implemented which achieve the same functionality.
- any arrangement of components to achieve the same functionality is effectively “associated” such that the desired functionality is achieved.
- any two components herein combined to achieve a particular functionality may be seen as “associated with” each other such that the desired functionality is achieved, irrespective of architectures or intermedial components.
- any two components so associated can also be viewed as being “operably connected,” or “operably coupled,” to each other to achieve the desired functionality.
- the illustrated examples may be implemented as circuitry located on a single integrated circuit or within a same device.
- the examples may be implemented as any number of separate integrated circuits or separate devices interconnected with each other in a suitable manner.
- the examples, or portions thereof may implemented as soft or code representations of physical circuitry or of logical representations convertible into physical circuitry, such as in a hardware description language of any appropriate type.
- the invention is not limited to physical devices or units implemented in non-programmable hardware but can also be applied in programmable devices or units able to perform the desired device functions by operating in accordance with suitable program code, such as mainframes, minicomputers, servers, workstations, personal computers, notepads, personal digital assistants, electronic games, automotive and other embedded systems, cell phones and various other wireless devices, commonly denoted in this application as ‘computer systems’.
- suitable program code such as mainframes, minicomputers, servers, workstations, personal computers, notepads, personal digital assistants, electronic games, automotive and other embedded systems, cell phones and various other wireless devices, commonly denoted in this application as ‘computer systems’.
- any reference signs placed between parentheses shall not be construed as limiting the claim.
- the word ‘comprising’ does not exclude the presence of other elements or steps then those listed in a claim.
- the terms “a” or “an,” as used herein, are defined as one or more than one.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Human Computer Interaction (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Library & Information Science (AREA)
- Computer Security & Cryptography (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
Description
- Filesystem and operating systems that interface with filesystems generally provide commands for searching and locating files within a tree of a filesystem according to specified criteria.
- An example for such command is the UNIX ‘find’ command-line that searches through specified directory or directory tree(s) of a filesystem, according to specified search criteria. Examples of search criteria include file name patterns, e.g. ‘xyz*” for searching files starting with xyz, a compound file name pattern, time constrains related to the modification time or access time of the file, size limits, ownership limitation, certain strings within the file content (‘grep’ command-line utility), directories or sub-trees to be searched in, and other criteria.
- The ‘find’ command is considered as a slow command, since it involves massive disk access for reading the relevant parts of the filesystem catalogue (directories and files' metadata). When NAS (Network-Attached Storage) is used to access a network filesystem, the latency imposed by the network makes it unreasonably to use the ‘find’ command.
- Yet other solutions are based upon a cyclic update of an index Data-Base by performing periodical queries of the file systems by the Client are inefficient because they are time consuming and thus are executed every few days and thus their content is erroneous most of the time.
- According to an embodiment of the invention there may be provided a method, the method may include: maintaining, by a storage system, a filesystem data structure that may include filesystem pathnames metadata related to a filesystem that is stored in the storage system; receiving, from a client that is coupled to the storage system via a network, a request to obtain a client filesystem object list related to at least a certain portion of the filesystem; generating, in response to the request and in response to the filesystem data structure, the client filesystem object list, wherein the client filesystem object list may include at least one pathname of at least one filesystem object that belongs to the at least certain portion of the filesystem; and sending the client filesystem object list to the client.
- The filesystem pathnames metadata may include pathnames of filesystem objects that belong to the filesystem.
- The filesystem pathnames metadata may include pathname retrieval information that facilitates a retrieval of pathnames of filesystem objects that belong to the filesystem.
- The filesystem data structure further may include filesystem attribute metadata that differs from the filesystem pathnames metadata.
- The filesystem attribute metadata may include attributes of filesystem objects that belong to the filesystem.
- The attribute of a filesystem object of the filesystem objects that belongs to the filesystem may be a size of the filesystem object.
- The method an attribute of a filesystem object of the filesystem objects that belongs to the filesystem may be a timestamp related to an operation applied on the filesystem object.
- The filesystem attribute metadata may include attributes retrieval information that facilitates a retrieval of attributes of filesystem objects that belong to the filesystem.
- The generating of the client filesystem object list is responsive to client access permissions related to filesystem objects that belong to the at least certain portion of the filesystem.
- The request to obtain the client filesystem object list may include a predefined term that represents the client filesystem object list.
- The method may include storing, in a certain location in the filesystem, an executable file that once executed by the client causes the client to respond to the request to obtain the client filesystem object list related to the at least certain portion of the filesystem by generating the client filesystem object list.
- The maintaining may include updating in real time the filesystem data structure in response to any change in the filesystem that mandates a change in the content of the filesystem data structure.
- The maintaining may include updating in real time the filesystem data structure in response to an addition of any filesystem object to the filesystem, a deletion of any filesystem object of the filesystem, a renaming of any filesystem object of the filesystem and a moving of any file system object of the filesystem.
- The request may be a network-attached storage (NAS) storage read request.
- According to an embodiment of the invention there may be provided a non-transitory computer readable medium may store instructions that once executed by a storage system cause the storage system to maintain a filesystem data structure that comprises filesystem pathnames metadata related to a filesystem that is stored in the storage system; receive, from a client that is coupled to the storage system via a network, a request to obtain a client filesystem object list related to at least a certain portion of the filesystem; generate, in response to the request and in response to the filesystem data structure, the client filesystem object list, wherein the client filesystem object list comprises at least one pathname of at least one filesystem object that belongs to the at least certain portion of the filesystem; and send the client filesystem object list to the client.
- According to an embodiment of the invention there may be provided a storage system that may include a controller and an interface, wherein the controller is configured to maintain a filesystem data structure that comprises filesystem pathnames metadata related to a filesystem that is stored in the storage system; wherein the interface is configured to receive, from a client that is coupled to the storage system via a network, a request to obtain a client filesystem object list related to at least a certain portion of the filesystem; wherein the controller is configured to generate, in response to the request and in response to the filesystem data structure, the client filesystem object list, wherein the client filesystem object list comprises at least one pathname of at least one filesystem object that belongs to the at least certain portion of the filesystem; and wherein the interface is configured to send the client filesystem object list to the client.
- The subject matter regarded as the invention is particularly pointed out and distinctly claimed in the concluding portion of the specification. The invention, however, both as to organization and method of operation, together with objects, features, and advantages thereof, may best be understood by reference to the following detailed description when read with the accompanying drawings in which:
-
FIG. 1 illustrates a storage system, a network and a client according to an embodiment of the invention; -
FIG. 2 illustrates a storage system and a client according to an embodiment of the invention; -
FIG. 3 illustrates a storage system and a client according to an embodiment of the invention; and -
FIG. 4 illustrates a method according to an embodiment of the invention. - It will be appreciated that for simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn to scale. For example, the dimensions of some of the elements may be exaggerated relative to other elements for clarity. Further, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous elements.
- In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the invention. However, it will be understood by those skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known methods, procedures, and components have not been described in detail so as not to obscure the present invention.
- The subject matter regarded as the invention is particularly pointed out and distinctly claimed in the concluding portion of the specification. The invention, however, both as to organization and method of operation, together with objects, features, and advantages thereof, may best be understood by reference to the following detailed description when read with the accompanying drawings.
- Because the illustrated embodiments of the present invention may for the most part, be implemented using electronic components and circuits known to those skilled in the art, details will not be explained in any greater extent than that considered necessary as illustrated above, for the understanding and appreciation of the underlying concepts of the present invention and in order not to obfuscate or distract from the teachings of the present invention.
- Any reference in the specification to a method should be applied mutatis mutandis to a system capable of executing the method and should be applied mutatis mutandis to a non-transitory computer readable medium that stores instructions that once executed by a computer result in the execution of the method.
- Any reference in the specification to a system should be applied mutatis mutandis to a method that may be executed by the system and should be applied mutatis mutandis to a non-transitory computer readable medium that stores instructions that may be executed by the system.
- Any reference in the specification to a non-transitory computer readable medium should be applied mutatis mutandis to a system capable of executing the instructions stored in the non-transitory computer readable medium and should be applied mutatis mutandis to method that may be executed by a computer that reads the instructions stored in the non-transitory computer readable medium.
- Any reference to the terms “comprising”, “comprise”, “comprises” and “including” should also be applied mutatis mutandis to a reference to the terms “consisting” and/or “consisting essentially of”. Thus, for example, any reference to a method that includes various steps may refer to a method that may include additional steps but may also refer to a method that is limited only (or essentially limited to only) these various steps.
- A file system object (may also be referred herein as an object) may be a file, a directory, a hard link, or any other object that may exist in a file system. For simplicity of explanation it is assumed that the file system object is a file.
- According to an embodiment of the invention there is provided a storage system that is configured to manage filesystem metadata such as a filesystem list file (also referred to as filesystem index file) in a predefined directory of each filesystem. The filesystem list file includes a list of all the files of the filesystem and at least filesystem pathnames metadata that includes information required to obtain the pathnames (filename and full directory path per each file) of the files within the filesystem tree.
- The storage system may also store other types of filesystem metadata—such as filesystem attribute metadata that may include attributes of the filesystem objects that belong to the filesystem (e.g., inodes and directories information).
- Based on the filesystem list file, the storage system can provide a client filesystem object list that includes pathnames of all or part of the files in the filesystem and optionally, additional attributes of each file.
- Whenever a change in the list file of the filesystem occurs, the filesystem list file is updated, for example: (i) A new entry for a new file is added to the filesystem list file upon creation of a new file; (ii) An entry is deleted from the list file upon file deletion, and (iii) an entry is changed upon file rename or move (from directory to another directory) so as to reflect the new name or new path of the file.
- The filesystem list file may include a reference for each file in the filesystem. The reference may include a full pathname, an inode number or any other pointer to the file's metadata, both inode and full pathname, etc.
- The filesystem list file facilitates building a client filesystem object list, which is provided to the client upon request. The client filesystem object list includes at least pathnames for files in the filesystem. The client filesystem object list has a predefined (well-known) name that is published to the client, for example, the client filesystem object list may be named ‘indexFile’. The file named ‘indexFile’ is a virtual file that does not really exist, as it is built upon request.
- When a client that is connected to the storage system needs to perform a ‘find’ command or a ‘locate’ command, the client first needs to read the client filesystem object list, using a read-request for the client list-file, wherein the read request is a command provided by the operating-system (OS) of the client, e.g., by using the Linux command: ‘cat/myfilesystem/indexFile’, wherein ‘myfilesystem’ is a name of a mount point previously established for gaining access to the requested filesystem within the storage system.
- Alternatively, the client can use the command: ‘cat indexFile’ (without the prefix ‘myfilesystem/’) if the requested filesystem (‘myfilesystem’) was previously set as a default path for access (e.g., by using the change directory (cd) command). The above example refers to cases where the client needs to receive a list of all the files in the filesystem and therefore the read-request specifies the path of the root of the filesystem (e.g., ‘/’, or myfilesystem/’). In cases where the client requests to receive a subset of the filesystem's files, e.g., a list of the files under a certain sub-tree, the client can specify the path to the subtree, preceding the name of the index file. For example, the client can request only the files under the directory dirB that is under a directory dirA that is under the root, by using the command: ‘cat /dirA/dirB/indexFile’.
- The Linux command is then translated into a NAS read command, e.g., NFS-READ (which may be preceded by NFS-LOOKUP command(s)).
- Upon receiving a read request (e.g., NFS-READ) to read the client filesystem object list, the storage system creates the client filesystem object list based on the filesystem list file of the requested filesystem. The building may include selecting among the entire filesystem's files only requested files and/or only allowed files and obtaining required file's attributes. The obtained file's attributes includes at least the pathnames, but may include additional attributes, such as size and timestamps.
- If the filesystem list file includes inode numbers (or other pointers to file's metadata) as file references, the full pathnames of the files are obtained based on the inode numbers. Other file attributes may also be obtained from the inode table and written to the client filesystem object list along with the file's pathname, for example: size, modified time, etc.
- Optionally, ACLs (Access Control Lists) or any other permission object associated with the files can be checked for access permission granted to the client that sent the read-request and only files that are permitted to be read by the client will be included in the client filesystem object list. If a certain sub-tree is not permitted to be accessed by the client, then none of the files or directories within the certain sub-tree will be included in the client filesystem object list. Similarly, if certain files are not permitted to be accessed by the client, then none of the certain files will be included in the client filesystem object list.
- In case where the client specifies a path preceding the name of the client filesystem object list (e.g., VdirA/indexFile'), only files under the specified path will be selected. In this case, the prefix of the path to each file in the filesystem (or in the group of permitted files) is compared to the specified path and only if the specified path is identified in the prefix of the file's pathname, the file will be included in the response. For example: if the requested client filesystem object list was indicated as ‘/dirA/indexFile’, a file under the path ‘/’ or under ‘/dirB/ will be omitted, while files under e.g., /dirA/’ or under /dirA/dirB/’ will be included.
- According to an embodiment of the invention, the content of the filesystem list file can be sent without changes or filtering, in cases where all the following conditions are fulfilled: (i) authentication/permission check is not required, (ii) the client provided the root as the path, (iii) the filesystem list file includes all the information required for the client, for example, the filesystem list file may include full pathnames while full pathnames are the only required information.
- The client, upon receiving the client filesystem object list, can perform the UNIX find/locate command or any similar simple text search on the received client filesystem object list.
- In case the NAS protocol includes a find-command, similar to UNIX ‘find’, the storage system can receive the NAS find-command and perform the search on the filesystem list file.
- The storage system may provide a find-utility, e.g. an executable file under a specific directory-path. The name of the find-utility and its pathname are published to the client. The client can execute the find-utility, i.e., type the execute command in the command-line of the client Operating-System (OS), the OS will read the executable file from the storage system and execute it at the client side on the client filesystem object list which is also read from the storage system and transferred to the client.
-
FIG. 1 illustrates astorage system 100, aclient 130 and anetwork 90 coupled between thestorage system 100 and theclient 130 according to an embodiment of the invention. The network may be a NAS network. - The client sends a client read request (denoted “read client index file”) to the storage system. The request refers to files that belong to at least certain portion of
filesystem 120. - The
storage system 100 stores filesystem 120.File system 120 includes files 121 (including data and metadata of the files) and a filesystem data structure that is illustrated as includingfilesystem index file 110 andpathnames 140. Filesystem index file 110 includes pathname retrieval information such as pointers File-ref 111(1)-(n) that enable a retrieval of pathnames, paths 141(1)-141(m) frompathnames 140. - The storage system sends to the client a client index-
file 150 with pathnames (paths 151(1)-151(m)) of files that belong to the at least certain portion of the filesystem. - The storage system may store additional filesystem metadata (not shown)—such as but not limited to filesystem attribute metadata that include attributes (other than pathnames) of the files that belong to the filesystem. The additional filesystem metadata may be for example, inodes, directories information, etc.
-
FIG. 2 illustrates astorage system 100 and aclient 130 according to an embodiment of the invention. The network that couples the storage system to the client was omitted for clarity of explanation. - In
FIG. 2 the storage system is shown as storing file system index file 110′ that includes pathname retrieval information such as pointers (denoted inode-pointers 121(1)-121(n)) that points to inodes 125(1)-125(n) of inode table 126. These pointers are also referred to as inode numbers. Inode table stores filesystem pathnames metadata or metadata that enables constructing pathnames, as well as filesystem attribute metadata that may include, for example, a size of the files of the filesystem. - The response sent to the client is shown as including pathnames path 151(1)-151(m) and size information, size 152(1)-152(m).
-
FIG. 3 illustrates astorage system 100 and aclient 130 according to an embodiment of the invention. The network that couples the storage system to the client was omitted for clarity of explanation. - In
FIG. 3 the storage system is shown as storing file system index file 110″ that includes the full pathnames 141(1)-141(n). -
FIG. 4 illustratesmethod 200 according to an embodiment of the invention. -
Method 200 may start bystages -
Stage 210 may be executed in a continuous manner or in real time or at least on a very high frequency. -
Stage 210 may include maintaining, by a storage system, a filesystem data structure that may include filesystem pathnames metadata related to a filesystem that is stored in the storage system.Stage 210 may include updating the filesystem data structure whenever a file system operation that should affect the filesystem data structure is executed. - For example—
stage 210 may include updating in real time the filesystem data structure in response to an addition of any filesystem object to the filesystem, a deletion of any filesystem object of the filesystem, a renaming of any filesystem object of the filesystem and a moving of any file system object of the filesystem. - The maintaining may include updating in real time the filesystem data structure in response to any change in the filesystem that mandates a change in the content of the filesystem data structure.
- The filesystem data structure may include filesystem metadata about objects included the filesystem. Non-limiting example of file system metadata may include:
-
- a. Filesystem pathnames metadata.
- b. Pathnames of files that belong to the filesystem.
- c. Pathname retrieval information that facilitates a retrieval of pathnames of the files that belong to the filesystem.
- d. Filesystem attribute metadata that differs from the filesystem pathnames metadata. The filesystem attribute metadata may include attributes of the files that belong to the filesystem.
- e. Filesystem attribute metadata about sizes of files the file system.
- f. Filesystem attribute metadata about times of an operation applied on the file.
- g. Attributes retrieval information that facilitates a retrieval of attributes of the files that belong to the filesystem. For example, the attribute retrieval information may be an inode number that points to an inode where the attributes are stored.
- h. Filesystem attribute metadata about client access permissions related to the files that belong to the at least certain portion of the filesystem. For example, the filesystem attribute metadata about client access permissions may include an ACL or a name of an ACL or a pointer to an ACL.
- i. A mapping between predefined names and filesystem paths.
-
Stage 220 may include receiving, from a client that is coupled to the storage system via a network, a request to obtain a client filesystem object list related to at least a certain portion of the filesystem. -
Stage 220 may include receiving a request that includes a predefined term that represents the client filesystem object list. -
Stage 220 may be followed bystage 230 of generating, in response to the request and in response to the filesystem data structure, the client filesystem object list, wherein the client filesystem object list may include at least one pathname of at least one filesystem object that belongs to the at least certain portion of the filesystem. -
Stage 230 may be followed bystage 240 of sending the client filesystem object list to the client. -
Method 200 may include stage 280 of storing, in a certain location in the filesystem, an executable file that once executed by the client causes the client to respond to the request to obtain the client filesystem object list related to the at least certain portion of the filesystem by generating the client filesystem object list. - The invention may also be implemented in a computer program for running on a computer system, at least including code portions for performing steps of a method according to the invention when run on a programmable apparatus, such as a computer system or enabling a programmable apparatus to perform functions of a device or system according to the invention.
- A computer program is a list of instructions such as a particular application program and/or an operating system. The computer program may for instance include one or more of: a subroutine, a function, a procedure, an object method, an object implementation, an executable application, an applet, a servlet, a source code, an object code, a shared library/dynamic load library and/or other sequence of instructions designed for execution on a computer system.
- The computer program may be stored internally on a non-transitory computer readable medium. All or some of the computer program may be provided on computer readable media permanently, removably or remotely coupled to an information processing system. The computer readable media may include, for example and without limitation, any number of the following: magnetic storage media including disk and tape storage media; optical storage media such as compact disk media (e.g., CD-ROM, CD-R, etc.) and digital video disk storage media; nonvolatile memory storage media including semiconductor-based memory units such as FLASH memory, EEPROM, EPROM, ROM; ferromagnetic digital memories; MRAM; volatile storage media including registers, buffers or caches, main memory, RAM, etc.
- A computer process typically includes an executing (running) program or portion of a program, current program values and state information, and the resources used by the operating system to manage the execution of the process. An operating system (OS) is the software that manages the sharing of the resources of a computer and provides programmers with an interface used to access those resources. An operating system processes system data and user input, and responds by allocating and managing tasks and internal system resources as a service to users and programs of the system.
- The computer system may for instance include at least one processing unit, associated memory and a number of input/output (TO) devices. When executing the computer program, the computer system processes information according to the computer program and produces resultant output information via IO devices.
- In the foregoing specification, the invention has been described with reference to specific examples of embodiments of the invention. It will, however, be evident that various modifications and changes may be made therein without departing from the broader spirit and scope of the invention as set forth in the appended claims.
- Moreover, the terms “front,” “back,” “top,” “bottom,” “over,” “under” and the like in the description and in the claims, if any, are used for descriptive purposes and not necessarily for describing permanent relative positions. It is understood that the terms so used are interchangeable under appropriate circumstances such that the embodiments of the invention described herein are, for example, capable of operation in other orientations than those illustrated or otherwise described herein.
- The connections as discussed herein may be any type of connection suitable to transfer signals from or to the respective nodes, units or devices, for example via intermediate devices. Accordingly, unless implied or stated otherwise, the connections may for example be direct connections or indirect connections. The connections may be illustrated or described in reference to being a single connection, a plurality of connections, unidirectional connections, or bidirectional connections. However, different embodiments may vary the implementation of the connections. For example, separate unidirectional connections may be used rather than bidirectional connections and vice versa. Also, plurality of connections may be replaced with a single connection that transfers multiple signals serially or in a time multiplexed manner. Likewise, single connections carrying multiple signals may be separated out into various different connections carrying subsets of these signals. Therefore, many options exist for transferring signals.
- Although specific conductivity types or polarity of potentials have been described in the examples, it will be appreciated that conductivity types and polarities of potentials may be reversed.
- Each signal described herein may be designed as positive or negative logic. In the case of a negative logic signal, the signal is active low where the logically true state corresponds to a logic level zero. In the case of a positive logic signal, the signal is active high where the logically true state corresponds to a logic level one. Note that any of the signals described herein may be designed as either negative or positive logic signals. Therefore, in alternate embodiments, those signals described as positive logic signals may be implemented as negative logic signals, and those signals described as negative logic signals may be implemented as positive logic signals.
- Furthermore, the terms “assert” or “set” and “negate” (or “deassert” or “clear”) are used herein when referring to the rendering of a signal, status bit, or similar apparatus into its logically true or logically false state, respectively. If the logically true state is a logic level one, the logically false state is a logic level zero. And if the logically true state is a logic level zero, the logically false state is a logic level one.
- Those skilled in the art will recognize that the boundaries between logic blocks are merely illustrative and that alternative embodiments may merge logic blocks or circuit elements or impose an alternate decomposition of functionality upon various logic blocks or circuit elements. Thus, it is to be understood that the architectures depicted herein are merely exemplary, and that in fact many other architectures may be implemented which achieve the same functionality.
- Any arrangement of components to achieve the same functionality is effectively “associated” such that the desired functionality is achieved. Hence, any two components herein combined to achieve a particular functionality may be seen as “associated with” each other such that the desired functionality is achieved, irrespective of architectures or intermedial components. Likewise, any two components so associated can also be viewed as being “operably connected,” or “operably coupled,” to each other to achieve the desired functionality.
- Furthermore, those skilled in the art will recognize that boundaries between the above described operations merely illustrative. The multiple operations may be combined into a single operation, a single operation may be distributed in additional operations and operations may be executed at least partially overlapping in time. Moreover, alternative embodiments may include multiple instances of a particular operation, and the order of operations may be altered in various other embodiments.
- Also for example, in one embodiment, the illustrated examples may be implemented as circuitry located on a single integrated circuit or within a same device. Alternatively, the examples may be implemented as any number of separate integrated circuits or separate devices interconnected with each other in a suitable manner.
- Also for example, the examples, or portions thereof, may implemented as soft or code representations of physical circuitry or of logical representations convertible into physical circuitry, such as in a hardware description language of any appropriate type.
- Also, the invention is not limited to physical devices or units implemented in non-programmable hardware but can also be applied in programmable devices or units able to perform the desired device functions by operating in accordance with suitable program code, such as mainframes, minicomputers, servers, workstations, personal computers, notepads, personal digital assistants, electronic games, automotive and other embedded systems, cell phones and various other wireless devices, commonly denoted in this application as ‘computer systems’.
- However, other modifications, variations and alternatives are also possible. The specifications and drawings are, accordingly, to be regarded in an illustrative rather than in a restrictive sense.
- In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The word ‘comprising’ does not exclude the presence of other elements or steps then those listed in a claim. Furthermore, the terms “a” or “an,” as used herein, are defined as one or more than one. Also, the use of introductory phrases such as “at least one” and “one or more” in the claims should not be construed to imply that the introduction of another claim element by the indefinite articles “a” or “an” limits any particular claim containing such introduced claim element to inventions containing only one such element, even when the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” or “an.” The same holds true for the use of definite articles. Unless stated otherwise, terms such as “first” and “second” are used to arbitrarily distinguish between the elements such terms describe. Thus, these terms are not necessarily intended to indicate temporal or other prioritization of such elements. The mere fact that certain measures are recited in mutually different claims does not indicate that a combination of these measures cannot be used to advantage.
- While certain features of the invention have been illustrated and described herein, many modifications, substitutions, changes, and equivalents will now occur to those of ordinary skill in the art. It is, therefore, to be understood that the appended claims are intended to cover all such modifications and changes as fall within the true spirit of the invention.
Claims (16)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/616,756 US9411526B1 (en) | 2015-02-09 | 2015-02-09 | Filesystem management |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/616,756 US9411526B1 (en) | 2015-02-09 | 2015-02-09 | Filesystem management |
Publications (2)
Publication Number | Publication Date |
---|---|
US9411526B1 US9411526B1 (en) | 2016-08-09 |
US20160231952A1 true US20160231952A1 (en) | 2016-08-11 |
Family
ID=56556421
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/616,756 Active 2035-05-08 US9411526B1 (en) | 2015-02-09 | 2015-02-09 | Filesystem management |
Country Status (1)
Country | Link |
---|---|
US (1) | US9411526B1 (en) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20190236296A1 (en) * | 2018-01-30 | 2019-08-01 | EMC IP Holding Company LLC | Sparse creation of per-client pseudofs in network filesystem with lookup hinting |
US11416629B2 (en) * | 2018-01-30 | 2022-08-16 | EMC IP Holding Company LLC | Method for dynamic pseudofs creation and management in a network filesystem |
US11709804B1 (en) * | 2020-05-13 | 2023-07-25 | Parallels International Gmbh | Virtual client file systems and methods within remote sessions |
EP4202716A4 (en) * | 2020-08-24 | 2024-02-14 | FUJIFILM Corporation | Information processing device, information processing method, and information processing program |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10409687B1 (en) * | 2015-03-31 | 2019-09-10 | EMC IP Holding Company LLC | Managing backing up of file systems |
US10713215B2 (en) * | 2015-11-13 | 2020-07-14 | International Business Machines Corporation | Allocating non-conflicting inode numbers |
CN111177784A (en) * | 2019-12-31 | 2020-05-19 | 上海摩勤智能技术有限公司 | Security protection method and device for file system and storage medium |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7010554B2 (en) * | 2002-04-04 | 2006-03-07 | Emc Corporation | Delegation of metadata management in a storage system by leasing of free file system blocks and i-nodes from a file system owner |
-
2015
- 2015-02-09 US US14/616,756 patent/US9411526B1/en active Active
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20190236296A1 (en) * | 2018-01-30 | 2019-08-01 | EMC IP Holding Company LLC | Sparse creation of per-client pseudofs in network filesystem with lookup hinting |
US11416629B2 (en) * | 2018-01-30 | 2022-08-16 | EMC IP Holding Company LLC | Method for dynamic pseudofs creation and management in a network filesystem |
US11436354B2 (en) * | 2018-01-30 | 2022-09-06 | EMC IP Holding Company LLC | Sparse creation of per-client pseudofs in network filesystem with lookup hinting |
US11704425B2 (en) | 2018-01-30 | 2023-07-18 | EMC IP Holding Company LLC | Method for dynamic pseudofs creation and management in a network filesystem |
US11709804B1 (en) * | 2020-05-13 | 2023-07-25 | Parallels International Gmbh | Virtual client file systems and methods within remote sessions |
EP4202716A4 (en) * | 2020-08-24 | 2024-02-14 | FUJIFILM Corporation | Information processing device, information processing method, and information processing program |
Also Published As
Publication number | Publication date |
---|---|
US9411526B1 (en) | 2016-08-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9411526B1 (en) | Filesystem management | |
US11288267B2 (en) | Pluggable storage system for distributed file systems | |
US10740319B2 (en) | Graph-based data models for partitioned data | |
US10346363B2 (en) | Deduplicated file system | |
US9411840B2 (en) | Scalable data structures | |
US7860907B2 (en) | Data processing | |
US20190026301A1 (en) | File system that supports both case sensitive and case insensitive directory lookup | |
US7228299B1 (en) | System and method for performing file lookups based on tags | |
US11977456B2 (en) | File system framework | |
US8660997B2 (en) | File system object-based deduplication | |
US8095678B2 (en) | Data processing | |
CN106682003B (en) | The path segmentation mapping method and device of distributed storage NameSpace | |
US8090925B2 (en) | Storing data streams in memory based on upper and lower stream size thresholds | |
JP2012174096A (en) | Computer system and data management method | |
KR20120106544A (en) | Method for accessing files of a file system according to metadata and device implementing the method | |
US8176087B2 (en) | Data processing | |
Renner et al. | Addressing hadoop's small file problem with an appendable archive file format | |
US20220197867A1 (en) | Ignore objects from syncrhonizing to content management system | |
CN112463792A (en) | Data authority control method and device | |
WO2023201002A1 (en) | Implementing graph search with in-structure metadata of a graph-organized file system | |
US11989159B2 (en) | Hybrid snapshot of a global namespace | |
US20220365905A1 (en) | Metadata processing method and apparatus, and a computer-readable storage medium | |
KR100912126B1 (en) | Method for providing snapshot of fileset of object based file system | |
US12001481B2 (en) | Graph-organized file system | |
CN117873967B (en) | Data management method, device, equipment and storage medium of distributed file system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: INFINIDAT LTD., ISRAEL Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BROIDO, JACOB;BROWN, ERAN;REEL/FRAME:034944/0393 Effective date: 20150211 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
AS | Assignment |
Owner name: BANK LEUMI LE-ISRAEL B.M., ISRAEL Free format text: SECURITY INTEREST;ASSIGNOR:INFINIDAT LTD.;REEL/FRAME:045914/0276 Effective date: 20180321 |
|
FEPP | Fee payment procedure |
Free format text: ENTITY STATUS SET TO UNDISCOUNTED (ORIGINAL EVENT CODE: BIG.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 4 |
|
AS | Assignment |
Owner name: SILICON VALLEY BANK, CALIFORNIA Free format text: SECURITY INTEREST;ASSIGNOR:INFINIDAT LTD.;REEL/FRAME:055653/0854 Effective date: 20210318 |
|
AS | Assignment |
Owner name: INFINIDAT LTD., ISRAEL Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:BANK LEUMI LE-ISRAEL B.M.;REEL/FRAME:055776/0526 Effective date: 20210318 |
|
AS | Assignment |
Owner name: HSBC BANK PLC, ENGLAND Free format text: SECURITY INTEREST;ASSIGNOR:INFINIDAT LTD;REEL/FRAME:066268/0584 Effective date: 20231220 |
|
AS | Assignment |
Owner name: KREOS CAPITAL 2020 OPPORTUNITY L.P., JERSEY Free format text: SECURITY INTEREST;ASSIGNOR:INFINIDAT LTD;REEL/FRAME:066270/0359 Effective date: 20231219 Owner name: KREOS CAPITAL VI (EXPERT FUND) L.P., JERSEY Free format text: SECURITY INTEREST;ASSIGNOR:INFINIDAT LTD;REEL/FRAME:066270/0359 Effective date: 20231219 |
|
AS | Assignment |
Owner name: INFINIDAT LTD., ISRAEL Free format text: RELEASE OF SECURITY INTEREST IN IP RECORDED AT R/F 55653/0854;ASSIGNOR:SILICON VALLEY BANK;REEL/FRAME:066344/0064 Effective date: 20240116 |
|
FEPP | Fee payment procedure |
Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
FEPP | Fee payment procedure |
Free format text: ENTITY STATUS SET TO SMALL (ORIGINAL EVENT CODE: SMAL); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY Free format text: 7.5 YR SURCHARGE - LATE PMT W/IN 6 MO, SMALL ENTITY (ORIGINAL EVENT CODE: M2555); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YR, SMALL ENTITY (ORIGINAL EVENT CODE: M2552); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY Year of fee payment: 8 |