WO2016122688A1 - Charging a user's storage quota for extended attributes - Google Patents

Charging a user's storage quota for extended attributes Download PDF

Info

Publication number
WO2016122688A1
WO2016122688A1 PCT/US2015/022793 US2015022793W WO2016122688A1 WO 2016122688 A1 WO2016122688 A1 WO 2016122688A1 US 2015022793 W US2015022793 W US 2015022793W WO 2016122688 A1 WO2016122688 A1 WO 2016122688A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
storage
gid
uid
tree
Prior art date
Application number
PCT/US2015/022793
Other languages
French (fr)
Inventor
Amarish S. V
Chaitanya NARRA
Abhay SACHAN
Padmagandha PANIGRAHY
Anil Kumar BOOGARAPU
Venkataraman Kamalaksha
Rajagopal Chellam
Original Assignee
Hewlett Packard Enterprise Development Lp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hewlett Packard Enterprise Development Lp filed Critical Hewlett Packard Enterprise Development Lp
Publication of WO2016122688A1 publication Critical patent/WO2016122688A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/14Details of searching files based on file metadata
    • G06F16/148File search processing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input 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/06Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601Interfaces specially adapted for storage systems
    • G06F3/0602Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/061Improving I/O performance

Definitions

  • File attributes are metadata values that may be associated with files of a computer file system.
  • File attributes may provide an operating system or application program more information about a file.
  • Some examples of file attributes include: read-only, archive, hidden, and system.
  • regular attributes may include a purpose strictly defined by the file system
  • extended file attributes may enable users to associate files with metadata not interpreted by the file system. For example, users may use these attributes to store the name of an author of a document, a checksum, a digital signature, etc.
  • FIG. 1 is a block diagram of an example computing device for charging a user's storage quota for extended attributes
  • FIG. 2 is a block diagram of another example computing device for charging a user's storage quota for extended attributes
  • FIG. 3 is a flowchart of an example method of charging a user's storage quota for extended attributes
  • FIG. 4 is a block diagram of an example computer system for charging a user's storage quota for extended attributes. Detailed Description
  • Extended attributes may be considered as extensions to regular attributes that are associated with inodes (files, directories, etc.) of a file system. Extended attributes are supported by various types of operating systems such as Linux, Unix, Windows, Solaris, etc. They may be optionally set to a file in order to capture information that cannot be stored in the file itself. For instance, four categories of extended attributes have been defined in Linux. These include security, trusted, user, and system.
  • FIG. 1 is a block diagram of an example computing device 100 for charging a user's storage quota for extended attributes.
  • Computing device 100 may include a file 102, a recognition module 104, a determination module 106, and a charge module 108.
  • module may refer to a software component (machine readable instructions), a hardware component or a combination thereof.
  • a module may include, by way of example, components, such as software components, processes, tasks, coroutines, functions, attributes, procedures, drivers, firmware, data, databases, data structures, Application Specific Integrated Circuits (ASIC) and other computing devices.
  • a module may reside on a volatile or nonvolatile storage medium and configured to interact with a processor of computing device 100.
  • Computing device 100 generally represents any type of computing system capable of reading machine-executable instructions. Examples of computing device 100 may include, without limitation, a server, a desktop computer, a notebook computer, a tablet computer, a thin client, a mobile device, a personal digital assistant (PDA), a phablet, and the like.
  • Examples of computing device 100 may include, without limitation, a server, a desktop computer, a notebook computer, a tablet computer, a thin client, a mobile device, a personal digital assistant (PDA), a phablet, and the like.
  • PDA personal digital assistant
  • file may include a computer or digital file.
  • File 102 may contain data, such as text files, image files, video files, database files, and the like, or it may be an executable file or program.
  • a computer file or "file” is the basic component of a file system.
  • the file system provides the underlying structure that a computing device uses to organize data on a storage medium.
  • Files may be organized by storing related files in a directory or sub-directory.
  • a directory or sub-directory is also a file.
  • the term "directory" (or "file directory), as used herein, may include a file that contains references (for example, names) to other files. Thus, a directory may be considered as a container for files.
  • file 102 may be a part of a local file system.
  • file 102 may be component of a scale-out file system such as a shared file system or network file system. Examples of a shared file system may include a Network Attached Storage (NAS) file system or cluster file system. Examples of a network file system may include a distributed file system or distributed parallel file system.
  • NAS Network Attached Storage
  • file 102 may be stored on computing device 100.
  • file 102 may be stored on a machine-readable storage medium remote from but accessible to computing device 100, for example, via a computer network.
  • a computer network may be a wireless or wired network.
  • the computer network may include, for example, a Local Area Network (LAN), a Wireless Local Area Network (WAN), a Metropolitan Area Network (MAN), a Storage Area Network (SAN), a Campus Area Network (CAN), or the like.
  • the computer network may be a public network (for example, the Internet) or a private network (for example, an intranet).
  • File 102 may be associated with one or more extended attributes.
  • an extended attribute associated with file 102 may include four parameters: name of the extended attribute, value assigned to the extended attribute, a User ID (UID) and a Group ID (GID).
  • the extended attribute may be a quadruplet comprising four parameters (i.e. name, value, UID, GID).
  • an extended attribute of file 102, with all associated parameters may be stored in a separate file. In an instance, such file may be a sequential file. Although only one file is illustrated in FIG. 1 , in other examples, a plurality of files may be present.
  • a User ID (UID) associated with an extended attribute of a file may include identification information of a user who created the file.
  • a User ID (UID) associated with an extended attribute of a file may include identification information of a user who created the extended attribute.
  • a User ID (UID) associated with an extended attribute of a file may include identification information of a user who was last to modify the extended attribute.
  • each user may be assigned to some group.
  • Each group may be assigned a unique Group ID that may provide identification information of a group. Users (or User IDs) assigned to the same group may share rights. For instance, all users in a group may be allowed to modify contents of a particular file.
  • a Group ID (GID) associated with an extended attribute of a file may include identification information of a group that a user, who created the file, belongs to.
  • a Group ID (GID) associated with an extended attribute of a file may include identification information of a group that a user, who created the extended attribute, belongs to.
  • a Group ID (GID) associated with an extended attribute of a file may include identification information of a group that a user, who was last to modify the extended attribute, belongs to.
  • storage quotas may be defined for each User ID and Group ID. Such storage quota may define the amount of storage space that may be used by a particular User ID or Group ID.
  • Recognition module 104 may recognize a user action regarding an extended attribute of a file (for example, file 102). In other words, if a user performs an action related to an extended attribute of a file (for example, file 102), the recognition module 104 may identify that action. For example, if a user creates or sets an extended attribute of a file (for example, file 102), the recognition module may recognize such user action. Similarly, if a user deletes an extended attribute of a file (for example, file 102), the recognition module 104 may realize such user action. Likewise, if a user modifies an extended attribute of a file (for example, file 102), the recognition module 104 may recognize such user action.
  • Determination module 106 may determine a user ID (UID) and a group ID (GID) of a user who requests a user action regarding an extended attribute of a file (for example, 102). In an example, determination module 106 may perform such determination from the command or process used by a user requesting a user action related to an extended attribute of a file (for example, 102).
  • UID user ID
  • GID group ID
  • Charge module 108 may charge storage affected by the user action towards respective storage quotas allocated to the UID and the GID of the user.
  • charge module 108 may charge the storage impacted by such user action against storage quotas that are assigned to the UID and the GID of the user. For example, if the user action includes generation of an extended attribute, charge module 108 may reduce the respective storage quotas allocated to the UID and the GID of the user, corresponding to storage used pursuant to generation of the extended attribute.
  • charge module 108 may charge such use against the UID and the GID of the user who performed the action, and reduce the storage quotas of such UID and GID with an amount equivalent to the consumed storage space.
  • charge module 108 may increase the respective storage quotas allocated to the UID and the GID of the user, corresponding to storage released consequent to deleting the extended attribute. In other words, if a user action regarding an extended attribute leads to release of storage space, charge module 108 may charge such use against the UID and the GID of the user who performed the action, and increase the storage quotas of such UID and GID with an amount equivalent to the released storage space.
  • storage space charged against a UID and/or GID of a user consequent to a user action related to an extended attribute may be recorded in a B-tree.
  • B-tree may be a tree data structure that keeps data sorted and allows searches, sequential access, insertions, and deletions.
  • B- tree may be construed as a generalization of a binary search tree in that a node may have more than two children.
  • a per-file B-tree may be maintained that may contain UIDs and GIDs of all users who may have set, modified, or deleted an extended attribute related to a file (for example, file 102).
  • Such B-tree may be termed as "Quota B-tree”.
  • such B-tree may also provide information related to storage quota charged against UID and GID of all users who may have set, modified, or deleted an extended attribute related to the file.
  • a storage quota charged against a UID and GID of a user may be defined in the form of a "bytes_consumed" field that may be stored along with the UID and GID of the user in the Quota B-tree.
  • charge module 108 may search the UID and GID of the user in the Quota B-tree, and the storage space consumed as a result of user action may be charged against the storage of the UID and GID of the user.
  • charge module may search the UID and GID of the user in the Quota B-tree, and the storage space released as a result of user action may be charged against the storage of the UID and GID of the user.
  • determination module 106 may determine if a UID and GID of a user along with respective storage quotas are defined in Quota B- tree.
  • determination module 106 may insert the UID and GID of the user along with respective storage quotas in the Quota B- tree.
  • charge module 108 may charge storage impacted by a user action related to an extended attribute, towards respective storage quotas allocated to the UID and GID of the user in the Quota B-tree.
  • FIG. 2 is a block diagram of an example computing device 200 for charging a user's storage quota for extended attributes.
  • Computing device 200 may be analogous to computing device 100, in which like reference numerals correspond to the same or similar, though perhaps not identical, components.
  • components or reference numerals of FIG. 2 having a same or similarly described function in FIG. 1 are not being described in connection with FIG. 2. Said components or reference numerals may be considered alike.
  • Computing device 100 may include a file 102, a recognition module 104, a determination module 106, a charge module 108, and a hash module 1 10.
  • the extended attributes related to a file may be stored in a B+ tree.
  • B+ tree may consist of a root, internal nodes and leaves. The root may be either a leaf or a node with two or more children. Each node of the tree may contain an ordered list of keys and pointers to lower level nodes in the tree.
  • the name of an extended attribute may be used as a key for the B+ tree.
  • the name of the extended attribute may be hashed and inserted into the B+ tree.
  • Each node of the B+ tree may include a node header and a plurality of node elements. Each node element may store the hash of an extended attribute's name and an offset. The offset provides the location in a file where the unhashed extended attribute's name and value may be stored. In an example, a sequential file may store such details.
  • hash module 1 10 may generate, upon recognition of a user action related to an extended attribute of a file (for example, file 102), a hash of name of the extended attribute. Hash module 1 10 may then determine whether the hash is present in the B+ Tree. In response to the determination that the hash is not present in the B+ Tree, hash module may insert the hash and an offset in a node of the B+ Tree. The offset may provide the location of: name of the extended attribute, value of the extended attribute, a U ID and a GID of the user who performed the user action, in a file that stores the extended attribute.
  • the determination module 106 may use the offset to obtain the UID and the GID of the user from the file that stores the extended attribute.
  • Charge module 108 may then use the UID and the GID of the user to charge storage affected by the user action towards respective storage quotas allocated to the UID and the GID of the user.
  • the hashed name of the extended attribute may be removed from the B+ tree, and the record related to the extended attribute may be marked as deleted from the file where it was stored.
  • the offsets containing free spaces may be stored in another B+ tree, which may be called as "free space B+ tree".
  • the free space B+ tree may be indexed by the length of free space.
  • a node element of this tree may store the value of the offset in the file where a free space lies.
  • FIG. 3 is a flowchart of an example method of charging a user's storage quota for extended attributes.
  • the method 300 which is described below, may at least partially be executed on computing devices 100 and 200 of FIGS. 1 and 2, respectively. However, other computing devices may be used as well.
  • a user action regarding an extended attribute of a file (for example, file 102) may be recognized.
  • a user ID (UID) and a group ID (GID) of the user requesting the user action may be determined.
  • storage impacted by the user action may be charged towards respective storage quotas allocated to the UID and the GID of the user.
  • charging storage impacted by the user action towards respective storage quotas of the UID and the GID of the user may comprise reducing the respective storage quotas of the UID and the GID of the user, corresponding to storage used for generation of the extended attribute.
  • charging storage impacted by the user action towards respective storage quotas of the UID and the GID of the user may comprise increasing the respective storage quotas allocated to the UID and the GID of the user, corresponding to storage released consequent to deleting the extended attribute.
  • FIG. 4 is a block diagram of an example computer system 400 for charging a user's storage quota for extended attributes.
  • System 400 includes a processor 402 and a machine-readable storage medium 404 communicatively coupled through a system bus.
  • system 400 may be analogous to computing device 100 of FIG. 1 .
  • Processor 402 may be any type of Central Processing Unit (CPU), microprocessor, or processing logic that interprets and executes machine-readable instructions stored in machine-readable storage medium 404.
  • CPU Central Processing Unit
  • microprocessor or processing logic that interprets and executes machine-readable instructions stored in machine-readable storage medium 404.
  • Machine-readable storage medium 404 may be a random access memory (RAM) or another type of dynamic storage device that may store information and machine-readable instructions that may be executed by processor 402.
  • machine- readable storage medium 404 may be Synchronous DRAM (SDRAM), Double Data Rate (DDR), Rambus DRAM (RDRAM), Rambus RAM, etc. or a storage memory media such as a floppy disk, a hard disk, a CD-ROM, a DVD, a pen drive, and the like.
  • machine-readable storage medium 404 may be a non-transitory machine-readable medium.
  • Machine- readable storage medium 404 may store instructions 406, 408, and 410.
  • instructions 406 may be executed by processor 402 to recognize a user action regarding an extended attribute of a file (for example, file 102).
  • Instructions 408 may be executed by processor 402 to determine whether a user ID (UID) and a group ID (GID) of user requesting the user action is present in a B-tree.
  • instructions 410 may be executed by processor 402 to charge storage impacted by the user action towards respective storage quotas assigned to the UID and the GID of the user in the B-tree.
  • FIG. 3 is shown as executing serially, however it is to be understood and appreciated that the present and other examples are not limited by the illustrated order.
  • the example systems of FIGS. 1 , 2 and 4, and method of FIG. 3 may be implemented in the form of a computer program product including computer-executable instructions, such as program code, which may be run on any suitable computing device in conjunction with a suitable operating system (for example, Microsoft Windows, Linux, UNIX, and the like).
  • a suitable operating system for example, Microsoft Windows, Linux, UNIX, and the like.
  • Embodiments within the scope of the present solution may also include program products comprising non-transitory computer-readable media for carrying or having computer-executable instructions or data structures stored thereon.
  • Such computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer.
  • such computer-readable media can comprise RAM, ROM, EPROM, EEPROM, CD-ROM, magnetic disk storage or other storage devices, or any other medium which can be used to carry or store desired program code in the form of computer-executable instructions and which can be accessed by a general purpose or special purpose computer.
  • the computer readable instructions can also be accessed from memory and executed by a processor. 35] It should be noted that the above-described examples of the present solution is for the purpose of illustration only. Although the solution has been described in conjunction with a specific embodiment thereof, numerous modifications may be possible without materially departing from the teachings and advantages of the subject matter described herein. Other substitutions, modifications and changes may be made without departing from the spirit of the present solution. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and/or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and/or steps are mutually exclusive.

