EP1977348A1 - Système de fichiers structuré par événements - Google Patents

Système de fichiers structuré par événements

Info

Publication number
EP1977348A1
EP1977348A1 EP07701720A EP07701720A EP1977348A1 EP 1977348 A1 EP1977348 A1 EP 1977348A1 EP 07701720 A EP07701720 A EP 07701720A EP 07701720 A EP07701720 A EP 07701720A EP 1977348 A1 EP1977348 A1 EP 1977348A1
Authority
EP
European Patent Office
Prior art keywords
event
file
file system
directory
esfs
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.)
Withdrawn
Application number
EP07701720A
Other languages
German (de)
English (en)
Other versions
EP1977348A4 (fr
Inventor
Graham Douglas Irving
Robert Jeffrey Ellestad
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
EL FRESKO TECHNOLOGIES LIMITED
Original Assignee
Titan Digital Corp
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
Priority claimed from CA2534170A external-priority patent/CA2534170C/fr
Application filed by Titan Digital Corp filed Critical Titan Digital Corp
Publication of EP1977348A1 publication Critical patent/EP1977348A1/fr
Publication of EP1977348A4 publication Critical patent/EP1977348A4/fr
Withdrawn legal-status Critical Current

Links

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/16—File or folder operations, e.g. details of user interfaces specifically adapted to file systems

Definitions

  • the present invention relates generally to computers and file systems.
  • Computer file systems have traditionally involved some mechanism of data storage at a physical location (for instance, a disk sector) and a lookup table or index of some sort identifying the data and its physical address (or a logical address from which that may be inferred).
  • the tables are implemented in various forms, and generally require the ability to overwrite or update previous table entries as file system additions and changes occur.
  • Event - a data structure existing within the file system indicating a specific type of change or addition to the file system.
  • File system - is a means to organize, store, process, retrieve and manage information/data using a storage medium of any type.
  • Metadata file system information that holds information describing and relating the user file system objects, files and directories.
  • the list of Events for a file system are its metadata. Metadata is not directly accessible to users.
  • Object an entity, such as a file or directory within a File System
  • table based file systems are the Unix File System (UFS) and its' associated directory tables and inodes, Windows FAT16, FAT32 (“File Allocation Table”) file systems, and Windows NTFS, based on Master File Tables.
  • UFS Unix File System
  • Windows FAT16 FAT32
  • FAT32 File Allocation Table
  • Windows NTFS based on Master File Tables.
  • Other file system designs extend existing file systems by adding joumaling and logging to improve reliability and recoverability, and file versioning.
  • Computer file systems generally fall into the following classes:
  • MFT Master File Table
  • Joumaling file systems (generally inode based, with separate journal)
  • Implementations of all of the above file systems require the ability to update or overwrite previously written metadata tables and data areas on the media, and are reliant upon rewritable tables, indexes, or inode maps.
  • MFT Master File Table
  • Joumaling file systems are designed to improve reliability and recoverability after a crash or failure affecting the system.
  • the journal component of such file systems records changes since a "checkpoint” or point in time at which the file system was known to be consistent, and to which it can be restored by reference to the recorded changes since "checkpoint".
  • the journal component typically reuses space that was allocated to it, and is not integral to the file system itself, other than for the purpose of improving reliability.
  • the journal's contents are generally limited to only those changes since the last checkpoint.
  • Versioning file systems maintain a file in its original form, and any subsequent changes are saved using the same file name and an incrementing version number.
  • the number of historical versions available is generally limited and application or implementation dependent.
  • the file's versions are generally implemented as "saves" of separate files with a naming convention for addressing specific different versions of the file in some sequence or order. These systems are generally implemented at a level closer to the user than the disk operating systems or low-level file systems to which this invention is directed.
  • Log-based file systems are perhaps the closest of the prior art to this invention.
  • Sprite and LFS as described in Mendel Rosenblum's and John K. Ousterhout's 24 July 1991 paper "The Design and Implementation of a Log-structured File System", published in the “Proceedings of the 13 th ACM Symposium on Operating System Principles” and the February 1992 "ACM Transactions on Computer Systems” (copy filed contemporaneously with this provisional application), are typical of this family of file systems, and are generally implemented using internal structures that are patterned after a conventional table-based file system, such as UFS.
  • the logging component records standard file system structures, such as inodes and directory entries, and adds a mapping table that describes the current location of all allocated inodes. The complete inode mapping table is then rewritten regularly to the end of the log, and is then used in a conventional manner to navigate the current file system structure.
  • the present invention is a method implementing a file system without table- based metadata, using instead a list or sequence of predefined Event types to describe the state, content, and complete history of the file system. This is useful
  • ESFS does not use any form of table within its' metadata to hold information describing the contents of the file system.
  • Table-based systems are entirely distinct from ESFS, which uses incremental updates to a sequenced Event list to reflect changes as they occur, and does not require any form of internal table whatsoever. Instead of tables or indexes (e.g. File
  • Events Allocation Tables or inodes of traditional file systems
  • ESFS uses a small set of predefined (but extensible) file system "Events".
  • a single Event is a data structure that generally describes a single file system operation (e.g. file or directory creation, file write, or file close, etc.) and if applicable, the location of data related to the Event. Events are linked or related together into sequences using one or more "pointers" contained within the Event. Several pointer types are used to build and navigate the file system. By navigating the file system's structure using the pointers contained in the Event descriptions, one can perform all necessary tasks to operate a file system with features and operations equivalent to traditional hierarchical file systems.
  • Features of the Event Structured File System include:
  • a basic ESFS implementation is very simple. Overhead for storing the Events is minimal. There is no requirement to prepare media or pre-allocate storage space for Events.
  • ESFS Ideal for implementing WORM applications: ESFS records file system changes as incremental Events in the sequence they occur, without overwriting previously written data. ESFS is thus ideally suited for use with applications that require WORM behaviour or media.
  • ESFS implementations can add custom Events types to add new features and controls.
  • Host independent ESFS is designed to be independent of the host system and is well suited for removable media implementations.
  • ESFS Self-auditing: ESFS is self-contained, and requires no additional tables, indexes or data bases are required in order to access contents of the file system. ESFS Events can be used to audit and produce historical journals of the contents and state of the file system at any time since its' creation time.
  • Sequential or Random Access storage devices and media Adaptable to all media types: WORM, erasable media, rewritable, and pre- mastered.
  • Secure Includes built-in tamper detection. ESFS can use both secure hash algorithms and encryption algorithms to ensure data integrity.
  • ESFS Built-in Versioning: ESFS tracks file and director versions, or revisions. This journal-like feature is built into the way Events are linked/related together, and reports can be inferred, generated or extracted.
  • Portability - file systems are binary compatible across all supported operating systems
  • Fast - data can be archived at very near the rated speed of the underlying hardware
  • Secure - ESFS provides mechanisms to detect tampering with file data or file system Metadata.
  • the EFSF may be briefly described as follows:
  • File system metadata including one or more Events, linked together in a fashion to completely describe, in aggregate with all other Event descriptions, the entire contents and structure of the file system.
  • ESFS functionality or features can be extended by enhancing or increasing Event types to permit, for example, customization of the ESFS for a particular application, security model, or Operating System ("OS”)
  • OS Operating System
  • ESFS can be implemented independently of the host computing hardware, operating system, storage device, or media. Because of it
  • ESFS Because of its' inherent portability, ESFS is very well suited for removable media and archival applications. 5. ESFS has a small implementation "footprint", and the logic and structure of the system is easy to understand.
  • file system implementations must make tradeoffs among media portability, media type, performance, security, verification, audit support, and robustness. It is an object of the present invention to obviate or mitigate at least one disadvantage of the previous art.
  • the ESFS of this invention may be consistently applied to all forms of erasable and write-once media, including physical devices and in-memory implementations.
  • the benefits of the method seem significant, in particular in applications where "Write once read many” ("WORM”) behaviors are useful or desirable or where the ability to authenticate the integrity of stored information is useful or desirable.
  • WORM Write once read many
  • FIG. 1 is a block diagram showing the relationships among ESFS events.
  • Fig. 2 is a block diagram showing the relationship between parts of an ESFS Volume Structure. Fig. 2
  • Block the smallest unit of storage addressable by an ESFS file system.
  • Block Address - a unique location identifier used to access a Block
  • Directory file system object that provides a way to name and organize multiple, related files. [For example, Users may perform the following file system operations on directories: Create, Delete, Rename, Get Info and List Files.] Endpoint - the most recent file or directory event location within a directory
  • Event - a data structure existing within the file system indicating a specific type of change or addition to the file system.
  • Event Address an Event Address specifies the location of a specific Event. It is comprised of a Block Address and a Block Offset, indicating the byte location of the Event within the Block.
  • File - a file system object that provides a way to store and recall data by name. Data within the file can be sequentially or randomly read and written. Users may, by example, perform the following file system operations: Create, Delete, Open, Close, Position, Read, Write, Rename, Set File Times, and Get Info.
  • File system - is a means to organize, store, process, retrieve and manage information/data using a storage medium of any type.
  • Metadata - file system information that holds information describing and relating the user file system objects, files and directories.
  • the list of Events for a file system are its metadata. Metadata is not directly accessible to users.
  • Offset - the number of bytes from the beginning of a Block to the beginning of an Event
  • Partition - a logical container with addressable Sectors that holds a file system, in whole or in part.
  • the present invention provides a File System comprising an ordered list of Events associated with Data, that may be implemented identically on all common digital storage media types, including write-once, erasable, and rewritable media, whether in sequential or random-access mode,(or otherwise).
  • the system uses the sequence and type of Event with its associated Data without reference to any external table or journal entry to operate and be verifiable.
  • the system's list of Events is accessible in a predefined sequence, normally, but not limited to, reverse chronological order.
  • ESFS includes an ordered list of Events associated with Data made verifiable in whole or in part by provision of checksums and security information within the
  • ESFS may be efficiently implemented using a "Write Once Read Many"
  • WORM WORM model
  • ESFS is made tamper-evident using checksums and security information on at least one of: Metadata and Data
  • Metadata and Data The method set out below describes how a file system may be structured and implemented using a small set of predefined set of Events, each of which describes an incremental change to the file system.
  • the Events such as creating or writing a file, form an ordered list that allows the exact state and contents of the file system to be known at any point in time. Events associated with a specific directory or file are logically linked as the file system grows.
  • the method is unique and represents a fundamental change in the way computer file systems are constructed.
  • Self-auditing means that the integrity of the file system (including the file system of this invention) can be assured without reference to an external or secondary information store, such as a journal or log file.
  • an external or secondary information store such as a journal or log file.
  • the list of Events and associated file data taken together are the file system and comprise its complete history since creation. No other information source is required either for normal use or for audit, integrity- checking, or tamper-evidencing.
  • ESFS Error-Fundor File System
  • ESFS requires only the ability to read and write specific storage blocks on a physical or electronic medium using reference to a unique identifier or block number associated with the storage block.
  • Event Structured File System includes:
  • a basic ESFS implementation is very simple. Overhead for storing the Events is minimal. There is no requirement to prepare media or pre-allocate storage space for Events.
  • ESFS Ideal for implementing WORM applications: ESFS records file system changes as incremental Events in the sequence they occur, without overwriting previously written data. ESFS is thus ideally suited for use with applications that require WORM behaviour or media.
  • Extensible Events can add custom Events types to add new features and controls.
  • ESFS Host independent: ESFS is designed to be independent of the host system and is well suited for removable media implementations.
  • ESFS Includes built-in tamper detection. ESFS can use both secure hash algorithms and encryption algorithms to ensure data integrity.
  • ESFS Built-in Versioning: ESFS tracks file and director versions, or revisions. This journal-like feature is built into the way Events are linked/related together, and reports can be inferred, generated or extracted.
  • Portability - file systems are binary compatible across all supported operating systems
  • Secure - ESFS provides mechanisms to detect tampering with file data or file system Metadata.
  • ESFS Concept is very flexible, and may be implemented on diverse hardware platforms, operating systems, and storage devices. Ignoring specific implementation issues, ESFS has the following minimum requirements for successful implementation and operation: a block addressable storage device.
  • Volume Structure Fig. 1 is a volume structure diagram of a file system based on this ESFS.
  • Components of the file system are:
  • File System Volume Label This item is optional and implementation dependent. It provides the host with a method of recognizing a specific ESF implementation on a storage medium.
  • File System Information Block (FSIB): This structure provides basic information describing the ESF file system, including volume size, geometry, and pointers to the logical addresses of the first Event and first data block. Depending on the implementation, the FSIB may also contain pointers to the logical address of the last Event and last data block.
  • Events Individual data structures that are linked together by pointers. For write-once applications, Events are reversed linked together using one more types of pointers. Examples of Events: Create Directory, Create File, Write Data, Remove File, etc.
  • Data logical blocks of file data; i.e., the contents of user files.
  • the data blocks are pointed to by "Data Events”.
  • volume Creation initializing storage medium with an empty, ready to use file system
  • FSVL File system Volume Label
  • FSVL File system Volume Label
  • FSIB File System Information Block
  • the FSIB will contain the necessary information to locate the first Event (First Event Address).
  • locate the last Event for the volume A preferred method is to locate the last Event by performing a binary search of the file system area to locate ESFS blocks with identifiers that match the FSIB identifiers.
  • the last Event should be an Unmount Event, indicating the last mount session was properly closed and that the basic file system's integrity is intact.
  • An ESFS pathname is a unique identifier assigned to a directory or file when it is created. After the file is created, the pathname can be used to access or update the directory or file.
  • ESFS pathnames may be implementation specific.
  • a common file system implementation is hierarchical, consisting of a top-level directory (the root directory), with zero or more file entries and subdirectory entries. Each file system entry below the root directory has a parent directory. Each file or directory entry has a unique name within its parent directory.
  • Pathnames for a specific file consist of one or more directory components, each separated by a pathname delimiter (for example 'T), followed by a filename. To access a specific file, a complete or absolute pathname may be used to navigate through all parent directory levels until the last filename component is reached.
  • Events The structure and contents of a file system constructed using the method is described by an ordered list of Events.
  • One or more Events are contained within a Block, where a Block consists of one or more physical storage Sectors. Each Block is addressable by a Block Address, and contains a unique signature that is associated with the volume's FSIB.
  • a specific Event is addressable by an Event Address, which contains both a Block Address and byte offset of the Event within the specified Block.
  • Events There are several different types of Events, each describing a single change to the file system, such as creating a file or directory, or writing to a file. Individual Events may be linked together by Event pointers to associate related Events and easily navigate through the file system.
  • the system of this invention uses several Event types that are considered Core Events that would typically be used by most implementations to create directories and files. Also described are Extended Events that would provide additional file system functionality, such as renaming or deleting files and directories, if required for a specific implementation. Space Events can be used to implement storage management for allocation and reclaiming of Blocks as files are created, written to, or deleted. ESFS Events are extensible, allowing the file system to easily grow and evolve while maintaining compatibility with earlier implementations. For example, "Security 1 ,
  • Stream Events could establish space limits within directories. "Stream" Events could associate multiple types of data streams with a specific file.
  • Link Pointers A link pointer is used to connect associated Events. That is, Events that are associated with one particular directory, file or list. The tables below express examples of possible connections among the Event types. For write-once implementations, link pointers will point to the last related Event (reverse linking), if one exists, otherwise it will be empty (nil). Rewritable implementations may choose reverse linking, forward linking, or both.
  • the method as described herein also demonstrates that all typical file system operations can be accomplished using ordered Events, without ever having to overwrite existing information.
  • Event tables below are organized “From:” rows and "To:” columns.
  • An Event in the "From:” column will point to an Event in the "To:” rows.
  • a Delete File Event may point to a Close File or Rename File Event; depending on which was the last to occur.
  • Events for a specific file may be related using Link and Parent pointers.
  • Related events may include file renaming or file deletion events, for example.
  • Directory Events are all linked to other related directory Events.
  • a related directory Event will have the identical Name field in each ESF Name structure.
  • a brother pointer points to the most recent file or directory Event that has the same parent directory.
  • a parent pointer points to the Create Directory Event of the parent directory, unless the parent directory is the root or top-level directory (T), in which case the parent pointer is empty (nil).
  • T top-level directory
  • a parent pointer points to a Close or Create Event, whichever is most recent.
  • ESFS Pathname Lookup is the process of navigating through the ESFS Events to locate the most recent file or directory Event associated with the pathname.
  • Each directory or file within ESFS has a unique pathname.
  • the pathname is first split into one or more components, where each component is separated by a pathname delimiter. Each component is then used to determine the existence of the component name in the corresponding directory level.
  • each component is a sequence of characters delimited by an implementation specific pathname delimiter character (T in the example), or the end of the string of characters, whichever comes first.
  • T implementation specific pathname delimiter character
  • the list of components is used below to navigate through the file system on directory level at a time (e.g. dirOOI , myfiles, mydoc, dod .txt). The search begins in the root directory with the first component of the path, "dirOOI".
  • Event is a Delete Directory, Rename Directory, Delete File, or Rename File Event, the search terminates in FAILURE.
  • ESFS creates links among associated Events as the file system grows
  • access to the last entry in an Event list (or "endpoint") is a frequently executed process.
  • Specific implementations may choose to incorporate an endpoint caching mechanism to reduce the time to access frequently referenced directories and add new Events.
  • Blocks must be allocated from a known list of available or free blocks (the Free Block List). The Free Block List must then be updated after each allocation or release of Blocks.
  • An implementation may use a simple Block allocation scheme that does not require Block Events at all. For example, Blocks could be allocated from a contiguous area, and the size of the area reduced after each allocation. If the implementation requires more sophisticated space management, Block
  • Volume Creation would prepare a Free List Event through which all subsequent Block allocations would be accessed and tracked.
  • a specific implementation need only generate and update a single Block Event as long as the allocations are contiguous, and Block Events need only be committed when the file system is being dismounted, just prior to writing an Unmount Event.
  • Allocate Block Events are generated every time a Block is allocated to a file to hold data, and the Blocks are successfully written. However, since allocations tend to be contiguous in a Write Once storage model, only one Allocate Block Event is likely required for the duration of a mount session.
  • Free Block Events are normally created only when a write to a file fails, and the Blocks allocated to hold that write are then returned to the Free Block List.
  • Free List Events are written when the file system is dismounted, and contains a complete, updated list of contiguous free Block entries.
  • Allocate Block Method The purpose of this method is to allocate one or more Blocks from the Free
  • Block List to a file that will write data to the allocated Blocks.
  • the method is passed a parameter indicating the number of Blocks required, and if successful, returns a list of allocated blocks.
  • the Event specified by the Free Block List is the Current Event.
  • Remaining Blocks is a value that is initialized to the number of blocks required.
  • the Allocated Event now contains a list of one or more contiguous Block areas.
  • Block Events may be created a list of Block Events, one item for each contiguous area of Blocks, and inserting the list at the beginning of the Free Block List.
  • a pathname for the new directory is provided by an external application to the file system, and the following steps are executed:
  • a pathname for the new file is provided by an external application to the file system, and the following steps are executed: (a) perform ESFS Pathname Lookup on the specified file pathname.
  • a pathname for the new file is provided by an external application to the file system, and the following steps are executed:
  • An external application provides the existing pathname of the file to be renamed, a new pathname, and the following steps are then executed:
  • the method for writing data to a file in the ESFS file system is explained below.
  • a specific implementation of the method would normally use a file descriptor or handle that provides access to a structure that retains information for an associated file that has been created or opened by the Create File or Open File methods.
  • the Write File method assumes that the following information is available:
  • Read File The method for reading data from a file in the ESFS file system is explained below.
  • the specific implementation of the method would normally include a file descriptor that retains information concerning a file that has been created or opened by the Create File or Open File methods. Also, specific implementations may support reading at any file location and length, or restrict reading to locations and sizes that are multiples of the underlying Block size.
  • implementations may need to perform the first (and/or last) read operation using a temporary buffer to accept a full Block. Partial user data is then copied to Data from a calculated offset within the temporary buffer.
  • File_Offset This value is the Block-Offset
  • the first Block to read is Starting_Block_Address + (Block-Offset Block-Size).
  • T set Read-Length to the lesser of Remaining_Data_Length or (Write-
  • Event-Length - Block-Offset (g) exit the procedure.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

L'invention concerne un système informatique de fichiers de stockage qui est structuré sans tables ni index et utilise à la place de ceux-ci une séquence constituée d'un petit nombre extensible de types d'événements prédéfinis dans une séquence logique décrivant l'historique complet et le contenu du système de fichiers, les événements étant des actions auxquelles sont soumis des objets, les objets étant au moins un répertoire ou un fichier, éventuellement associés à des données d'utilisateur.
EP07701720A 2006-01-27 2007-01-26 Système de fichiers structuré par événements Withdrawn EP1977348A4 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US76250206P 2006-01-27 2006-01-27
CA2534170A CA2534170C (fr) 2006-01-27 2006-01-27 Systeme de fichier structure d'evenements
PCT/CA2007/000097 WO2007085083A1 (fr) 2006-01-27 2007-01-26 Système de fichiers structuré par événements

Publications (2)

Publication Number Publication Date
EP1977348A1 true EP1977348A1 (fr) 2008-10-08
EP1977348A4 EP1977348A4 (fr) 2010-08-04

Family

ID=38308801

Family Applications (1)

Application Number Title Priority Date Filing Date
EP07701720A Withdrawn EP1977348A4 (fr) 2006-01-27 2007-01-26 Système de fichiers structuré par événements

Country Status (2)

Country Link
EP (1) EP1977348A4 (fr)
WO (1) WO2007085083A1 (fr)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9531722B1 (en) 2013-10-31 2016-12-27 Google Inc. Methods for generating an activity stream
US9542457B1 (en) 2013-11-07 2017-01-10 Google Inc. Methods for displaying object history information
US9614880B1 (en) 2013-11-12 2017-04-04 Google Inc. Methods for real-time notifications in an activity stream
US9509772B1 (en) 2014-02-13 2016-11-29 Google Inc. Visualization and control of ongoing ingress actions
US9536199B1 (en) 2014-06-09 2017-01-03 Google Inc. Recommendations based on device usage
US9507791B2 (en) 2014-06-12 2016-11-29 Google Inc. Storage system user interface with floating file collection
US10078781B2 (en) 2014-06-13 2018-09-18 Google Llc Automatically organizing images
US9870420B2 (en) 2015-01-19 2018-01-16 Google Llc Classification and storage of documents
US11995044B2 (en) 2021-02-12 2024-05-28 Zettaset, Inc. Configurable stacking/stackable filesystem (CSF)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6189016B1 (en) * 1998-06-12 2001-02-13 Microsoft Corporation Journaling ordered changes in a storage volume
US20030204479A1 (en) * 2002-04-25 2003-10-30 International Business Machines Corporation Method for efficient recording and management of data changes to an object
US20060004759A1 (en) * 2004-06-07 2006-01-05 Veritas Operating Corporation System and method for file system content processing

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6189016B1 (en) * 1998-06-12 2001-02-13 Microsoft Corporation Journaling ordered changes in a storage volume
US20030204479A1 (en) * 2002-04-25 2003-10-30 International Business Machines Corporation Method for efficient recording and management of data changes to an object
US20060004759A1 (en) * 2004-06-07 2006-01-05 Veritas Operating Corporation System and method for file system content processing

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
DOUGLIS F ET AL: "Log-structured file systems" INTELLECTUAL LEVERAGE. SAN FRANCISCO, FEB. 27 - MAR. 3, 1989; [COMPUTER SOCIETY INTERNATIONAL CONFERENCE (COMPCON)], WASHINGTON, IEEE COMP. SOC. PRESS, US LNKD- DOI:10.1109/CMPCON.1989.301914, vol. CONF. 34, 27 February 1989 (1989-02-27), pages 124-129, XP010014733 ISBN: 978-0-8186-1909-0 *
GAL E ET AL: "A TRANSACTIONAL FLASH FILE SYSTEM FOR MICROCONTROLLERS" PROCEEDINGS OF THE USENIX ANNUAL TECHNICAL CONFERENCE, GEBERAL TRACK, 10 April 2005 (2005-04-10), pages 89-104, XP009068250 *
See also references of WO2007085083A1 *
SELTZER M I ET AL: "JOURNALING VERSUS SOFT UPDATES: ASYNCHRONOUS META-DATA PROTECTION IN FILE SYSTEMS" PROCEEDINGS OF THE USENIX ANNUAL TECHNICAL CONFERENCE, XX, XX, 18 June 2000 (2000-06-18), pages 71-84, XP009068279 *

Also Published As

Publication number Publication date
EP1977348A4 (fr) 2010-08-04
WO2007085083A1 (fr) 2007-08-02

Similar Documents

Publication Publication Date Title
US8341123B2 (en) Event structured file system (ESFS)
CA2534170C (fr) Systeme de fichier structure d'evenements
US8548965B2 (en) Changed files list with time buckets for efficient storage management
US7860907B2 (en) Data processing
WO2007085083A1 (fr) Système de fichiers structuré par événements
US7827201B1 (en) Merging containers in a multi-container system
JP4388078B2 (ja) ファイルシステムと互換性を維持するシンボリックリンクを生成する方法、前記シンボリックリンクを用いてファイル／ディレクトリにアクセスする方法および装置
US7882071B2 (en) Systems and methods for a snapshot of data
US9507784B2 (en) Selective extraction of information from a mirrored image file
US8156165B2 (en) Transaction-safe FAT files system
US7987190B2 (en) Filesystem having a filename cache
US20130110893A1 (en) Methods of processing files in a multiple quality of service system
US20080270461A1 (en) Data containerization for reducing unused space in a file system
US20080046476A1 (en) Systems and methods for a snapshot of data
US20080046432A1 (en) Systems and methods for a snapshot of data
US8095678B2 (en) Data processing
US7376681B1 (en) Methods and apparatus for accessing information in a hierarchical file system
US7366836B1 (en) Software system for providing storage system functionality
US20080005524A1 (en) Data processing
Garfinkel et al. A file system for write-once media
US8176087B2 (en) Data processing
WO2008021528A2 (fr) Systèmes et procédés pour analyse sélective de données
US7979665B1 (en) Method and apparatus for processing access requests in a computer system
GB2439575A (en) Replacing data with references when freezing data
Stuart An O (1) Method for Storage Snapshots

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20080704

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: EL FRESKO TECHNOLOGIES LIMITED

A4 Supplementary search report drawn up and despatched

Effective date: 20100702

DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20130801