Today's computers require memory to hold or store both the steps or instructions of programs and the data that those programs take as input or produce as output. This memory is conventionally divided into two types, primary storage and secondary storage. Primary storage is that which is immediately accessible by the computer or microprocessor, and is typically though not exclusively used as temporary storage. It is, in effect, the short term memory of the computer.
Similarly, secondary storage can be seen as the long-term computer memory. This form of memory maintains information that must be kept for a long time, and may be orders of magnitude larger and slower. Secondary memory is typically provided by devices such as magnetic disk drives, optical drives, and so forth. These devices present to the computer's operating system a low-level interface in which individual storage subunits may be individually addressed. These subunits are often generalized by the computer's operating system into “blocks,” and such devices are often referred to as “block storage devices.”
Block storage devices are not typically accessed directly by users or (most) programs. Rather, programs or other components of the operating system organize block storage in an abstract fashion and make this higher-level interface available to other software components. The most common higher-level abstraction thus provided is a “filesystem.” In a filesystem, the storage resource is organized into directories, files, and other objects. Associated with each file, directory, or other object is typically a name, some explicit/static metadata such as its owner, size, and so on, its contents or data, and an arbitrary and open set of implicit or “dynamic” metadata such as the file's content type, checksum, and so on. Directories are containers that provide a mapping from directory-unique names to other directories and files. Files are containers for arbitrary data. Because directories may contain other directories, the filesystem client (human user, software application, etc.) perceives the storage to be organized into a quasi-hierarchical structure or “tree” of directories and files. This structure may be navigated by providing the unique names necessary to identify a directory inside another directory at each traversed level of the structure; hence, the organizational structure of names is sometimes said to constitute a “filesystem namespace.”.
Filesystems support a finite set of operations (such as create, open, read, write, close, delete, etc.) on each of the abstract objects which the filesystem contains. For each of these operations, the filesystem takes a particular action in accordance with the operation in question and the data provided in the operation. The sequence of these operations over time affects changes to the filesystem structure, data, and metadata in a predictable way. The set of filesystem abstractions, operations, and predictable results for particular actions is said to constitute a “semantics” for the filesystem. While particular filesystems differ slightly in their precise semantics, in general filesystems implement as a subset of their full semantics a common semantics. This approximately equivalent common semantics can be regarded as the “conventional” or “traditional” filesystem semantics. Storage resources accessed by some computer, its software or users need not be “directly” attached to that computer. Various mechanisms exist for allowing software or users on one computing device to access over a network and use storage assets that are actually located on another remote computer or device. There are many types of remote storage access facilities, but they may without loss of generality be regarded to fall into one of two classes: block-level and file-level. File-level remote storage access mechanisms extend the filesystem interface and namespace across the network, enabling clients to access and utilize the files and directories as if they were local. Such systems are therefore typically called “network file systems,” which may refer to the aggregation of more than one type of filesystem, Note that the term “network file system” is used herein generally to refer to all such systems—there is a network file system called Network File System or NFS, originally developed at Sun Microsystems and now in the public domain. When discussing the general class of such systems herein, the lower-case term, e.g., “networked file systems” will be used. When discussing the specific Sun-developed networked file system, the fully capitalized version of the term or its acronym, e.g., “Network File System or NFS” will be used.
Networked file systems enable machines to access filesystems that reside on other machines. Architecturally, this leads to the following distinctions: in the context of a given filesystem, one machine plays the role of a filesystem “origin server” (alternatively, “fileserver” or “server”) and another plays the role of a filesystem client. The two are connected via a data transmission network. The client and server communicate over this network using standardized network protocols; the high-level protocols which extend the filesystem namespace and abstractions across the network are referred to as “network filesystem protocols.” Exemplary filesystem protocols include the Common Internet File System (CIFS), the aforementioned NFS, Novell's Netware filesharing system, Apple's Appleshare, the Andrew File System (AFS), and the Coda Filesystem (Coda). CIFS and NFS are by far the most prevalent. These network filesystem protocols share an approximately equivalent semantics and set of abstractions, but differ in their details and are noninteroperable. Thus, to use a filesystem from a fileserver, a client must “speak the same language,” i.e., have software that implements the same protocol that the fileserver uses.
A fileserver indicates which portions of its filesystems are available to remote clients by defining “exports” or “shares.” To access a particular remote fileserver's filesystems, a client must then make those exports or shares of interest available by including them by reference as part of their own filesystem namespace. This process is referred to as “mounting” or “mapping (to)” a remote export or share. By mounting or mapping, a client establishes a tightly coupled relationship with the particular file server. The overall architecture can be characterized as a “two-tier” client-server system, since the client communicates directly with the server which “has” the resources of interest to the client.
In addition to organizing and maintaining the relationships between filesystem clients and file servers, additional challenges exist in managing access to and utilization of filesystems. While most organizations have and enforce stringent document workflow and retention policies for their paper files, similar policies—while desired and mandated—are rarely enforced for electronic files. As a non-limiting example, many corporations have a policy that prohibits the usage of corporate storage capacity on fileservers for the storage of certain personal files and content types, for instance, MP3s, personal digital images, and so on. This “policy” usually takes the form of a memo, email, etc. The administrators in charge of enforcing this policy face significant challenges. Conventional filesystems do not provide mechanisms for configuring a filesystem to only allow particular content types or otherwise make decisions about what should be stored, where, and how. These conventional filesystems are static, and the set of semantics for access and other administrative controls are rather limited. Thus any such policy enforcement that happens is done retroactively and in an ad-hoc manner via manual or mostly-manual processes. The net result is that network file storage fills up with old, duplicated, and garbage files that often violate corporate and administrative utilization policies.
In today's increasingly litigious environment and in the presence of new rules and regulations such as the Health Insurance Portability and Accountability Act of 1996 (HIPAA) and the Sarbanes-Oxley Act of 2002, the lack of management, including the inability to enforce policies consistently and effectively, represents a serious risk that corporations and businesses alike must rush to address. Unfortunately, as a direct result of the general lack of innovation and improvement in filesystem architecture over the last 30 years, viable solutions that could provide practical and effective policy management to enterprises do not seem to exist.
Perhaps a general comparison between typical databases systems and typical filesystems will serve to illustrate the previous lack of innovation and improvement in filesystem architecture. For databases, storage is usually organized into tables arranged in a flat space (i.e., tables may not be contained in other tables) which contain records with generally fixed form. Such database systems often provide a notion of “triggers” and “stored procedures.” Triggers define a set of conditions; when the database is manipulated in a way that matches some condition, the stored procedure associated with that trigger is executed, potentially modifying the transaction or operation. This mechanism is used primarily in two ways in database applications: to ensure data correctness and integrity and to automate certain administrative and application-specific tasks. The analogous facility is not available in filesystems because filesystems are quasi-hierarchical collections of directories and files. As such, triggers cannot be defined with associated stored procedures that can be automatically activated and enacted synchronous with a filesystem activity in any extant filesystem.
In general, implementation of triggers and stored procedures in filesystems is significantly more complex than in databases systems because of less regular structure of filesystems, their less formally well-defined semantics, and because file data is itself arbitrarily semi-structured and loosely typed. Implementation of programmable procedures which respond to an arbitrary filesystem operation by modifying the operation is challenging when the correct (i.e., traditional, expected, etc.) semantics of filesystems must be preserved. There are existing systems that will generate “events” when operations occur on the filesystem; these events can then be used to activate arbitrary actions post-facto. However, the actions cannot themselves modify the file operation, since the event which activates them is not generated until the triggering operation completes.
Currently, the “intelligence” that a conventional filesystem exhibits with respect to access control is typically restricted to a static set of rules defining file owners, permissions, and access control lists. To the extent even this relatively low level of “intelligence” exists, it is usually statically defined as a part of the filesystem implementation and may not be extended.
In part, this is because in a typical enterprise, the files and directories stored in the enterprise filesystems represent unstructured or semi-structured business intelligence, which comprises the work product and intellectual property produced by its knowledge workers. The work product may include business-critical assets and may range from Excel spreadsheets representing (collectively) the financial health and state of the enterprise to domain-specific artifacts such as Word documents representing memos to customers. However, in contrast to the data stored in “mission critical” information systems such as logistics systems, inventory systems, order processing systems, customer service systems, and other “glass house” applications, the unstructured and semi-structured information stored in the enterprise filesystems is largely “unmanaged.” It is perhaps backed up but little or no effort is made to understand what the information is, what its relevance or importance to the business might be, or even whether it is appropriately secured.
As examples, assuming that a user ‘Idunno’ has stored unauthorized and illegal copies of MP3 music files in a “home directory” on some file server that belong to a corporation ‘Big Corp’ where Idunno works. In doing so, Idunno has perhaps violated a corporate policy of Big Corp stating that no MP3 files are to be stored on the network. However, since the “home directory” is not visible to the system managers, the system managers have no knowledge to this violation, nor any automated means of remedying the situation. Even in the event that the system managers are able to episodically inventory the filesystems for such violators, they are often loathe to automatically take appropriate actions (e.g., deleting) on such offending files. The reason is that, more often than not, while they have the responsibility for enforcing such policies, they do not have the authority to do so. To remedy this, the end-user (i.e., the file owner—in this example, Idunno) or some other responsible party must be brought “into the loop.” Other examples of file management policies might include: documents relating to patients' individual medical conditions within a healthcare provider business might be stored in such a way that perhaps would violate the privacy constraints of HIPAA; or financial documents within the finance operation of a Fortune 2000 company might be stored in such a way that perhaps would violate both regulatory requirements under the Sarbanes-Oxley Act of 2002 and internal corporate governance considerations.
The pressing need to monitor filesystems and to report activities related to the filesystems presents a challenge of unprecedented scope and scale on many fronts. Filesystem activity produces changes to the state of a filesystem. This activity can affect changes to the structure, the stored metadata, and the stored data of the directories and files. Generally speaking, this activity is not logged in any way; rather, the filesystem itself holds its current state. Some filesystems—called “journaling” filesystems—maintain transient logs of changes for a short duration as a means of implementing the filesystem itself; however, these logs are not typically organized in any way conducive to monitoring and reporting on the state of the filesystem and its activity and are not made available to external programs for that purpose. Further, these logs are frequently purged and therefore provide a poor basis for reporting of historical and trend data.
One significant and open problem is that of collection, redaction, and analysis of high-level data about what a filesystem is being used for, what is stored in it, by whom and for what purpose. Solutions today involve software programs or users explicitly walking through the filesystem structure, gathering the data required, and then analyzing it and/or acting on it, etc. Collection of filesystem data proactively as operations occur is generally not done as it is generally not supported by the filesystem itself. Furthermore, the accuracy of such collected data is usually questionable, as it reflects not an instantaneous state of the filesystem at any given moment, but, rather, an approximate state of the filesystem over the duration of the run. Without collecting and maintaining the appropriate statistics as file operations occur, it is impossible for the data, at the end of the run, to represent a correct and accurate picture of the contents of the filesystem at that time.
Collection and storage of all such data as it occurs could also be untenably burdensome; such logs would “grow” quickly and consume additional storage capacity at an undesirable rate. The ability to both collect such data as it occurs and dynamically redact or “historize” it would allow ongoing statistics to be maintained while simultaneously constraining the total amount of storage capacity that must be dedicated to such a purpose.
The problem of data collection and reporting is further compounded in a networked filesystem environment. Because each server—indeed, each filesystem on each server—is a separate entity, it is therefore necessary to perform each data collection independently on each server. If reporting or monitoring is to be done across the network filesystem environment, significant challenges exist; namely, because of the parallel and discrete nature of the collection runs, it becomes difficult or impossible to sensibly merge the collected data into a consistent snapshot of the state of the filesystem at some time.
This is particularly true with respect to collecting data pertaining to a certain users across a myriad number of filesystems which may exist in a networked filesystem environment. In order to bring an end-user “into the loop” with respect to the policies implemented by a particular organization it is highly desirable to be able to identify an end-user with objects residing in the networked filesystem environment. However, this may be a difficult task. As discussed above the networked filesystem environment may be composed of a number of heterogenous types of filesystems, and, additionally, a single end-user may have different user identities associated with one or more of these filesystems.
Returning to the end-user “Idunno” of the above example, on one particular filesystem (a particular NFS filesystem in the networked filesystem environment, for example) end-user Idunno's user identification may be “I_Dunno”, while in another filesystem Idunno's user identification may be “Idunnojack”. Thus, to associate objects across a networked filesystem with a single user in order to involve a user with policy implementation may be difficult, as it may be difficult to identify an end-user associated with a file on which a policy is, or should be, implemented.
As can be seen then, it is desirable to have systems and methods which may allow the identification of objects in disparate and heterogeneous filesystems with a single user, and which may furthermore allow these users to be involved in policy implementation with respect to these, or other, objects.
USPTO Backgrounds
USPTO Backgrounds