Abstract

Some examples relate to charging a users storage quota for extended attributes. In an example, a user action regarding an extended attribute of a file may be recognized. A user ID (UID) and a group ID (GID) of user requesting the user action may be determined. Storage impacted by the user action may be charged towards respective storage quotas allocated to the UID and the GID of the user.

Description

CHARGING A USER'S STORAGE QUOTA FOR EXTENDED ATTRIBUTES Background
[001] File attributes are metadata values that may be associated with files of a computer file system. File attributes may provide an operating system or application program more information about a file. Some examples of file attributes include: read-only, archive, hidden, and system. Whereas regular attributes may include a purpose strictly defined by the file system, extended file attributes may enable users to associate files with metadata not interpreted by the file system. For example, users may use these attributes to store the name of an author of a document, a checksum, a digital signature, etc.
Brief Description of the Drawings
[002] For a better understanding of the solution, embodiments will now be described, purely by way of example, with reference to the accompanying drawings, in which:
[003] FIG. 1 is a block diagram of an example computing device for charging a user's storage quota for extended attributes;
[004] FIG. 2 is a block diagram of another example computing device for charging a user's storage quota for extended attributes;
[005] FIG. 3 is a flowchart of an example method of charging a user's storage quota for extended attributes; and
[006] FIG. 4 is a block diagram of an example computer system for charging a user's storage quota for extended attributes. Detailed Description
[007] Extended attributes may be considered as extensions to regular attributes that are associated with inodes (files, directories, etc.) of a file system. Extended attributes are supported by various types of operating systems such as Linux, Unix, Windows, Solaris, etc. They may be optionally set to a file in order to capture information that cannot be stored in the file itself. For instance, four categories of extended attributes have been defined in Linux. These include security, trusted, user, and system.
[008] In existing file systems, storage space consumed for storing extended attributes of a file is counted towards the disk quotas of the file owner and the file group. Thus, in a scenario where multiple users have write permissions to a file, a user who's not the owner of the file but has "write" permission may set extended attributes on a file, over and above user's allocated storage limit, since storage used for setting of such extended attributes may be charged against storage space assigned to the file owner and the file group. This is not a desirable situation as it may be exploited by a malicious user either by storing data over and above his or her storage quota limit, or causing a denial of service to the file owner by using latter's quota. Further, in a scenario where a storage administrator may be tasked with setting-up of extended attributes for a file, a file owner may be unfairly charged with the storage used for the extended attributes. It should ideally be charged against the storage quota of the administrator.
[009] To address this issue, the present disclosure describes various examples for charging a user's storage quota for extended attributes. In an example, a user action regarding an extended attribute of a file may be recognized. Upon recognition, a user ID (UID) and a group ID (GID) of the user requesting the user action may be determined. Upon determination, storage impacted by the user action may be charged towards respective storage quotas allocated to the UID and the GID of the user. [0010] FIG. 1 is a block diagram of an example computing device 100 for charging a user's storage quota for extended attributes. Computing device 100 may include a file 102, a recognition module 104, a determination module 106, and a charge module 108. The term "module" may refer to a software component (machine readable instructions), a hardware component or a combination thereof. A module may include, by way of example, components, such as software components, processes, tasks, coroutines, functions, attributes, procedures, drivers, firmware, data, databases, data structures, Application Specific Integrated Circuits (ASIC) and other computing devices. A module may reside on a volatile or nonvolatile storage medium and configured to interact with a processor of computing device 100.
[0011] Computing device 100 generally represents any type of computing system capable of reading machine-executable instructions. Examples of computing device 100 may include, without limitation, a server, a desktop computer, a notebook computer, a tablet computer, a thin client, a mobile device, a personal digital assistant (PDA), a phablet, and the like.
[0012] The term "file", as used herein, may include a computer or digital file.
Generally speaking, each piece of data on a storage device may be called a "file". Each file may be called by a filename. File 102 may contain data, such as text files, image files, video files, database files, and the like, or it may be an executable file or program.
[0013] A computer file or "file" is the basic component of a file system. The file system provides the underlying structure that a computing device uses to organize data on a storage medium. Files may be organized by storing related files in a directory or sub-directory. A directory or sub-directory is also a file. The term "directory" (or "file directory), as used herein, may include a file that contains references (for example, names) to other files. Thus, a directory may be considered as a container for files. [0014] In an example, file 102 may be a part of a local file system. In another example, file 102 may be component of a scale-out file system such as a shared file system or network file system. Examples of a shared file system may include a Network Attached Storage (NAS) file system or cluster file system. Examples of a network file system may include a distributed file system or distributed parallel file system.
[0015] In an example, file 102 may be stored on computing device 100. In some examples, file 102 may be stored on a machine-readable storage medium remote from but accessible to computing device 100, for example, via a computer network. Such a computer network may be a wireless or wired network. The computer network may include, for example, a Local Area Network (LAN), a Wireless Local Area Network (WAN), a Metropolitan Area Network (MAN), a Storage Area Network (SAN), a Campus Area Network (CAN), or the like. Further, the computer network may be a public network (for example, the Internet) or a private network (for example, an intranet).
[0016] File 102 may be associated with one or more extended attributes. In an example, an extended attribute associated with file 102 may include four parameters: name of the extended attribute, value assigned to the extended attribute, a User ID (UID) and a Group ID (GID). In other words, the extended attribute may be a quadruplet comprising four parameters (i.e. name, value, UID, GID). In an example, an extended attribute of file 102, with all associated parameters, may be stored in a separate file. In an instance, such file may be a sequential file. Although only one file is illustrated in FIG. 1 , in other examples, a plurality of files may be present.
[0017JA User ID may provide identification information of a user. In an example, a User ID (UID) associated with an extended attribute of a file may include identification information of a user who created the file. In another example, a User ID (UID) associated with an extended attribute of a file may include identification information of a user who created the extended attribute. In another example, a User ID (UID) associated with an extended attribute of a file may include identification information of a user who was last to modify the extended attribute.
[0018] In an example file system, each user may be assigned to some group.
Each group may be assigned a unique Group ID that may provide identification information of a group. Users (or User IDs) assigned to the same group may share rights. For instance, all users in a group may be allowed to modify contents of a particular file. In an example, a Group ID (GID) associated with an extended attribute of a file may include identification information of a group that a user, who created the file, belongs to. In another example, a Group ID (GID) associated with an extended attribute of a file may include identification information of a group that a user, who created the extended attribute, belongs to. In another example, a Group ID (GID) associated with an extended attribute of a file may include identification information of a group that a user, who was last to modify the extended attribute, belongs to.
[0019] In an example, storage quotas may be defined for each User ID and Group ID. Such storage quota may define the amount of storage space that may be used by a particular User ID or Group ID.
[0020] Recognition module 104 may recognize a user action regarding an extended attribute of a file (for example, file 102). In other words, if a user performs an action related to an extended attribute of a file (for example, file 102), the recognition module 104 may identify that action. For example, if a user creates or sets an extended attribute of a file (for example, file 102), the recognition module may recognize such user action. Similarly, if a user deletes an extended attribute of a file (for example, file 102), the recognition module 104 may realize such user action. Likewise, if a user modifies an extended attribute of a file (for example, file 102), the recognition module 104 may recognize such user action. [0021] Determination module 106 may determine a user ID (UID) and a group ID (GID) of a user who requests a user action regarding an extended attribute of a file (for example, 102). In an example, determination module 106 may perform such determination from the command or process used by a user requesting a user action related to an extended attribute of a file (for example, 102).
[0022] Charge module 108 may charge storage affected by the user action towards respective storage quotas allocated to the UID and the GID of the user. In other words, if a user action related to an extended attribute of a file (for example, file 102) impacts storage space (for example, on a storage disk), charge module 108 may charge the storage impacted by such user action against storage quotas that are assigned to the UID and the GID of the user. For example, if the user action includes generation of an extended attribute, charge module 108 may reduce the respective storage quotas allocated to the UID and the GID of the user, corresponding to storage used pursuant to generation of the extended attribute. In other words, if a user action regarding an extended attribute leads to consumption of storage space, charge module 108 may charge such use against the UID and the GID of the user who performed the action, and reduce the storage quotas of such UID and GID with an amount equivalent to the consumed storage space.
[0023] In another example, if the user action includes deletion of an extended attribute, charge module 108 may increase the respective storage quotas allocated to the UID and the GID of the user, corresponding to storage released consequent to deleting the extended attribute. In other words, if a user action regarding an extended attribute leads to release of storage space, charge module 108 may charge such use against the UID and the GID of the user who performed the action, and increase the storage quotas of such UID and GID with an amount equivalent to the released storage space. [0024] In an example, storage space charged against a UID and/or GID of a user consequent to a user action related to an extended attribute may be recorded in a B-tree. B-tree may be a tree data structure that keeps data sorted and allows searches, sequential access, insertions, and deletions. B- tree may be construed as a generalization of a binary search tree in that a node may have more than two children. In an example, a per-file B-tree may be maintained that may contain UIDs and GIDs of all users who may have set, modified, or deleted an extended attribute related to a file (for example, file 102). Such B-tree may be termed as "Quota B-tree". In an example, such B-tree may also provide information related to storage quota charged against UID and GID of all users who may have set, modified, or deleted an extended attribute related to the file. In an instance, a storage quota charged against a UID and GID of a user may be defined in the form of a "bytes_consumed" field that may be stored along with the UID and GID of the user in the Quota B-tree.
[0025] In an example, if a user sets an extended attributed, charge module 108 may search the UID and GID of the user in the Quota B-tree, and the storage space consumed as a result of user action may be charged against the storage of the UID and GID of the user. On the other hand, if a user deletes an extended attributed, charge module may search the UID and GID of the user in the Quota B-tree, and the storage space released as a result of user action may be charged against the storage of the UID and GID of the user. In a scenario where a user "A" may modify an extended attribute set by user "B", the storage quota against UID and GID of user "B" may be decremented by the previous size of the extended attribute. In other words, in such case, charge module may release the storage impacted by the user action towards respective storage quotas allocated to the UID and the GID of a previous user (i.e. user "B"). On the other hand, the storage quota against UID and GID of user "A" may be incremented by the new size of the extended attribute. [0026] In an example, determination module 106 may determine if a UID and GID of a user along with respective storage quotas are defined in Quota B- tree. If the UID and GID of the user along with respective storage quotas are not defined in Quota B-tree, determination module 106 may insert the UID and GID of the user along with respective storage quotas in the Quota B- tree. On the other hand, if the UID and the GID of the user along with respective allocated storage quotas are defined in the Quota B-tree, charge module 108 may charge storage impacted by a user action related to an extended attribute, towards respective storage quotas allocated to the UID and GID of the user in the Quota B-tree.
[0027] FIG. 2 is a block diagram of an example computing device 200 for charging a user's storage quota for extended attributes. Computing device 200 may be analogous to computing device 100, in which like reference numerals correspond to the same or similar, though perhaps not identical, components. For the sake of brevity, components or reference numerals of FIG. 2 having a same or similarly described function in FIG. 1 are not being described in connection with FIG. 2. Said components or reference numerals may be considered alike.
[0028] Computing device 100 may include a file 102, a recognition module 104, a determination module 106, a charge module 108, and a hash module 1 10.
[0029] In an example, the extended attributes related to a file (for example, 102) may be stored in a B+ tree. B+ tree may consist of a root, internal nodes and leaves. The root may be either a leaf or a node with two or more children. Each node of the tree may contain an ordered list of keys and pointers to lower level nodes in the tree. In an example, the name of an extended attribute may be used as a key for the B+ tree. The name of the extended attribute may be hashed and inserted into the B+ tree. Each node of the B+ tree may include a node header and a plurality of node elements. Each node element may store the hash of an extended attribute's name and an offset. The offset provides the location in a file where the unhashed extended attribute's name and value may be stored. In an example, a sequential file may store such details.
[0030] In an example, hash module 1 10 may generate, upon recognition of a user action related to an extended attribute of a file (for example, file 102), a hash of name of the extended attribute. Hash module 1 10 may then determine whether the hash is present in the B+ Tree. In response to the determination that the hash is not present in the B+ Tree, hash module may insert the hash and an offset in a node of the B+ Tree. The offset may provide the location of: name of the extended attribute, value of the extended attribute, a U ID and a GID of the user who performed the user action, in a file that stores the extended attribute. On the other hand, if it is determined that the hash is present in the B+ Tree, the determination module 106 may use the offset to obtain the UID and the GID of the user from the file that stores the extended attribute. Charge module 108 may then use the UID and the GID of the user to charge storage affected by the user action towards respective storage quotas allocated to the UID and the GID of the user.
[0031] In an instance, if an extended attribute is deleted by a user action, the hashed name of the extended attribute may be removed from the B+ tree, and the record related to the extended attribute may be marked as deleted from the file where it was stored. For efficient management of free spaces in the file that stores the extended attribute, the offsets containing free spaces may be stored in another B+ tree, which may be called as "free space B+ tree". The free space B+ tree may be indexed by the length of free space. A node element of this tree may store the value of the offset in the file where a free space lies.
[0032] FIG. 3 is a flowchart of an example method of charging a user's storage quota for extended attributes. The method 300, which is described below, may at least partially be executed on computing devices 100 and 200 of FIGS. 1 and 2, respectively. However, other computing devices may be used as well. At block 302, a user action regarding an extended attribute of a file (for example, file 102) may be recognized. At block 304, a user ID (UID) and a group ID (GID) of the user requesting the user action may be determined. At block 306, storage impacted by the user action may be charged towards respective storage quotas allocated to the UID and the GID of the user. In an example, if the user action includes generating the extended attribute, charging storage impacted by the user action towards respective storage quotas of the UID and the GID of the user may comprise reducing the respective storage quotas of the UID and the GID of the user, corresponding to storage used for generation of the extended attribute. In another example, if the user action includes deleting the extended attribute, charging storage impacted by the user action towards respective storage quotas of the UID and the GID of the user may comprise increasing the respective storage quotas allocated to the UID and the GID of the user, corresponding to storage released consequent to deleting the extended attribute. In some examples, the method may determine storage impacted by a user action related to the extended attribute by a previous user, and increase storage quotas allocated to a UID and a GID of the previous user, corresponding to the impacted storage. 33] FIG. 4 is a block diagram of an example computer system 400 for charging a user's storage quota for extended attributes. System 400 includes a processor 402 and a machine-readable storage medium 404 communicatively coupled through a system bus. In an example, system 400 may be analogous to computing device 100 of FIG. 1 . Processor 402 may be any type of Central Processing Unit (CPU), microprocessor, or processing logic that interprets and executes machine-readable instructions stored in machine-readable storage medium 404. Machine-readable storage medium 404 may be a random access memory (RAM) or another type of dynamic storage device that may store information and machine-readable instructions that may be executed by processor 402. For example, machine- readable storage medium 404 may be Synchronous DRAM (SDRAM), Double Data Rate (DDR), Rambus DRAM (RDRAM), Rambus RAM, etc. or a storage memory media such as a floppy disk, a hard disk, a CD-ROM, a DVD, a pen drive, and the like. In an example, machine-readable storage medium 404 may be a non-transitory machine-readable medium. Machine- readable storage medium 404 may store instructions 406, 408, and 410. In an example, instructions 406 may be executed by processor 402 to recognize a user action regarding an extended attribute of a file (for example, file 102). Instructions 408 may be executed by processor 402 to determine whether a user ID (UID) and a group ID (GID) of user requesting the user action is present in a B-tree. In response to the determination that the UID and the GID of the user is present in the B-tree, instructions 410 may be executed by processor 402 to charge storage impacted by the user action towards respective storage quotas assigned to the UID and the GID of the user in the B-tree. 34] For the purpose of simplicity of explanation, the example method of FIG. 3 is shown as executing serially, however it is to be understood and appreciated that the present and other examples are not limited by the illustrated order. The example systems of FIGS. 1 , 2 and 4, and method of FIG. 3 may be implemented in the form of a computer program product including computer-executable instructions, such as program code, which may be run on any suitable computing device in conjunction with a suitable operating system (for example, Microsoft Windows, Linux, UNIX, and the like). Embodiments within the scope of the present solution may also include program products comprising non-transitory computer-readable media for carrying or having computer-executable instructions or data structures stored thereon. Such computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer. By way of example, such computer-readable media can comprise RAM, ROM, EPROM, EEPROM, CD-ROM, magnetic disk storage or other storage devices, or any other medium which can be used to carry or store desired program code in the form of computer-executable instructions and which can be accessed by a general purpose or special purpose computer. The computer readable instructions can also be accessed from memory and executed by a processor. 35] It should be noted that the above-described examples of the present solution is for the purpose of illustration only. Although the solution has been described in conjunction with a specific embodiment thereof, numerous modifications may be possible without materially departing from the teachings and advantages of the subject matter described herein. Other substitutions, modifications and changes may be made without departing from the spirit of the present solution. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and/or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and/or steps are mutually exclusive.

Claims

Claims:
1 . A method of charging a user's storage quota for extended attributes, comprising:
recognizing a user action regarding an extended attribute of a file;
determining a user ID (UID) and a group ID (GID) of user requesting the user action; and
charging storage impacted by the user action towards respective storage quotas allocated to the UID and the GID of the user.
2. The method of claim 1 , wherein if the user action includes generating the extended attribute, charging comprises reducing the respective storage quotas allocated to the UID and the GID of the user, corresponding to storage used pursuant to generation of the extended attribute.
3. The method of claim 1 , wherein if the user action includes deleting the extended attribute, charging comprises increasing the respective storage quotas allocated to the UID and the GID of the user, corresponding to storage released consequent to deleting the extended attribute.
4. The method of claim 1 , further comprising storing the UID and the GID of the user as part of the extended attributed of the file.
5. The method of claim 1 , further comprising:
determining storage impacted by a user action related to the extended attribute by a previous user; and
increasing storage quotas allocated to a UID and a GID of the previous user, corresponding to the impacted storage.
6. A system to charge a user's storage quota for extended attributes, comprising: a recognition module to recognize a user action to create, modify, or delete an extended attribute of a file;
a determination module to determine a user ID (UID) and a group ID (GID) of user requesting the user action; and
a charge module to charge storage used or released consequent to the user action towards respective storage quotas allocated to the UID and the GID of the user.
7. The system of claim 6, further comprising a hash module to:
generate, upon recognition of the user action regarding the extended attribute of the file, a hash of name of the extended attribute;
determine whether the hash is present in a B+ tree; and
in response to the determination that the hash is not present in the B+ tree, insert the hash and an offset in a node of the B+ tree, wherein the offset provides location of: the name of the extended attribute, value of the extended attribute, the UID and the GID of the user in a file.
8. The system of claim 7, further comprising:
in response to the determination that the hash is present in the B+ tree, the determination module to obtain the UID and the GID of the user from the file.
9. The system of claim 6, wherein the determination module is to:
determine if the UID and the GID of the user along with respective storage quotas are defined in a B tree; and
if the UID and the GID of the user along with respective storage quotas are not defined in a B tree, insert the UID and GID of the user along with respective storage quotas in the B tree.
10. The system of claim 8, wherein if the UID and the GID of the user along with respective allocated storage quotas are defined in the B tree, charge module to charge storage impacted by the user action towards respective storage quotas allocated to the UID and the GID of the user in the B tree.
1 1 . A non-transitory machine-readable storage medium comprising instructions to charge a user's storage quota for extended attributes, the instructions executable by a processor to:
recognize a user action regarding an extended attribute of a file;
determine whether a user ID (UID) and a group ID (GID) of user requesting the user action is present in a B tree; and
in response to the determination that the UID and the GID of the user is present in the B tree, charge storage impacted by the user action towards respective storage quotas assigned to the UID and the GID of the user in the B tree.
12. The storage medium of claim 1 1 , wherein if the user action includes creation of the extended attribute, the instructions to charge comprise instructions to:
reduce the respective storage quotas assigned to the UID and the GID of the user in the B tree, equivalent to storage used further to the creation of the extended attribute.
13. The storage medium of claim 1 1 , wherein if the user action includes deletion of the extended attribute, the instructions to charge comprise instructions to:
increase the respective storage quotas assigned to the UID and the GID of the user, equivalent to storage released consequent to the deletion of the extended attribute.
14. The storage medium of claim 1 1 , further comprising instructions to: in response to the determination that the UID and the GID of the user is not present in the B tree, add the UID and the GID of the user, along with respective assigned storage quotas, in the B tree.
15. The storage medium of claim 1 1 , further comprising instructions to: determine storage impacted by a user action related to the extended attribute by a previous user; and increase storage quotas allocated to a UID and a GID of the previous user, corresponding to the impacted storage, in the B tree.
PCT/US2015/022793 2015-01-29 2015-03-26 Charging a user's storage quota for extended attributes WO2016122688A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
IN423CH2015 2015-01-29
IN423/CHE/2015 2015-01-29

Publications (1)

Publication Number Publication Date
WO2016122688A1 true WO2016122688A1 (en) 2016-08-04

Family

ID=56544097

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2015/022793 WO2016122688A1 (en) 2015-01-29 2015-03-26 Charging a user's storage quota for extended attributes

Country Status (1)

Country Link
WO (1) WO2016122688A1 (en)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5946686A (en) * 1997-07-11 1999-08-31 International Business Machines Corporation Parallel file system and method with quota allocation
US20030028514A1 (en) * 2001-06-05 2003-02-06 Lord Stephen Philip Extended attribute caching in clustered filesystem
US20040267827A1 (en) * 2003-06-30 2004-12-30 International Business Machines Corporation Method, apparatus, and program for maintaining quota information within a file system
US20070088760A1 (en) * 2003-08-08 2007-04-19 Jun Okitsu Method of controlling total disk usage amount in virtualized and unified network storage system
US20090119304A1 (en) * 2002-01-30 2009-05-07 Red Hat, Inc. Metadata structures and related locking techniques to improve performance and scalability in a cluster file system

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5946686A (en) * 1997-07-11 1999-08-31 International Business Machines Corporation Parallel file system and method with quota allocation
US20030028514A1 (en) * 2001-06-05 2003-02-06 Lord Stephen Philip Extended attribute caching in clustered filesystem
US20090119304A1 (en) * 2002-01-30 2009-05-07 Red Hat, Inc. Metadata structures and related locking techniques to improve performance and scalability in a cluster file system
US20040267827A1 (en) * 2003-06-30 2004-12-30 International Business Machines Corporation Method, apparatus, and program for maintaining quota information within a file system
US20070088760A1 (en) * 2003-08-08 2007-04-19 Jun Okitsu Method of controlling total disk usage amount in virtualized and unified network storage system

Similar Documents

Publication Publication Date Title
US10754878B2 (en) Distributed consistent database implementation within an object store
US10223544B1 (en) Content aware hierarchical encryption for secure storage systems
US9576071B2 (en) Graph-based data models for partitioned data
US7228299B1 (en) System and method for performing file lookups based on tags
US20190026301A1 (en) File system that supports both case sensitive and case insensitive directory lookup
CN103607405B (en) A kind of cipher text searching authentication method of facing cloud storage
WO2019000979A1 (en) File system access rights configuration method and device
US10742633B2 (en) Method and system for securing data
EP3561636A1 (en) Record level data security
CN104123359A (en) Resource management method of distributed object storage system
US10417181B2 (en) Using location addressed storage as content addressed storage
US20180189301A1 (en) Managing appendable state of an immutable file
US11086995B2 (en) Malware scanning for network-attached storage systems
US20180210950A1 (en) Distributed file system with tenant file system entity
US8510350B2 (en) Methods and apparatus for distinguishing files from one another in a file system in a computing environment
US20160149925A1 (en) Systems and methodologies for controlling access to a file system
WO2016122688A1 (en) Charging a user's storage quota for extended attributes
WO2016130167A1 (en) Consistency check on namespace of an online file system
US20190340359A1 (en) Malware scan status determination for network-attached storage systems
US10521405B2 (en) Policy and configuration data for a user directory
US11016933B2 (en) Handling weakening of hash functions by using epochs
JP5783010B2 (en) Index management program, index management device, and search system
WO2016118176A1 (en) Database management
US20180367313A1 (en) Secure memory and hierarchical structure and system therefor
WO2017007496A1 (en) Managing a database index file

Legal Events

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

Ref document number: 15880578

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15880578

Country of ref document: EP

Kind code of ref document: A1