EP3084638A1 - Posix-kompatibles dateisystem, verfahren zum erzeugen einer dateiliste und speichervorrichtung - Google Patents

Posix-kompatibles dateisystem, verfahren zum erzeugen einer dateiliste und speichervorrichtung

Info

Publication number
EP3084638A1
EP3084638A1 EP14783855.1A EP14783855A EP3084638A1 EP 3084638 A1 EP3084638 A1 EP 3084638A1 EP 14783855 A EP14783855 A EP 14783855A EP 3084638 A1 EP3084638 A1 EP 3084638A1
Authority
EP
European Patent Office
Prior art keywords
file
directory
metadata
stored
files
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
EP14783855.1A
Other languages
English (en)
French (fr)
Inventor
Alexander KÖNIG
Christoph König
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.)
Fujitsu Ltd
Original Assignee
Fujitsu Technology Solutions Intellectual Property GmbH
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 Fujitsu Technology Solutions Intellectual Property GmbH filed Critical Fujitsu Technology Solutions Intellectual Property GmbH
Publication of EP3084638A1 publication Critical patent/EP3084638A1/de
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/14—Details of searching files based on file metadata
    • G06F16/148—File search processing
    • 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/11—File system administration, e.g. details of archiving or snapshots
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/13—File access structures, e.g. distributed indices

Definitions

  • the invention relates to a POSIX compatible file system comprising at least one directory and a plurality of files stored in the directory. Moreover, the invention relates to a method for generating a file list with files of a POSIX-compatible file system, a use of extended attributes and a
  • POSIX compatible file systems are known in the art.
  • most known Linux distributors are based on different, POSIX-compatible ones
  • Access rights as well as the creation, modification, and reading dates of files stored in the file system.
  • a POSIX compatible file system comprising at least one directory and a plurality of ones stored in the directory
  • Each file is associated with an inode with metadata about the particular file, and the directory comprises an association between filenames of the plurality of files and the inode associated with each file.
  • the metadata about the respective file at least the file name of the associated file and / or information about the at least one directory.
  • Filenames and / or paths based solely on metadata stored in the inodes.
  • metadata can be based on a combination of name and directory information
  • the storage of either only directory or name information allows at least pre-filtering of associated file objects, such that fewer fewer data blocks need to be accessed.
  • By locating name and / or directory information in the inodes I / O access to other parts of a mass storage can be avoided or reduced.
  • administrative tasks based on corresponding information and metadata of the inodes can be accelerated.
  • the information about the at least one directory comprises a reference to an inode associated with the directory.
  • the path to the file can be built backwards from an inode of a file without a
  • the file system is embodied as a WORM file system and the information about the at least one directory comprises a path specification of the assigned file from a predetermined reference point, in particular a mountpoint of the WORM file system.
  • WORM file system English:
  • writable file system is formed, after the first storage of a file no further changes in its path, for example, by renaming or moving the file or parent directories arise.
  • the full path can be stored in the inode associated with the file.
  • it is through a linear scan through the list of Inodes possible to build a file list with path information to files and associated inodes.
  • Aspect uses extended attributes of the file system.
  • a method for creating a file list with files of a POSIX compatible file system comprises the steps:
  • the metadata including at least the file name of the respective associated file and / or
  • the above method allows the creation of a file list exclusively for information contained in inodes of a POSIX-compatible file system. In this way, in particular the multiple back and forth
  • Metadata at least one further attribute, in particular a date of a last backup of the respective associated file, wherein the at least one further attribute is transferred to the file list and / or a transfer of a file in the file list based on the at least one further
  • Attribute is decided.
  • Filenames with additional attributes of the associated file can backup and archiving systems and similar
  • a storage device comprising at least one interface for accessing files stored by the storage device and at least one mass storage system for
  • the storage device is set up to receive a
  • the metadata stored on the file at least the file name of the file and / or information about a directory in which the file is stored.
  • the memory device further comprises a software component, wherein the at least one software component thereto
  • a file list is set up to create a file list based solely on the stored metadata.
  • it may be a file management software component that selects files for further processing based solely on the stored metadata.
  • a backup of files based on at least one of the metadata stored time in particular a comparison of an additional stored date of a last backup with a default stored date of a last change of the metadata associated file, be performed.
  • Figures 1A to IC a tree view, a
  • FIGS. 3A and 3B a data structure and a method according to a first embodiment of the invention
  • FIGS 4A and 4B a data structure and a method according to a second embodiment of the invention and Figure 5, a schematic representation of a
  • POSIX-compatible file system will generally be described below with reference to FIGS. 1A to 1C and a conventional file system
  • FIG. 1A shows a directory tree 1 of a POSIX-compatible file system 2.
  • POSIX compliant file systems 2 usually allow the use of uppercase and lowercase letters as well as numbers and other special characters for both directory and file names.
  • clear longer names and the production of clearly more complicated directory trees than the directory tree 1 shown in FIG. 1A are possible.
  • files are referenced in the following description and appended claims, there are regular files in the sense of a POSIX compatible one
  • the directory tree 1 includes a so-called
  • the root directory 3 is the operating system Unix and related operating systems such as Linux
  • the directory tree 1 first branches from the root directory 3 into three directories A, B and C of a first hierarchical level
  • the first directory A contains two regular files al in the directory tree 1 according to FIG
  • the second directory B comprises a single file bl
  • the third directory C comprises a further subdirectory D of a second hierarchical level and regular files cl and c2
  • a further file d1 is stored in the exemplary embodiment according to FIG.
  • the directory tree 1 shown in FIG. 1A represents a simplified special case involving only a single root file system without so-called mount points and no links between different file and directory objects of the
  • File system 2 contains. Basically, it is common for POSIX compatible file systems, the content of others
  • Root file system with the root directory 3, to integrate.
  • network-like structures can be created so that multiple paths from the root directory 3 to one and the same regular file can result. Such structures are not shown here for reasons of clarity. Their importance for the implementation of the following
  • FIG. 1B schematically shows a data structure for mapping the directory tree 1 onto a physical data carrier 4.
  • the physical data carrier 4 is a mass storage device in the form of a data storage device
  • Hard disk drive or a flash drive is a hard disk drive or a flash drive.
  • the physical data carrier 4 is in the embodiment in a first memory area 5 and a second
  • Memory area 6 divided. For example, it may be a division according to block addresses or other
  • Address information of the physical disk 4 act. Such a division is usually at a first
  • inodes 7 are stored in the embodiment.
  • the inodes are POSIX-compatible data blocks with metadata about the data stored in the file system 2. The exact
  • a predetermined inode 7r is the one
  • Root directory 3 assigned. For example, it is a first addressable block of the first
  • Memory area 5 Further inodes 7 are the respective
  • Clarity are the inodes 7 of the first
  • mapping of inodes to related directories or files is more dependent on the order of their creation.
  • the actual data of the file system 2 are stored.
  • a directory object 8 is stored in the second memory area 6.
  • the corresponding directory objects 8 essentially comprise a list of list entries, each list entry containing the names and associated inodes of the list entries
  • directory object 8 for directory A includes two list entries with filenames a1 and a2 and an associated numeric address of inodes 7 associated with files a1 and al2.
  • file objects 9 are more regular Files are stored associated with corresponding inodes 7 of the first memory area 5.
  • the actual data may be one or more File objects 9 extend. However, this is not shown in FIG. 9 for reasons of clarity.
  • a single inode 7 is not always sufficient to store references to all the file objects 9 of the second memory area 6 in a single inode 7.
  • the inode 7 refers to further second or third order inodes 7, so that a large number of references to corresponding file objects 9
  • File list 10 includes list entries 11 for regular files. Each list entry 11 comprises at least one complete path 12, consisting of a simple path 13 to the directory in which the file is stored, as well as the actual file name 14, a numeric address 15 of the inode 7 associated with the file, and other attributes 16 of the file, such as For example, the date of creation or last modification of the file.
  • the information of the file list 10 may, for example, of software components of a
  • Archiving system can be used to decide which file objects 9 of the second storage area 6 on another storage medium, such as a magnetic security tape, must be stored.
  • file lists 10 are required, inter alia, in hierarchical storage system (HSM) but for other systems and programs for managing large data.
  • HSM hierarchical storage system
  • FIG. 2A schematically shows the one used for this purpose
  • Root directory 3 determined and loaded. For example, an inode entry with the address "0" can be read in from the first memory area 5.
  • a current variable p is used to record the current path, which in this case is represented by a simple "/”. Subsequently, in a step 21, an associated
  • Directory object 8r loaded from the second memory area 6.
  • the directory object 8r comprises three directory entries 17 for the directories A, B and C of the first hierarchical level.
  • step 22 it is determined in a subsequent step 22 that directory entries 17 still to be processed are present in the directory object 8r.
  • step 23 first, the first
  • Directory entry 17A shows that the inode 7A with the address "1" is assigned to the memory object A. Furthermore, the directory entry 17A results in the name "A" of the memory object A. In the subsequent step 24, the associated inode 7A of the memory object A is created with the address "1" to determine the metadata associated with the storage object A.
  • step 25 it is checked what type of object the memory object A is. From the loaded metadata of the inode 7A can be determined, for example, based on the so-called mode information, whether it is, as in the present case, another directory or a regular file or other object of a POSIX-compatible file system 2.
  • mode information whether it is, as in the present case, another directory or a regular file or other object of a POSIX-compatible file system 2.
  • FIG. 2B for the sake of simplicity, only the
  • Directory object 8 in a subsequent step 26, the working variable for the path p to be examined is supplemented by the name determined in step 23. Furthermore, the directory that is currently valid is buffered in another variable q. Thereafter, the process is continued recursively in step 21 with the loading of the associated directory object 8A.
  • the directory A contains only regular file objects 9 for the files al and a2.
  • step 25 it is determined that the directory entries 17 of the directory object 8A refer to regular files. Accordingly, in a step 27, a list entry 11 for the file list 10 is generated based on the current path p and the file name "al" extracted from the directory entry 17 in step 23. Thereafter, the method is described in
  • a further list entry 11 for the file a2 is generated in a subsequent circulation in step 27.
  • a renewed call of step 22 it is determined that no further directory entries 17 are to be processed in directory A. Accordingly, in one
  • Directory of the directory A reset, ie the root directory "/", and the process is continued at the next higher level in step 22.
  • the directory tree 1 shown in FIG. 1A is progressively visited by the recursive algorithm, directory entries 17 for file objects 9 being generated in the file list 10.
  • the method according to FIG. 2B causes a
  • Memory area 5 and the second memory area 6 This is due in particular to the fact that without reading out the information of the inodes 7 from the first memory area 5, the associated directory objects 8 and file objects 9 in the second memory area 6 can not be located. Conversely, in the inodes 7 of the first
  • Memory area 5 does not contain all the information about
  • FIG. 3A shows an improved data structure for mapping the directory tree 1 described at the beginning.
  • File object 9 or directory object 8 stored.
  • a back reference 18 is likewise stored on the inode 7 of a higher-level directory object 8, that is, for example, in the inode 7A of the directory A
  • Root directory 3 itself there is no entry.
  • Root directory 3 For more complex directory trees, the distributed over several disks are correspondingly have multiple mount points, the reference points to the
  • Directory object 8 the back reference 18 and, if appropriate, the reference to the reference point can be stored, for example, as extended attributes of known file systems, for example by using the so-called xattr function.
  • Figure 3B shows an improved method of creating the file list 10 based on the data structure of Figure 3A.
  • a first step 30 it is checked whether further inodes 7 of a list of inodes are to be processed.
  • the inode list may contain all inodes 7 of the first
  • Memory area 5 include.
  • processing inode 7 read.
  • a subsequent step 32 it is checked whether the inode 7 is assigned to a regular file object 9. If this is not the case, the processing in step 30 can be continued immediately with the next inode 7.
  • step 32 If, on the other hand, it is determined in step 32 that the last-read inode 7 is assigned to a regular file object 9, for example the file al, in step 33 the Address 15 of the inode 7 and the associated name "al" of the file object 9 are cached in a variable n.
  • a step 34 subsequently the inode 7A is loaded, which the return link 18 of the previously loaded inode 7 references as inode 7A of the higher-level directory object 8A.
  • the variable n is supplemented by the name "A" of the higher-level directory A.
  • a step 36 it is checked whether the higher-level directory is already the root directory 3. If this is the case, then a Step 37 now stores the complete path 12 contained in the variable n, including the path 13 and the file name 14 in the file list 10, as well as the address 15 of the inode 7 associated with the regular file "al". Thereafter, the method is continued in step 30 with the processing of possibly further inodes 7 of the inode list. If, however, it is determined in step 36 that it is not yet the root directory 3, the method is continued in step 34 with the loading of the inode 7 of the directory which is the parent directory, so that the path in step 35 is the next higher one
  • Directory level is supplemented until the process finally arrives at the root directory 3. In this way, for each inode 7 by following the return references 15
  • FIG. 3B has a number of advantages over the method according to FIG. 2B.
  • Memory area 6 are avoided on the physical disk 4. All data required to create the file list 10 is completely in the inodes 7
  • the inodes 7 contain only the reference back to the higher-level directory object 8, but no attribute with the name of the inode 7
  • Memory area 6 are accessed. However, the number of I / O accesses can already be significantly reduced in this embodiment, if only paths for a
  • inodes 7 relatively small proportion of inodes 7 must be determined. For example, as explained later, due to the other metadata contained in the inode 7, only certain files for further processing, such as a backup, can be selected. If, for example, only 1% of the stored file objects 9 are backed up, the structure of paths for the selected inodes 7 by reading a few directory objects 8 is still associated with significantly fewer I / O accesses than a complete one
  • Figures 4A and 4B show a data structure
  • Embodiment instead of the name of the memory object and the back reference 18 to the inode 7 of a parent
  • Directory object 8 a path 12, stored at least from the parent mountpoint. Furthermore, in each inode 7, a reference 19 to the inode 7 of a
  • the described embodiment serves as a reference point for objects of the root file system, the root directory 3, here a
  • the root file system of mounted file systems is stored as the reference point of the inode of the mount point of the corresponding mounted file system at which path 12 begins.
  • a backup date 20 is stored, which is the time of a last backup of the associated object on another storage medium, such as a tape storage medium by a
  • a fixed reference point for example the
  • Root directory 3 or another specified node of file system 2, fixed or elsewhere
  • the storage of the reference 19 in the inodes 7 can be dispensed with.
  • a single additional attribute namely a complete path 12 including the simple path 13 from the root directory 3 and the file name 14 itself, stored as a contiguous string.
  • the file system 2 is a so-called WORM file system, in which after the first-time writing of a file or the creation of a file Directory name changes or shifts are no longer possible.
  • WORM file system in which after the first-time writing of a file or the creation of a file Directory name changes or shifts are no longer possible.
  • File object 9 is assigned. If this is not the case, the method can be continued in step 40 with the processing of possibly further inodes 7. Otherwise, an entry for the file list 10 can be created immediately in step 43. Is it the stored one
  • full path 12 of the data object 9 can be used directly to create the entry.
  • a path from the root directory 3 to the respective stored mountpoint may have to be determined. Again, this is usually possible without further I / O access to a mass storage, since even in complex file system usually only a few mountpoints are available, which in a central location, in particular a so-called filesystem table fstab (English: filesystem table) , are stored.
  • filesystem table fstab English: filesystem table
  • Procedure in step 40 continued with the possibly existing next inode 7.
  • the method according to FIG. 4B also has the advantage that only the information stored in the inodes 7 for creating the file list 10 is sufficient.
  • the method according to FIG. 4B has the advantage that recursive creation of path information is no longer necessary at all. Instead, the file list 10 may be replaced by a
  • the additional save date 20 serves this purpose
  • all objects of the file system are regularly secured on a further storage medium, such as a magnetic tape.
  • a further storage medium such as a magnetic tape.
  • pending backup run can be based solely on the stored in the inodes 7
  • FIG. 5 shows a memory device 50 according to FIG.
  • Storage device 50 is for example a so-called storage appliance, which is the archiving
  • FIG. 5 indicates that such copies are made on a tape drive 52 which is external in the exemplary embodiment or in a so-called cloud memory 53, that is to say one via
  • Data network especially the Internet, connected
  • the memory device 50 according to FIG. 5 has a first interface 54 for accessing those in FIG.
  • Storage device 50 stored data.
  • this is an interface according to the NFS protocol for the Unix operating system family or an interface according to the CIFS protocol for the
  • Windows family of operating systems About the first interface 54 known from these protocols requests for writing and reading and, where appropriate, for deleting and Rename individual files to the storage device 50 are transmitted.
  • the commands received via the interface 54 are analyzed via a processing component 55 of the memory device 50 and, if permissible, implemented.
  • a processing component 55 of the memory device 50 serves a
  • Storage medium of the storage device 50 is stored.
  • the processing component 55 sets the corresponding ones
  • Storage device 50 as WORM systems, requests for changing and renaming files and directories are acknowledged with a corresponding error message and not executed. A deletion of a file is either not allowed or only after expiry of a predetermined retention period. Invalid delete commands are also acknowledged with an error message. In the case of permissible deletion commands, in particular deletion commands for regular files in an ordinary, rewriteable file system, the deletion of a file is entered in an additional protocol file which is used in the later creation of file lists 10 and similar information based on the meta information
  • DMAPI Data Management API
  • Directory objects 8 of a file system 2 are checked for changes since a last search.
  • the inodes 7 of the directory entries 17 of the changed directory objects 8 are determined. For these inodes 7 then in a third step corresponding
  • the storage device 50 further includes a second interface 56 for administration. About the second
  • Interface 56 has a system administrator or other authorized user access to a configuration dialog 57, with which the behavior of the memory device 50 in
  • Detail can be configured. For example, it can be selected via the configuration dialog 57 whether the file system provided by the interface 57 of the
  • the memory device 50 further comprises a scanning component 58 which is used inter alia for processing the
  • the memory device 50 comprises a so-called object mover 59, which is responsible for the need-based backup of files on another storage medium.
  • a fuse can be made for various reasons. For example, it may be a regular one
  • Backup of the stored in the storage device 50 objects act.
  • it can also be a swapping out of a file or file version in a hierarchical storage system or archive system
  • the object mover 59 creates a new object at the destination, which contains at least the data of the secured object and possibly further metadata for the backup.
  • the metadata stored in the inodes 7 of the file system of the mass storage 51 is updated accordingly. For example, during a backup in an extended attribute the current date as the last backup date 20 notes. Alternatively, at a
  • the object associated with the inode 7 may be identified as being deleted from the mass storage 51 or replaced by a so-called stub that is based on the new one
  • the storage device 50 further comprises a so-called backup manager 60 for self-service
  • the backup manager 60 accesses, among other things, the scanning device 58 to objects
  • Directory objects to be backed up are Directory objects to be backed up.
  • other backup strategies such as a differential backup, in which the difference is always backed up since a last basic backup, or a full backup, in which always the entire content or
  • predetermined portions of the mass memory 51 is secured can be used.
  • Various system parameters are specified via the configuration interface 57. For example, a so-called mountpoint of a file system 2, for which the incremental backup is to be performed, is determined. In addition, a time interval between
  • Storage device 50 every hour, daily or weekly backup of the stored in the mass storage 51 files makes. Also other criteria, such as the minimum or maximum size of files to be backed up can be specified via the configuration dialog 57.
  • Storage device 50 scans the scanner 58 for all
  • the date of the last backup may also be stored elsewhere in the storage device.
  • a global for all objects of the storage device may also be stored elsewhere in the storage device.
  • the file list 10 to be created can contain, in addition to the path information 12 or 13 and / or the file name 14, further information,
  • Tape drive 52 or the cloud storage 53 store.
  • Data processing tasks where data is at least partially processed with associated metadata.
  • Image management software outlines individual images from a large number of existing image data
  • Metadata associated with image data for example as so-called EXIF data in an image format, such as a JPEG image format, must first be read in at least the header information of the respective image file before processing is possible. This leads to the frequent repositioning of read heads of a mass memory already described above and thus to a slower processing speed.
  • Metadata in a separate database in particular a relational database or object database too
  • Image processing program if necessary, not recognized by the database. Accordingly, there is basically the problem of keeping the metadata stored in the database consistent with the actual data.
  • such application-specific metadata are additionally stored in the inodes 7 of the file system 2.
  • a Location of a photo in the advanced attributes of a GPFS file system is additionally stored in the inodes 7 of the file system 2.
  • the methods described above are applicable for scanning a large list of files.
  • it can then be determined on the basis of a list of inodes 7 alone which further files have to be taken into account for processing, for example the compilation of a slide show. Since the application-specific attributes are stored directly in the extended file system 2, this can not lead to a discrepancy between the stored metadata on the one hand and possibly changed image data on the other.

Abstract

Die Erfindung betrifft ein POSIX-kompatibles Dateisystem (2) umfassend wenigstens ein Verzeichnis (A) und eine Mehrzahl von in dem Verzeichnis (A) gespeicherten Dateien (a1, a2), wobei jeder Datei (a1, a2) ein Inode (7) mit Metadaten über die jeweilige Datei (a1, a2) zugeordnet ist und das Verzeichnis (A) eine Zuordnung zwischen Dateinamen (14) der Mehrzahl von Dateien (a1, a2) und dem jeweils einer Datei (a1, a2) zugeordneten Inode (7) umfasst. Dabei umfassen die Metadaten über die jeweilige Datei (a1, a2) wenigstens den Dateinamen (14) der zugeordneten Datei (a1, a2) und/oder Informationen über das wenigstens eine Verzeichnis (A). Die Erfindung betrifft des Weiteren ein Verfahren zum Erzeugen einer Dateiliste (10), die Verwendung von erweiterten Attributen eines POSIX-kompatiblen Dateisystems (2) sowie eine Speichervorrichtung (50).

Description

Beschreibung
POSIX-kompatibles Dateisystem, Verfahren zum Erzeugen einer Dateiliste und Speichervorrichtung
Die Erfindung betrifft ein POSIX-kompatibles Dateisystem umfassend wenigstens ein Verzeichnis und eine Mehrzahl von in dem Verzeichnis gespeicherten Dateien. Darüber hinaus betrifft die Erfindung ein Verfahren zum Erzeugen einer Dateiliste mit Dateien eines POSIX-kompatiblen Dateisystems, eine Verwendung von erweiterten Attributen sowie eine
Speichervorrichtung .
POSIX-kompatible Dateisysteme sind aus dem Stand der Technik bekannt. Insbesondere basieren die meisten bekannten Linux- Distributoren auf verschiedenen, POSIX-kompatiblen
Dateisystemen, wie beispielsweise ext2 und ext3.
Grundsätzlich weisen derartige Dateisysteme eine
verhältnismäßig große Flexibilität auf und sind zur Ablage einer großen Anzahl von Dateien geeignet.
POSIX-kompatible Dateisysteme verwalten physikalische
Datenträger unter Verwendung so genannter Inodes, wobei die Inodes Metadaten über auf dem Datenträger gespeicherte
Informationen enthalten. Beispiele solcher Metadaten sind
Zugriffsrechte sowie jeweils ein Erstellungs- , Änderungs- und Lesedatum von in dem Dateisystem gespeicherten Dateien.
Derartige Informationen werden unter anderem von Sicherungsund Archivierungslösungen zum Verwalten der in dem
Dateisystem gespeicherten Dateien verwendet.
Die Auswertung und Aktualisierung solcher und ähnlicher Metadaten kann jedoch insbesondere bei sehr umfangreichen Dateisystemen, wie sie beispielsweise in sogenannten „Big Data"-Anwendungen vorkommen, auch zu Problemen führen.
Es ist eine Aufgabe der vorliegenden Erfindung, ein POSIX- kompatibles Dateisystem sowie Verfahren und Vorrichtungen zu seiner Erstellung und Nutzung zu beschreiben, die eine gegenüber bekannten Implementierungen verbesserte
Leistungsfähigkeit aufweisen. Insbesondere soll eine Anzahl von I /O-Zugriffen auf einen Massenspeicher beim Durchsuchen von auf dem Massenspeicher gespeicherten Dateien reduziert werden. Die beschriebenen Vorrichtungen und Verfahren sollen sich insbesondere zur Verwendung in Sicherungs- und
Archivierungssystemen eignen, die hunderttausende bis
Milliarden von Dateien verwalten.
Gemäß einem ersten Aspekt der Erfindung wird ein POSIX- kompatibles Dateisystem umfassend wenigstens ein Verzeichnis und eine Mehrzahl von in dem Verzeichnis gespeicherten
Dateien offenbart. Jeder Datei ist ein Inode mit Metadaten über die jeweilige Datei zugeordnet, und das Verzeichnis umfasst eine Zuordnung zwischen Dateinamen der Mehrzahl von Dateien und dem jeweils einer Datei zugeordneten Inode. Dabei umfassen die Metadaten über die jeweilige Datei wenigstens den Dateinamen der zugeordneten Datei und/oder Informationen über das wenigstens eine Verzeichnis.
Ein derartiges Dateisystem erlaubt die Bestimmung von
Dateinamen und/oder Pfadangaben allein auf Grundlage von in den Inodes gespeicherten Metadaten. Beispielsweise erlaubt ein derartiges Dateisystem basierend auf einer Kombination von Namens und Verzeichnisinformation der Metadaten der
Inodes eine Dateiliste zu erstellen, ohne dass auf sonstige Datenblöcke des Dateisystems, insbesondere Verzeichnisse, zugegriffen werden muss. Die Speicherung von entweder nur Verzeichnis oder Namensinformation erlaub zumindest eine Vorfilterung von zugehörigen Dateiobjekten, so dass auf weniger andere Datenblöcke zugegriffen werden muss. Durch die Lokalisierung von Namens- und/oder Verzeichnisinformationen in den Inodes können I/O-Zugriffe auf sonstige Teile eines Massenspeichers vermieden oder reduziert werden. Somit können Verwaltungsaufgaben, die auf entsprechenden Informationen und Metadaten der Inodes beruhen, beschleunigt werden.
Gemäß einer ersten Ausgestaltung umfasst die Information über das wenigstens eine Verzeichnis einen Verweis auf einen dem Verzeichnis zugeordneten Inode. Durch Vorsehung eines
Verweises auf einen Inode eines übergeordneten Verzeichnisses kann ausgehend von einem Inode einer Datei rückwärts der Pfad zu der Datei aufgebaut werden, ohne dass eine
Verzeichnisstruktur durch Lesen von Verzeichnisobjekten aufgebaut werden muss. Gemäß einer alternativen Ausgestaltung ist das Dateisystem als WORM-Dateisystem ausgeführt und die Information über das wenigstens eine Verzeichnis umfasst eine Pfadangabe der zugeordneten Datei von einem vorbestimmten Bezugspunkt, insbesondere einem Mountpoint des WORM-Dateisystems. Wenn das Dateisystem als so genanntes WORM-Dateisystem (Englisch:
„write once, read multiple") , also als nur einmal
beschreibbares Dateisystem ausgestaltet ist, können nach der ersten Speicherung einer Datei keine weiteren Änderungen in dessen Pfad, beispielsweise durch Umbenennen oder Verschieben der Datei oder von übergeordneten Verzeichnisse entstehen. In diesem Fall kann die vollständige Pfadangabe in dem der Datei zugeordneten Inode gespeichert werden. In einem derartigen System ist es durch einen linearen Scan durch die Liste der Inodes möglich, eine Dateiliste mit Pfadangaben zu Dateien und zugehörigen Inodes aufzubauen.
Zum Speichern des Dateinamens und der Informationen über das wenigstens eine Verzeichnis werden gemäß einem weiteren
Aspekt erweiterte Attribute des Dateisystems verwendet.
Gemäß einem weiteren Aspekt der Erfindung wird ein Verfahren zum Erzeugen einer Dateiliste mit Dateien eines POSIX- kompatiblen Dateisystems beschrieben. Das Verfahren umfasst die Schritte:
- Scannen einer vorbestimmten Gruppe von Inodes zum
Erfassen von Metadaten einer Mehrzahl von den Inodes jeweils zugeordneten Dateien, wobei die Metadaten wenigstens den Dateinamen der jeweils zugeordneten Datei und/oder
Informationen über ein Verzeichnis umfassen, in dem die jeweilige Datei gespeichert ist;
- Bestimmen von Dateinamen und/oder Pfadangaben von
Dateien basierend allein auf den in den Inodes gespeicherten Metadaten; und
- Erzeugen einer Dateiliste auf Grundlage der bestimmten Dateinamen bzw. Pfadangaben.
Das oben genannte Verfahren gestattet die Erzeugung einer Dateiliste ausschließlich auf Informationen, die in Inodes eines POSIX-kompatiblen Dateisystems enthalten sind. Auf diese Weise kann insbesondere das mehrfache Hin- und
Zurückspringen von Schreib-/Lese-Köpfen einer physikalischen Speichervorrichtung zwischen einem ersten Speicherbereich mit Informationen der Inodes und einem zweiten Speicherbereich mit anderen Datenblöcken vermieden werden, so dass der Aufbau der Dateiliste insgesamt beschleunigt wird. Gemäß einer vorteilhaften Ausgestaltung umfassen die
Metadaten wenigstens ein weiteres Attribut, insbesondere ein Datum einer letzten Sicherung der jeweils zugeordneten Datei, wobei das wenigstens eine weitere Attribut in die Dateiliste übernommen wird und/oder eine Übernahme einer Datei in die Dateiliste auf Grundlage des wenigstens einen weiteren
Attributs entschieden wird. Durch die Kombination des
Dateinamens mit weiteren Attributen der zugehörigen Datei, insbesondere eines Datum einer letzten Sicherung, können Sicherungs- und Archivierungssysteme sowie ähnliche
Softwareprogramme allein anhand der in den Inodes enthaltenen Metadaten entscheiden, welche Dateien weiterverarbeitet, beispielsweise gesichert, werden müssen. Gemäß einem weiteren Aspekt der Erfindung wird eine
Speichervorrichtung umfassend wenigstens eine Schnittstelle zum Zugriff von durch die Speichervorrichtung gespeicherten Dateien und wenigstens ein Massenspeichersystem zum
nichtflüchtigen Speichern der Dateien offenbart. Dabei ist die Speichervorrichtung dazu eingerichtet, bei Erhalt eines
Schreibbefehls zum Schreiben oder Ändern einer Datei über die wenigstens eine Schnittstelle Metadaten über die wenigstens eine Datei in dem Massenspeichersystem zu speichern bzw.
bereits gespeicherte Metadaten zu ändern, wobei die über die Datei gespeicherten Metadaten wenigstens den Dateinamen der Datei und/oder Informationen über ein Verzeichnis umfassen, in dem die Datei gespeichert ist.
Die genannte Speichervorrichtung speichert die notwendigen Informationen zur Ausführung des oben genannten Verfahrens und zur Bereitstellung eines POSIX-kompatiblen Dateisystems. Gemäß weiteren Ausgestaltungen der Erfindung umfasst die Speichervorrichtung des Weiteren eine Softwarekomponente, wobei die wenigstens eine Softwarekomponente dazu
eingerichtet ist, eine Dateiliste allein auf Grundlage der gespeicherten Metadaten zu erzeugen. Beispielsweise kann es sich um eine Softwarekomponente zur Dateiverwaltung handeln, die allein basierend auf den gespeicherten Metadaten Dateien für eine weitere Verarbeitung auswählt. Insbesondere kann eine Sicherung von Dateien basierend auf wenigstens einer in den Metadaten gespeicherten Zeitangabe, insbesondere eines Vergleichs eines zusätzlich gespeicherten Datums einer letzten Sicherung mit einem standardmäßig gespeicherten Datum einer letzten Änderung der den Metadaten zugeordneten Datei, durchgeführt werden.
Weitere vorteilhafte Ausgestaltungen und Einzelheiten der Erfindung sind in den angehängten Ansprüchen sowie der nachfolgenden ausführlichen Beschreibung von
Ausführungsbeispielen offenbart.
Die Erfindung wird nachfolgend anhand von unterschiedlichen Ausführungsbeispielen unter Bezugnahme auf die angehängten Figuren im Detail beschrieben. Dabei werden unterschiedliche Instanzen gleicher oder gleichwirkender Komponenten mit alphabetischen Suffixen gekennzeichnet. Soll auf alle
Instanzen gemeinsam Bezug genommen werden, wird das
entsprechende Suffix weggelassen. In den Figuren zeigen:
Figuren 1A bis IC, eine Baumdarstellung, eine
Speicheraufteilung sowie eine Listendarstellung eines POSIX- kompatiblen Dateisystems im Allgemeinen, Figuren 2A und 2B, eine konventionelle Datenstruktur sowie ein konventionelles Verfahren zum Erstellen einer Dateiliste,
Figuren 3A und 3B, eine Datenstruktur sowie ein Verfahren gemäß einer ersten Ausgestaltung der Erfindung,
Figuren 4A und 4B, eine Datenstruktur und ein Verfahren gemäß einer zweiten Ausgestaltung der Erfindung und Figur 5, eine schematische Darstellung einer
Speichervorrichtung gemäß einer Ausgestaltung der Erfindung.
Zum besseren Verständnis der Erfindung wird nachfolgend zunächst ein POSIX-kompatibles Dateisystem im Allgemeinen anhand der Figuren 1A bis IC sowie eine konventionelle
Datenstruktur zu seiner Implementierung sowie ein Verfahren zum Erstellen einer Dateiliste anhand der Figuren 2A und 2B beschrieben . Figur 1A zeigt einen Verzeichnisbaum 1 eines POSIX- kompatiblen Dateisystems 2. Zur besseren Unterscheidung werden im weiteren Verlauf Großbuchstaben zur Kennzeichnung von Verzeichnissen und Kleinbuchstaben sowie Ziffern zur Kennzeichnung von regulären Dateien des Dateisystems 2 verwendet. Selbstverständlich gestatten POSIX-kompatible Dateisysteme 2 in der Regel die Verwendung von Groß- und Kleinbuchstaben sowie Ziffern und sonstige Sonderzeichen sowohl für Verzeichnis- als auch Dateinamen. Des Weiteren sind deutliche längere Namen und die Herstellung von deutlich komplizierterer Verzeichnisbäume als dem in der Figur 1A dargestellten Verzeichnisbaum 1 möglich. Soweit in der folgenden Beschreibung und den angehängten Ansprüchen auf Dateien verwiesen wird, sind darunter jeweils reguläre Dateien im Sinne eines POSIX-kompatiblen
Dateisystems, das heißt die in dem Dateisystem 2
gespeicherten Nutzdaten, zu verstehen. Andere Objekte, wie insbesondere Verzeichnisobjekte, sogenannte Hard- und
Softlinks und sonstige Metadaten des Dateisystems 2, werden im Folgenden explizit als solche benannt, um sie besser von regulären Dateien zu unterschieden.
Der Verzeichnisbaum 1 umfasst ein so genanntes
Wurzelverzeichnis 3 das bei dem Betriebssystem Unix und daran angelehnten Betriebssystemen wie beispielsweise Linux
üblicherweise durch den vorwärts gestellten Schrägstrich „/" gekennzeichnet ist. Von dem Wurzelverzeichnis 3 verzweigt sich der Verzeichnisbaum 1 zunächst in drei Verzeichnisse A, B und C einer ersten Hierarchieebene. Das erste Verzeichnis A enthält in dem Verzeichnisbaum 1 gemäß Figur 1 zwei reguläre Dateien al und a2. Das zweite Verzeichnis B umfasst eine einzelne Datei bl . Das dritte Verzeichnis C umfasst ein weiteres Unterverzeichnis D einer zweiten Hierarchieebene sowie reguläre Dateien cl und c2. In dem Unterverzeichnis D zweiter Ordnung ist im Ausführungsbeispiel gemäß Figur 1 eine weitere Datei dl gespeichert.
An dieser Stelle wird darauf hingewiesen, dass der in der Figur 1A dargestellte Verzeichnisbaum 1 einen vereinfachten Sonderfall darstellt, der nur ein einziges Stammdateisystem ohne sogenannte Mountpoints sowie keinerlei Links zwischen unterschiedlichen Datei- und Verzeichnisobjekten des
Dateisystems 2 enthält. Grundsätzlich ist es bei POSIX- kompatiblen Dateisystemen üblich, den Inhalt weiterer
Massenspeicher mit darauf gespeicherten Verzeichnisbäumen an vorbestimmten Stellen, den sogenannten Mountpoints, eines übergeordneten Dateisystems, normalerweise des
Stammdateisystems mit dem Wurzelverzeichnis 3, einzubinden. Ebenfalls könne durch die Verwendung von Soft- oder Hardlinks netzwerkartige Strukturen erzeugt werden, so dass mehrere Pfade von dem Wurzelverzeichnis 3 zu ein und derselben regulären Datei führen können. Derartige Strukturen sind hier aus Gründen der Übersichtlichkeit nicht dargestellt. Ihre Bedeutung für die Implementierung der nachfolgend
beschriebenen Vorrichtungen und Verfahren sind an
entsprechender Stelle aufgeführt.
Figur 1B zeigt schematisch eine Datenstruktur zum Abbilden des Verzeichnisbaums 1 auf einen physikalischen Datenträger 4. Beispielsweise handelt es sich bei dem physikalischen Datenträger 4 um einen Massenspeicher in Form eines
Festplattenlaufwerks oder eines Flash-Laufwerks.
Grundsätzlich sind jedoch auch andere Speichermedien möglich. Der physikalische Datenträger 4 ist im Ausführungsbeispiel in einen ersten Speicherbereich 5 und einen zweiten
Speicherbereich 6 aufgeteilt. Beispielsweise kann es sich um eine Aufteilung gemäß Blockadressen oder sonstigen
Adressangaben des physikalischen Datenträgers 4 handeln. Eine derartige Aufteilung wird in der Regel bei einer ersten
Initialisierung des Datenträgers 4, beispielsweise bei dessen Formatierung mit dem Dateisystem 2, vorgenommen.
In dem ersten Speicherbereich 5 sind im Ausführungsbeispiel so genannte Inodes 7 gespeichert. Bei den Inodes handelt es sich um POSIX-kompatible Datenblöcke mit Metadaten über die in dem Dateisystem 2 gespeicherten Daten. Die genaue
Datenstruktur der einzelnen Inodes 7 wird weiter unten unter Bezugnahme auf die Figur 2A beschrieben. In der Darstellung gemäß Figur 1B ist ein vorbestimmter Inode 7r dem
Wurzelverzeichnis 3 zugeordnet. Beispielsweise handelt es sich um einen ersten adressierbaren Block des ersten
Speicherbereichs 5. Weitere Inodes 7 sind jeweils den
Verzeichnissen A, B, C und D sowie den Dateien al, a2, bl, cl, c2 und dl zugeordnet. Die jeweilige Zuordnung zwischen den Inodes 7 und den zugehörigen Verzeichnissen
beziehungsweise Dateien ist von der Implementierung des
Dateisystems 2 abhängig. Lediglich aus Gründen der
Übersichtlichkeit sind die Inodes 7 des ersten
Speicherbereichs 5 in der oben genannten Reihenfolge
dargestellt. In der Praxis hängt die Zuordnung von Inodes zu zugehörigen Verzeichnissen oder Dateien dagegen eher von der Reihenfolge ihrer Erstellung ab.
In dem zweiten Speicherbereich 6 sind die eigentlichen Daten des Dateisystems 2 gespeichert. Insbesondere sind zu jedem der Verzeichnisse A, B, C und D sowie dem Wurzelverzeichnis „/" ein Verzeichnisobjekt 8 in dem zweiten Speicherbereich 6 gespeichert. Die entsprechenden Verzeichnisobjekte 8 umfassen im Wesentlichen eine Liste mit Listeneinträgen, wobei jeder Listeneintrag die Namen und zugehörigen Inodes der in dem Verzeichnis gespeicherten Objekte angeben. Beispielsweise umfasst das Verzeichnisobjekt 8 für das Verzeichnis A zwei Listeneinträge mit den Dateinamen al und a2 sowie einer zugehörigen nummerischen Adresse der den Dateien al und a2 zugeordneten Inodes 7. In dem zweiten Speicherbereich 6 sind des Weiteren Dateiobjekte 9 regulärer Dateien gespeichert, die korrespondierenden Inodes 7 des ersten Speicherbereichs 5 zugeordnet sind. Je nach Umfang der gespeicherten Dateien können sich die tatsächlichen Daten über ein oder mehrere Dateiobjekte 9 erstrecken. Dies ist aus Gründen der Übersichtlichkeit in der Figur 9 jedoch nicht dargestellt.
Bei sehr großen Dateien reicht ein einzelner Inode 7 nicht immer aus, um Verweise auf sämtliche Dateiobjekte 9 des zweiten Speicherbereichs 6 in einem einzigen Inode 7 zu speichern. In diesem Fall verweist der Inode 7 auf weitere Inodes 7 zweiter oder dritter Ordnung, so dass eine große Anzahl von Verweisen auf entsprechende Dateiobjekte 9
gespeichert werden kann. Bezüglich weiterer Details wird beispielsweise auf den Artikel „Inodes" der
englischsprachigen Online-Enzyklopädie Wikipedia verwiesen (http://en.wikipedia.org/wiki/Inode, Fassung vom 27.10.2013). In der Figur IC ist eine Dateiliste 10 dargestellt. Die
Dateiliste 10 umfasst Listeneinträge 11 für reguläre Dateien. Jeder Listeneintrag 11 umfasst wenigstens eine vollständige Pfadangabe 12, bestehend aus einer einfache Pfadangabe 13 zum Verzeichnis, in dem die Datei gespeichert ist, sowie dem eigentlich Dateinamen 14, eine nummerische Adresse 15 des der Datei zugeordneten Inodes 7 sowie weitere Attribute 16 der Datei, wie beispielsweise das Datum einer Erstellung oder letzten Änderung der Datei. Die Informationen der Dateiliste 10 können beispielsweise von Softwarekomponenten eines
Archivierungssystems verwendet werden, um zu entscheiden, welche Dateiobjekte 9 des zweiten Speicherbereichs 6 auf einem weiteren Speichermedium, wie beispielsweise einem magnetischen Sicherungsband, gespeichert werden müssen. Solche Dateilisten 10 sind unter anderem in hierarchischen Speichersystem (HSM) aber für andere Systeme und Programme zur Verwaltung umfangreicher Daten erforderlich.
Problematisch an bekannten POSIX-kompatiblen Dateisystemen ist, dass die Erstellung einer solchen Dateiliste 10 unter anderem eine erhebliche Zeit in Anspruch nimmt. Insbesondere bei sogenannten „Big Data"-Systemen mit Millionen von über unterschiedliche Knoten eines Clustersystems verteilte
Dateien ist die Erstellung oder Laufendhaltung einer
entsprechenden Dateiliste 10 in der dafür zur Verfügung stehender Zeit mit bekannten Dateisystemen unmöglich.
Nachfolgend wird anhand der Figuren 2A und 2B beschrieben, wie anhand der auf dem physikalischen Datenträger 4
gespeicherten Informationen in konventionellen Dateisystemen eine Dateiliste 10 gemäß Figur IC erstellt werden kann. Dabei zeigt Figur 2A schematisch die dazu verwendeten
Datenstrukturen und Figur 2B ein Ablaufdiagramm eines
konventionellen Verfahrens zum Abarbeiten eines
Verzeichnisbaums 1 zur Erstellung der Dateiliste 10.
In einem ersten Schritt 20 wird der Inode 7r des
Wurzelverzeichnisses 3 bestimmt und geladen. Beispielsweise kann ein Inode-Eintrag mit der Adresse „0" aus dem ersten Speicherbereich 5 eingelesen werden. Gleichzeitig wird in einer Arbeitsvariable p der aktuelle Pfad festgehalten, der in diesem Fall durch einen einfachen „/" dargestellt ist. Nachfolgend wird in einem Schritt 21 ein zugehöriges
Verzeichnisobjekt 8r von dem zweiten Speicherbereich 6 geladen. Das Verzeichnisobjekt 8r umfasst in dem in Figur 2A dargestellten Ausführungsbeispiel drei Verzeichniseinträge 17 für die Verzeichnisse A, B und C der ersten Hierarchieebene.
Dementsprechend wird in einem nachfolgenden Schritt 22 festgestellt, dass in dem Verzeichnisobjekt 8r noch zu verarbeitenden Verzeichniseinträge 17 vorhanden sind. Im nachfolgenden Schritt 23 wird zunächst der erste
Verzeichniseintrag 17A bezüglich des an dieser Stelle noch unbekannten Speicherobjektes A eingelesen. Aus dem
Verzeichniseintrag 17A ergibt sich, dass dem Speicherobjekt A der Inode 7A mit der Adresse „1" zugeordnet ist. Des Weiteren ergibt sich aus dem Verzeichniseintrag 17A der Name „A" des Speicherobjekt A. Im nachfolgenden Schritt 24 wird der zugehörige Inode 7A des Speicherobjektes A mit der Adresse „1" eingeladen, um die zum Speicherobjekt A gehörigen Metadaten zu bestimmen.
Im Schritt 25 wird überprüft, um was für eine Art Objekt es sich bei dem Speicherobjekt A handelt. Aus den geladenen Metadaten des Inodes 7A kann beispielsweise anhand der so genannten Modus-Informationen bestimmt werden, ob es sich dabei, wie im vorliegenden Fall, um ein weiteres Verzeichnis oder eine reguläre Datei oder ein sonstiges Objekt eines POSIX-kompatiblen Dateisystems 2 handelt. In der Figur 2B ist aus Gründen der einfacheren Darstellung lediglich die
Verarbeitung von Dateien und Verzeichnissen angedeutet.
Handelt es sich wie vorliegend um ein weiteres
Verzeichnisobjekt 8, wird in einem nachfolgenden Schritt 26 die Arbeitsvariable für den zu untersuchenden Pfad p um den im Schritt 23 bestimmten Namen ergänzt. Des Weiteren wird das bis jetzt gültige Verzeichnis in einer weiteren Variablen q zwischengespeichert. Danach wird das Verfahren rekursiv im Schritt 21 mit dem Laden des zugehörigen Verzeichnisobjekts 8A fortgesetzt. Im beschriebenen Beispiel enthält das Verzeichnis A lediglich reguläre Dateiobjekte 9 für die Dateien al und a2.
Dementsprechend wird bei der nachfolgenden Überprüfung im Schritt 25 festgestellt, dass die Verzeichniseinträge 17 des Verzeichnisobjekts 8A auf reguläre Dateien verweisen. In einem Schritt 27 wird dementsprechend ein Listeneintrag 11 für die Dateiliste 10 basierend auf dem aktuellen Pfad p und dem im Schritt 23 aus dem Verzeichniseintrag 17 entnommenen Dateinamen „al" generiert. Danach wird das Verfahren im
Schritt 22 für den nächsten Verzeichniseintrag 17
fortgesetzt. Entsprechend wird in einem nachfolgenden Umlauf im Schritt 27 ein weiterer Listeneintrag 11 für die Datei a2 erzeugt . In einem erneuten Aufruf des Schritts 22 wird festgestellt, dass keine weiteren Verzeichniseinträge 17 in dem Verzeichnis A zu verarbeiten sind. Dementsprechend wird in einem
nachfolgenden Schritt 28 der Pfad auf das übergeordnete
Verzeichnis des Verzeichnisses A zurückgesetzt, also dem Wurzelverzeichnis „/", und das Verfahren wird auf der nächst höhere Ebene im Schritt 22 fortgesetzt.
Durch das beschriebene Verfahren wird der in der Figur 1A dargestellte Verzeichnisbaum 1 nach und nach durch den rekursiven Algorithmus besucht, wobei Verzeichniseinträge 17 für Dateiobjekte 9 in der Dateiliste 10 erzeugt werden.
Wie sich insbesondere aus der Darstellung gemäß Figur 2A ergibt, verursacht das Verfahren gemäß Figur 2B ein
regelmäßigen Hin- und Herspringen zwischen dem ersten
Speicherbereich 5 und dem zweiten Speicherbereich 6. Das liegt insbesondere darin begründet, dass ohne Auslesen der Information der Inodes 7 aus dem ersten Speicherbereich 5, die zugehörigen Verzeichnisobjekte 8 und Dateiobjekte 9 in dem zweiten Speicherbereich 6 nicht ausfindig gemacht werden können. Umgekehrt stehen in den Inodes 7 des ersten
Speicherbereichs 5 nicht sämtliche Informationen zur
Verfügung, um beispielsweise Namen oder Pfadangaben einzelner Dateien zu bestimmen oder die hierarchische Struktur des Verzeichnisbaumes 1 zu ermitteln. In der Praxis weist dieses Vorgehen daher den Nachteil auf, dass eine häufige
Neupositionierung von Schreib-/Lese-Köpfen oder sonstigen Lesevorrichtungen eines physikalischen Datenträgers 4 erforderlich sind, um die Dateiliste 10 zu erstellen.
Insbesondere bei sehr umfangreichen Datensammlungen, wie sie beispielsweise bei Archivierungssystemen auftreten, führt dies in der Praxis zu langen Laufzeiten und daher zu
Problemen bei häufig ablaufenden Prozessen.
Figur 3A zeigt eine verbesserte Datenstruktur zur Abbildung des eingangs beschriebenen Verzeichnisbaumes 1. Insbesondere ist in den einzelnen Inodes 7 zusätzlich zu den oben
genannten Informationen jeweils der Name des zugehörigen
Dateiobjekts 9 bzw. Verzeichnisobjekts 8 gespeichert. In den Inodes 7 ist ebenfalls ein Rückverweis 18 auf den Inode 7 eines übergeordneten Verzeichnisobjektes 8 gespeichert, also in dem Inode 7A des Verzeichnisses A beispielsweise ein
Verweis auf den Inode 7r. Nur im Inode 7r des
Wurzelverzeichnisses 3 selbst findet sich dort kein Eintrag.
Optional kann in allen Inodes 7 ein weiterer Verweis auf einen vorbestimmten Bezugspunkt des Dateisystems 2
gespeichert werden (in der Figur 3A nicht dargestellt) . Im
Fall des einfachen Verzeichnisbaums 1 gemäß Figur 1A verweist der Eintrag für den Bezugspunkt direkt auf das
Wurzelverzeichnis 3. Bei komplexeren Verzeichnisbäumen, die über mehrere Datenträger verteilt sind entsprechend mehrere Mountpoints aufweisen, verweist der Bezugspunkt auf den
Mountpoint des die Datei enthaltenen Dateisystems. Auf diese Weise bleiben die in den Inodes 7 gespeicherten Metadaten auch dann gültig, wenn das betreffende Dateisystem an anderer Stelle in einem übergeordneten Dateisystem, insbesondere dem Stammdateisystem, eingebunden wird.
Der Name des zugehörigen Dateiobjekts 9 beziehungsweise
Verzeichnisobjekts 8, der Rückverweis 18 und gegebenenfalls der Verweis auf den Bezugspunkt können beispielsweise als erweiterte Attribute bekannter Dateisysteme, beispielsweise durch Verwendung der sogenannten xattr-Funktion, gespeichert werden .
Figur 3B zeigt ein verbessertes Verfahren zum Erstellen der Dateiliste 10 basierend auf der Datenstruktur gemäß Figur 3A.
In einem ersten Schritt 30 wird überprüft, ob weitere Inodes 7 einer Liste von Inodes zu verarbeiten sind. Beispielsweise kann die Inode-Liste sämtliche Inodes 7 des ersten
Speicherbereichs 5 umfassen.
Ist dies der Fall wird im Schritt 31 der nächste zu
verarbeitende Inode 7 eingelesen. In einem nachfolgenden Schritt 32 wird überprüft, ob der Inode 7 einem regulären Dateiobjekt 9 zugeordnet ist. Ist dies nicht der Fall, kann die Verarbeitung im Schritt 30 unmittelbar mit dem nächsten Inode 7 fortgesetzt werden.
Wird dagegen im Schritt 32 festgestellt, dass der zuletzt gelesene Inode 7 einem regulären Dateiobjekt 9 zugeordnet ist, beispielsweise der Datei al, werden im Schritt 33 die Adresse 15 des Inode 7 sowie der zugehörige Name „al" des Dateiobjekts 9 in einer Variable n zwischengespeichert.
In einem Schritt 34 wird nachfolgend der Inode 7A geladen, den der Rückverweis 18 des zuvor geladenen Inodes 7 als Inode 7A des übergeordneten Verzeichnisobjektes 8A referenziert . Nachfolgend wird in einem Schritt 35 die Variable n um den Namen „A" des übergeordneten Verzeichnisses A ergänzt. In einem Schritt 36 wird überprüft, ob es sich bei dem übergeordneten Verzeichnis bereits um das Wurzelverzeichnis 3 handelt. Ist dies der Fall, wird in einem Schritt 37 die nun in der Variable n enthaltene, vollständige Pfadangabe 12 umfassend die Pfadangabe 13 sowie den Dateinamen 14 in der Dateiliste 10 sowie die Adresse 15 des Inodes 7 gespeichert, der der regulären Datei „al" zugeordnet ist. Danach wird das Verfahren im Schritt 30 mit der Verarbeitung eventuell weiterer Inodes 7 der Inode-Liste fortgesetzt. Wird im Schritt 36 jedoch festgestellt, dass es sich noch nicht um das Wurzelverzeichnis 3 handelt, wird das Verfahren im Schritt 34 mit dem Laden des Inodes 7 des dem aktuellen Verzeichnis übergeordneten Verzeichnisses fortgesetzt, so dass der Pfad im Schritt 35 um die nächsthöhere
Verzeichnisebene ergänzt wird, bis das Verfahren schließlich am Wurzelverzeichnis 3 ankommt. Auf diese Weise kann für jeden Inode 7 durch Folgen der Rückverweise 15 auf
übergeordnete Inodes 7 in sehr kurzer Zeit eine vollständige Pfadangabe 12 ermittelt werden. In konventionellen
Dateisystem 2 wäre dagegen der Aufbau bzw. die Suche über einen vollständigen Verzeichnisbaum 1 erforderlich. Das Verfahren gemäß Figur 3B weist eine Reihe von Vorteilen gegenüber dem Verfahren gemäß Figur 2B auf. Insbesondere kann beim Erstellen der Dateiliste 10 ein Hin- und Herspringen zwischen dem ersten Speicherbereich 5 und dem zweiten
Speicherbereich 6 auf dem physikalischen Datenträger 4 vermieden werden. Sämtliche zur Erstellung der Dateiliste 10 erforderliche Daten sind vollständig in den Inodes 7
gespeichert . Gleichzeitig kann auf eine vollständige rekursive Abarbeitung des Verzeichnisbaumes 1 verzichtet werden. Insbesondere ist es möglich, einen linearen Scan über sämtliche Inodes 7 durchzuführen, die in dem ersten Speicherbereich 5
gespeichert sind. Lediglich für die Inodes 7, die einem regulären Dateiobjekt 9 zugeordnet und deren sonstige
Metadaten beispielsweise einem bestimmten Suchprofil
entsprechen, müssen durch einen rekursiven Algorithmus um eine vollständige Pfadangabe 12 ergänzt werden. Insbesondere wenn bereits auf Grundlage einer Vorfilterung eine Vielzahl von Inodes 7 von dieser Bearbeitung
ausgeschlossen werden können, beispielsweise bei einem
Archivsystem, das nur die Dateinamen von seit einem letzten Sicherungszeitpunkt geänderten Dateien erfasst, spielt dieser rekursive Anteil des Algorithmus jedoch nur eine
untergeordnete Bedeutung für dessen Laufzeitverhalten.
In einer nicht bildlich dargestellten Abwandlung der
Ausgestaltung nach Figur 3A enthalten die Inodes 7 lediglich den Rückverweis auf das übergeordnete Verzeichnisobjekt 8, jedoch kein Attribut mit dem Namen des dem Inode 7
zugehörigen Dateiobjekts 9 oder Verzeichnisobjektes 8. In dieser Ausgestaltung muss zur Erstellung einer Dateiliste 10 noch auf die Verzeichnisobjekte 8 des zweiten
Speicherbereichs 6 zugegriffen werden. Allerdings kann die Anzahl der I/O-Zugriffe bereits in dieser Ausgestaltung deutlich reduziert werden, wenn nur Pfade für einen
verhältnismäßig kleinen Anteil der Inodes 7 bestimmt werden müssen. Beispielsweise können, wie später ausgeführt, aufgrund der sonstigen in dem Inode 7 enthaltenen Metadaten nur bestimmte Dateien für eine weitere Bearbeitung, etwa eine Sicherung, ausgewählt werden. Werden beispielsweise nur 1% der gespeicherten Dateiobjekte 9 gesichert, ist der Aufbau von Pfadangaben für die ausgewählten Inodes 7 durch Einlesen von wenigen Verzeichnisobjekten 8 immer noch mit deutlich weniger I /O-Zugriffen verbunden als ein komplettes
Durchsuchen des Verzeichnisbaumes 1.
Die Figuren 4A und 4B zeigen eine Datenstruktur
beziehungsweise ein Arbeitsverfahren gemäß einer weiteren Ausgestaltung der Erfindung. Wie insbesondere der Figur 4A zu entnehmen ist, ist in den Inodes 7 gemäß der weiteren
Ausgestaltung an Stelle des Namens des Speicherobjektes und dem Rückverweis 18 auf den Inode 7 eines übergeordneten
Verzeichnisobjektes 8 eine Pfadangabe 12, zumindest ab dem übergeordneten Mountpoint gespeichert. Des Weiteren ist in jedem Inode 7 ein Verweis 19 auf den Inode 7 eines
übergeordneten Bezugspunktes gespeichert. In der
beschriebenen Ausgestaltung dient als Bezugspunkt für Objekte des Stammdateisystems das Wurzelverzeichnis 3, hier ein
Verweis auf den Inode 7r. Für Objekte anderer in das
Stammdateisystem eingebundener Dateisysteme, beispielsweise anderen Partitionen einer Festplatte, Netzwerkvolumes oder wechselbaren Speichermedien, wird als Bezugspunkt der Inode des Mountpoints des entsprechenden eingebundenen Dateisystems gespeichert, an dem die Pfadangabe 12 beginnt. Schließlich ist in jedem Inode 7 zusätzlich ein Sicherungsdatum 20 gespeichert, das den Zeitpunkt einer letzten Sicherung des zugehörigen Objekts auf einem weiteren Speichermedium, beispielsweise einem Bandspeichermedium, durch eine
Sicherungskomponente angibt.
In einer Abwandlung der Ausgestaltung gemäß den Figuren 4A und 4B wird ein fester Bezugspunkt, beispielsweise das
Wurzelverzeichnis 3 oder ein anderer festgelegter Knoten des Dateisystems 2, fest vorgegeben oder anderer Stelle
gespeichert. In dieser Ausgestaltung kann auf die Speicherung des Verweises 19 in den Inodes 7 verzichtet werden. Bevorzugt wird in dieser Ausgestaltung nur ein einzelnes zusätzliches Attribut, nämlich eine vollständige Pfadangabe 12 umfassend die einfache Pfadangabe 13 ab dem Wurzelverzeichnis 3 und der Dateiname 14 selbst, als eine zusammenhängende Zeichenkette gespeichert .
Die Datenstruktur gemäß Figur 4A und deren oben beschriebene Abwandlung eignen sich zur noch schnelleren Erstellung von Dateilisten 10. In dem Ausführungsbeispiel handelt es sich bei dem Dateisystem 2 um ein so genanntes WORM-Dateisystem, in dem nach dem erstmaligen Schreiben einer Datei oder dem Erstellen eines Verzeichnisses keine Namensänderungen oder Verschiebungen mehr möglich sind. Da sich somit effektiv der Pfad zu einer einmal gespeicherten Datei ab dem gegebenen Bezugspunkt, entweder einem Mountpoint oder dem
Wurzelverzeichnis 3, nicht mehr ändern kann, kann die
vollständige Pfadangabe 12 wie in der Figur 4A dargestellt zusammenhängend in einem erweiterten Attribut eines Inodes 7 gespeichert werden. Die Erstellung einer Dateiliste gestaltet sich in diesem Fall besonders einfach. In einem ersten Schritt 40 wird überprüft, ob noch weitere Inodes 7 einer Liste von Inodes zu bearbeiten sind. Ist dies der Fall, wird im Schritt 41 der zunächst zu bearbeitende Inode 7 geladen. Nachfolgend wird im Schritt 42 überprüft, ob der geladene Inode 7 einem regulären
Dateiobjekt 9 zugeordnet ist. Ist dies nicht der Fall, kann das Verfahren im Schritt 40 mit der Verarbeitung eventuell weiterer Inodes 7 fortgesetzt werden. Andernfalls kann im Schritt 43 unmittelbar ein Eintrag für die Dateiliste 10 erstellt werden. Handelt es sich bei dem gespeicherten
Bezugspunkt direkt um das Wurzelverzeichnis 3 können die in dem aktuellen Inode 7 gespeicherten Informationen zur
vollständigen Pfadangabe 12 des Datenobjekts 9 direkt zur Erstellung des Eintrags verwendet werden. Bei komplexeren Dateisystemen mit mehreren Mountpoints muss gegebenenfalls noch ein Pfad vom Wurzelverzeichnis 3 bis zum jeweiligen gespeicherten Mountpoint bestimmt werden. Auch dies ist in der Regel ohne weitere I/O-Zugriffe auf einen Massenspeicher möglich, da selbst in komplexen Dateisystem in der Regel nur wenige Mountpoints vorhanden sind, die an einem zentralen Ort, insbesondere einer so genannten Dateisystemtabelle fstab (Englisch: filesystem table), gespeichert sind. Der Inhalt der Dateisystemtabelle fstab wird für eine Vielzahl
verschiedene Zwecke benötigt und ist daher in der Regel in einem Cachespeicher oder einer sonstigen speicherresidenten Datenstruktur gespeichert. Somit kann der Eintrag durch
Kombination eines zwischengespeicherten Pfades bis zu dem angegebenen Mountpoint und den in den Inode 7 gespeicherten Daten zur Pfadangabe gebildet werden. Danach wird das
Verfahren im Schritt 40 mit dem gegebenenfalls vorhandenen nächsten Inode 7 fortgesetzt. Auch das Verfahren gemäß Figur 4B besitzt den Vorteil, dass allein die in den Inodes 7 gespeicherten Informationen zur Erstellung der Dateiliste 10 genügen. Darüber hinaus besitzt das Verfahren gemäß Figur 4B den Vorteil, dass nun überhaupt keine rekursive Erstellung von Pfadangaben mehr erforderlich ist. Stattdessen kann die Dateiliste 10 durch einen
einfachen, linearen Algorithmus erstellt werden, der die in der Regel aufeinander folgend gespeicherten Inodes 7
sequenziell abarbeitet. Durch diese Vorgehensweise ist bei Dateisystem mit einigen Millionen Inodes 7 eine
Beschleunigung von etwa einem Faktor 100 gegenüber bekannten Verzeichnis-Suchläufen möglich.
Sofern eine Entscheidung bezüglich einer möglichen weiteren Verarbeitung der Datenobjekte 9 allein auf Grundlage der in den Inodes 7 gespeicherten Metadaten getroffen werden kann, müssen die Daten des zweiten Speicherbereichs 6 überhaupt nicht mehr eingelesen werden, was zu einer weiteren
wesentlichen Beschleunigung des Verfahrens führt.
Im dargestellten Beispiel dient hierzu unter anderem das zusätzliche Sicherungsdatum 20. Im beschriebenen
Ausführungsbeispiel sollen sämtliche Objekte des Dateisystems regelmäßig auf einem weiteren Speichermedium, beispielsweise einem Magnetband, gesichert werden. Dabei wird ein
sogenanntes inkrementelles Sicherungsverfahren verwendet, bei dem nur seit einer vorhergehenden Sicherung neu
hinzugekommene oder geänderte Objekte gesichert werden sollen. Die Entscheidung, welche Objekte bei einem
anstehenden Sicherungslauf gesichert werden müssen, kann allein auf Grundlage der in den Inodes 7 gespeicherten
Informationen getroffen werden. Insbesondere ist in der Figur 4A zu erkennen, dass das Wurzelverzeichnis 3 seit der letzten Sicherung am 01.07.2012 nicht mehr geändert wurde und daher nicht gesichert werden muss. Dagegen wurde das Verzeichnis A zuletzt am 03.07.2012 und damit nach seiner letzten Sicherung am 01.07.2012 geändert und muss dementsprechend gesichert werden. Die reguläre Datei al wurde noch überhaupt nicht gesichert und muss daher ebenfalls gesichert werden.
Figur 5 zeigt eine Speichervorrichtung 50 gemäß einem
Ausführungsbeispiel der Erfindung. Bei der
Speichervorrichtung 50 handelt es sich beispielsweise um eine so genannte Storage Appliance, die die Archivierung
unterschiedlicher Versionen von Dateien oder sonstigen
Datenobjekten ermöglicht. Dabei wird zumindest die jeweils aktuelle Version einer Datei auf einem leistungsfähigen, im Ausführungsbeispiel internen Massenspeicher 51 vorgehalten. Zusätzlich werden Kopien der aktuellen Version sowie
gegebenenfalls vorhandener vorhergehender Versionen auf einem weiteren Speichermedium vorgehalten. In der Figur 5 ist beispielsweise angedeutet, dass solche Kopien auf einem, im Ausführungsbeispiel externen Bandlaufwerk 52 oder in einem so genannten Cloudspeicher 53, also einer über ein
Datennetzwerk, insbesondere das Internet, angebundenen
Speichersystem gespeichert werden. Die Speichervorrichtung 50 gemäß Figur 5 weist eine erste Schnittstelle 54 zum Zugriff auf die in der
Speichervorrichtung 50 gespeicherten Daten auf.
Beispielsweise handelt es sich dabei um eine Schnittstelle gemäß dem NFS-Protokoll für die Unix-Betriebssystemfamilie oder eine Schnittstelle gemäß dem CIFS-Protokoll für die
Windows-Betriebssystemfamilie. Über die erste Schnittstelle 54 können die aus diesen Protokollen bekannten Anfragen zum Schreiben und Lesen sowie gegebenenfalls zum Löschen und Umbenennen einzelner Dateien an die Speichervorrichtung 50 übermittelt werden.
Im Ausführungsbeispiel werden die über die Schnittstelle 54 empfangenen Befehle über eine Verarbeitungskomponente 55 der Speichervorrichtung 50 analysiert und, soweit zulässig, umgesetzt. Im Ausführungsbeispiel dient dazu eine
Softwarekomponente, die auf einem nichtflüchtigen
Speichermedium der Speichervorrichtung 50 gespeichert ist. Die Verarbeitungskomponente 55 setzt die entsprechenden
Anforderungen in an sich bekannter Weise für ein Dateisystem 2 des Massenspeichers 51, beispielsweise das für
Clustersysteme besonders geeignete GPFS-Dateisystem
(Englisch: „General Parallel File System") der Firma IBM, um.
Bei der Konfiguration des gesamten oder eines Teils der
Speichervorrichtung 50 als WORM-Systemen werden Anfragen zum Ändern und Umbenennen von Dateien und Verzeichnissen mit einer entsprechenden Fehlermeldung quittiert und nicht ausgeführt. Ein Löschen einer Datei ist entweder gar nicht oder erst nach Ablauf einer vorbestimmten Aufbewahrungsfrist zulässig. Unzulässige Löschbefehle werden ebenfalls mit einer Fehlermeldung quittiert. Bei zulässigen Löschbefehlen, insbesondere auch Löschbefehle für reguläre Dateien in einem gewöhnlichen, wiederbeschreibbaren Dateisystemen, wird das Löschen einer Datei in einer zusätzlichen Protokoll-Datei eingetragen, die bei der späteren Erstellung von Dateilisten 10 und ähnlichen auf den Metainformationen beruhenden
Informationen entsprechend berücksichtigt wird.
Beispielsweise wird ein entsprechender Inode 7 durch
Speicherung eines zusätzlichen Attributs oder durch
Speicherung eines vorbestimmten Werts in einem vorhandenen Attribut als ungültig und damit das zugehörige Objekt als gelöscht gekennzeichnet.
Zusätzlich zu der Umsetzung der eigentlichen Anfrage werden in der beschriebenen Ausgestaltung noch bestimmte
vorhergehende und nachfolgende Aktionen ausgeführt, um die zusätzliche Metadaten zu speichern. Insbesondere werden beim Schreiben von neuen Dateien oder Verzeichnissen zugehörige Metadaten in dem zugehörigen Inode 7 des Dateisystems 2 des Massenspeichers 51 abgelegt. Hierzu umfasst die
Softwarekomponente einen sogenannten Dämon-Prozess , der auf Ereignisse gemäß der sogenannten Data Management API (DMAPI) Schnittstelle reagiert und unter anderem die für die oben beschriebenen Verfahren erforderlichen Zusatzinformationen in erweiterten Attributen des GPFS-Dateisystems speichert.
Beispielsweise können über die DMAPI-Schnittstelle die
Ereignisse „create" und „postcreate" für die Erstellung von Dateien abgefangen werden. Alternativ ist es auch möglich, die erforderlichen
Zusatzinformationen in einem einmaligen und/oder regelmäßig durchgeführten Suchlauf über alle Verzeichnisse zu ermitteln. Beispielsweise können in einem ersten Schritt sämtliche
Verzeichnisobjekte 8 eines Dateisystems 2 auf Änderungen seit einem letzten Suchlauf überprüft werden. In einem zweiten Schritt werden die Inodes 7 der Verzeichniseinträge 17 der geänderten Verzeichnisobjekte 8 ermittelt. Für diese Inodes 7 werden dann in einem dritten Schritt entsprechende
Zusatzinformationen gespeichert. Optional kann vor einem erneuten Speichern zunächst überprüft werden, ob die Inodes 7 bereits aktuelle Zusatzinformationen enthalten. Die Speichervorrichtung 50 umfasst des Weiteren eine zweite Schnittstelle 56 zur Administration. Über die zweite
Schnittstelle 56 hat ein Systemadministrator oder sonstiger berechtigter Benutzer Zugriff auf einen Konfigurationsdialog 57, mit dem das Verhalten der Speichervorrichtung 50 im
Detail konfiguriert werden kann. Beispielsweise kann über den Konfigurationsdialog 57 ausgewählt werden, ob sich das über die Schnittstelle 57 bereitgestellte Dateisystem des
Massenspeichers 51 oder einzelne Bereiche davon wie ein WORM- Speichermedium oder wie ein normales, mehrfach (über-) schreibbares Speichermedium verhalten soll.
Die Speichervorrichtung 50 umfasst des Weiteren eine Scan- Komponente 58, die unter anderem zur Verarbeitung der
zusätzlich in den Inodes 7 gespeicherten Metadaten dient. Darüber hinaus umfasst die Speichervorrichtung 50 einen so genannten Object-Mover 59, der für die bedarfsweise Sicherung von Dateien auf einem anderen Speichermedium verantwortlich ist. Eine Sicherung kann aus verschiedenen Gründen heraus erfolgen. Beispielsweise kann es sich um eine regelmäßige
Sicherung (Englisch: backup) der in der Speichervorrichtung 50 gespeicherten Objekte handeln. Alternativ kann es sich auch um eine Auslagerung einer Datei oder Dateiversion in einem hierarchischen Speichersystem bzw. Archivsystem
handeln, bei dem beispielsweise lange nicht benutzten Dateien bzw. veralteten Versionen, von dem Massenspeicher 51 auf das Bandlaufwerk 52 und/oder den Cloudspeicher 53 verschoben werden. Dabei erstellt der Objekt-Mover 59 am Zielort ein neues Objekt, das zumindest die Daten des gesicherten Objekts und gegebenenfalls weitere Metadaten zur Sicherung enthält. Zusätzlich werden die in den Inodes 7 des Dateisystems des Massenspeichers 51 gespeicherten Metadaten entsprechend aktualisiert. Beispielsweise wird bei einer Sicherung in einem erweiterten Attribut das aktuelle Datum als letztes Sicherungsdatum 20 vermerkt. Alternativ kann bei einer
Auslagerung das dem Inode 7 zugehörige Objekt als von dem Massenspeicher 51 gelöscht gekennzeichnet oder durch einen sogenannten Stub ersetzt werden, der auf den neuen
Speicherort verweist.
Die Speichervorrichtung 50 umfasst des Weiteren einen so genannten Backup-Manager 60 der für die selbsttätige
Datensicherung von auf dem Massenspeicher 51 gespeicherten
Daten entsprechend Voreinstellungen des Konfigurationsdialogs 57 verantwortlich ist. Um diese Aufgabe möglichst effizient durchführen zu können, greift der Backup-Manager 60 unter anderem auf die Scan-Vorrichtung 58 zu, um Objekte
auszuwählen, die durch den Object-Mover 59 von dem internen Massenspeicher 51 auf ein weiteres, externes Speichermedium gesichert werden sollen.
Nachfolgend wird anhand der Figur 5 ein so genanntes
„Incremental forever"-Sicherungssystem beschrieben. Der
Begriff der unendlichen, inkrementellen Sicherung soll dabei zum Ausdruck bringen, dass nach einer anfänglichen
Grundsicherung stets nur die seit der letzten Sicherung neu auf dem Massenspeicher 51 gespeicherten oder geänderten
Objekte, insbesondere reguläre Dateien und
Verzeichnisobjekte, gesichert werden. Selbstverständlich können auch andere Sicherungsstrategien, wie beispielsweise eine differenzielle Sicherung, bei der stets der Unterschied seit einer letzten Grundsicherung gesichert wird, oder eine Vollsicherung, bei der stets der gesamte Inhalt oder
vorbestimmte Teile des Massenspeichers 51 gesichert wird, verwendet werden. Über die Konfigurationsschnittstelle 57 werden verschiedene Systemparameter vorgegeben. Beispielsweise wird ein so genannter Mountpoint eines Dateisystems 2, für die die inkrementelle Sicherung durchgeführt werden soll, bestimmt. Darüber hinaus kann ein zeitlicher Abstand zwischen
verschiedenen zu sichernden Dateiversionen vorgegeben werden. Beispielsweise kann vorgegeben werden, dass die
Speichervorrichtung 50 stündlich, täglich oder wöchentliche Sicherung der in dem Massenspeicher 51 gespeicherten Dateien vornimmt. Auch weitere Kriterien, wie beispielsweise die minimale oder maximale Größe zu sichernder Dateien können über den Konfigurationsdialog 57 vorgegeben werden.
Ist ein vorbestimmter Sicherungszeitpunkt oder ein sonstiges eine Sicherung auslösendes Ereignis erreicht, müssen zunächst sämtliche Dateien des Massenspeichers 51 bestimmt werden, die aktuell gesichert werden müssen. Hierzu verwendet die
Speichervorrichtung 50 die Scan-Vorrichtung 58 um alle
Dateien zu bestimmen, deren Erstellungs- oder Änderungsdatum zeitlich nach dem Datum der letzten Sicherung liegt. Es wird angemerkt, dass diese Informationen im Ausführungsbeispiel gemäß Figur 4A bereits als Sicherungsdatum 20 in den Inodes 7 des Dateisystems 2 enthalten sind. Somit kann allein auf Grundlage eines Scans sämtlicher Inodes 7 festgestellt werden, welche Dateiobjekte 9 grundsätzlich für eine
Sicherung in Erwägung zu ziehen sind, ohne die einzelnen Dateiobjekte 9 des zweiten Speicherbereichs 6 zu laden.
Alternativ kann das Datum der letzten Sicherung auch an anderer Stelle in der Speichervorrichtung gespeichert sein. Beispielsweise kann ein global für alle Objekte des
Massenspeichersystems 51 gültiger Sicherungszeitpunkt
gespeichert oder bestimmt werden. Im Falle einer differenziellen Sicherung ist statt dem Datum der letzten Sicherung das Datum der letzten Vollsicherung zu verwenden.
Nur für die Objekte, die seit dem Zeitpunkt der letzten
Sicherung geändert wurden, werden nachfolgend basierend auf den in den Inodes 7 enthaltenen Metadaten, insbesondere dem darin enthaltenen Dateinamen 14 und/oder weiteren
Informationen einer Pfadangabe 12 oder 13 eine entsprechende Dateiliste 10 mit zu sichernden Objekten erstellt. Die zu erstellende Dateiliste 10 kann neben den Pfadangaben 12 oder 13 und/oder dem Dateinamen 14 weitere Informationen,
insbesondere einen direkten Verweis auf den zugehörigen Inode 7, die Größe der Datei und sonstige Informationen der
Metadaten enthalten. Eine derartige Liste 10 kann
beispielsweise an den Objekt-Mover 59 übergeben werden, um für geänderte Dateien neue Sicherungsobjekte auf dem
Bandlaufwerk 52 oder dem Cloudspeicher 53 zu speichern.
Neben dem oben genannten Sicherungssystem eignen sich die Datenstrukturen gemäß den Figuren 3A und 4A sowie die
Algorithmen gemäß den Figuren 3B und 4B jedoch auch für eine Vielzahl von anderen Anwendungen. Insbesondere eignen sich die beschriebenen Mechanismen für eine Vielzahl von
Datenverarbeitungsaufgaben, bei denen Daten zumindest teilweise mit zugehörigen Metadaten verarbeitet werden.
Als weiteres Beispiel wird nachfolgend eine
Bildverwaltungssoftware skizziert, bei der aus einer großen Anzahl von vorhandenen Bilddaten einzelne Bilder auf
Grundlage von Metadaten herausgefiltert werden sollen, wie beispielsweise einem Erstellungszeitraum, einem Aufnahmeort oder Informationen über einem in dem Bild enthaltenen Motiv. Konventionell werden derartige Datenverarbeitungsaufgaben durch einen von zwei möglichen Ansätzen gelöst. Entweder werden die Metainformationen zusammen mit den eigentlichen Daten, hier also den Bilddaten, gespeichert. Dies hat den Nachteil, dass bei einer Suche über die Metadaten sämtliche Bilddateien geöffnet und zumindest teilweise eingelesen werden müssen. Werden im Falle der hier beschriebenen
Bilddaten zugehörige Metadaten beispielsweise als so genannte EXIF-Daten in einem Bildformat, wie beispielsweise einem JPEG-Bildformat, gespeichert, muss zunächst jeweils zumindest die KopfInformationen der jeweiligen Bilddatei eingelesen werden, bevor eine Verarbeitung möglich ist. Dies führt zu der bereits eingangs beschriebenen häufigen Neupositionierung von Leseköpfen eines Massenspeichers und somit zu einer langsameren Verarbeitungsgeschwindigkeit.
Ein anderer Ansatz besteht darin, die erforderlichen
Metadaten in einer gesonderten Datenbank, insbesondere einer relationalen Datenbank oder einer Objektdatenbank zu
speichern. In diesem Fall stehen alle zur Beantwortung einer Abfrage erforderlichen Angaben in einer gemeinsamen Datenbank für eine beschleunigte Verarbeitung zur Verfügung. Der zweite genannte Ansatz besitzt jedoch den Nachteil, dass Änderungen von anderen Softwarekomponenten an den gespeicherten Daten, beispielsweise einer Überarbeitung des Bilds durch ein
Bildverarbeitungsprogramm, gegebenenfalls durch die Datenbank nicht erkannt wird. Dementsprechend besteht grundsätzlich das Problem, die in der Datenbank gespeicherten Metadaten mit den eigentlichen Daten konsistent zu halten.
Gemäß einem Ausführungsbeispiel der Erfindung werden solche, anwendungsspezifische Metadaten, zusätzlich in den Inodes 7 des Dateisystems 2 gespeichert. Beispielsweise kann ein Aufnahmeort eines Fotos in den erweiterten Attributen eines GPFS-Dateisystems gespeichert werden. In diesem Fall sind die oben beschriebenen Verfahren zum Scannen einer umfangreichen Liste von Dateien anwendbar. Insbesondere kann dann allein auf Grundlage einer Liste von Inodes 7 bestimmt werden, welche weiteren Dateien für eine Verarbeitung, beispielsweise die Zusammenstellung einer Diashow, berücksichtigt werden müssen. Da die anwendungsspezifischen Attribute direkt in dem erweiterten Dateisystem 2 gespeichert werden, kann es hierbei auch nicht zu einer Diskrepanz zwischen den gespeicherten Metadaten einerseits und eventuell geänderten Bilddaten andererseits kommen.
Insbesondere bietet sich hierfür das bereits oben ausgeführte Verfahren unter Verwendung der DMAPI-Schnittstelle an. Werden entsprechende Mechanismen zum Erstellen und Laufendhalten der in den Inodes 7 gespeicherten erweiterten Metadaten auf
Dateisystemebene in eine Speichervorrichtung 50 integriert, werden diese stets unabhängig von einer verwendeten Anwendung laufend gehalten.
Bezugs zeichenliste
1 Verzeichnissystem
2 Dateisystem
3 Wurzelverzeichnis
4 physischer Datenträger
5 erster Speicherbereich
6 zweiter Speicherbereich
7 Inode
8 Verzeichnisobjekt
9 Dateiobjekt
10 Dateiliste
11 Listeneintrag
12 (vollständige) Pfadangabe 13 (einfache) Pfadangabe
14 Dateiname
15 Adresse (des Inodes)
16 weiteres Attribut
17 Verzeichniseintrag
18 Rückverweis
19 Verweis (auf Bezugspunkt)
20 Sicherungsdatum
50 Speichervorrichtung
51 Massenspeicher
52 Bandlaufwerk
53 Cloudspeicher
54 erste Schnittstelle
55 Verarbeitungskomponente
56 zweite Schnittstelle 57 Konfigurationsdialog
58 Scanvorrichtung
59 Object-Mover
60 Backup-Manager

Claims

Patentansprüche
1. POSIX-kompatibles Dateisystem (2) umfassend wenigstens ein Verzeichnis (A) und eine Mehrzahl in dem Verzeichnis (A) gespeicherten Dateien (al, a2), wobei
jeder Datei (al, a2) ein Inode (7) mit Metadaten über die jeweilige Datei (al, a2) zugeordnet ist;
das Verzeichnis (A) eine Zuordnung zwischen Dateinamen (14) der Mehrzahl von Dateien (al, a2) und dem jeweils einer Datei zugeordneten Inode (7) umfasst; und
die Metadaten über die jeweilige Datei (al, a2)
wenigstens den Dateinamen (14) der zugeordneten Datei (al, a2) und Informationen über das wenigstens eine Verzeichnis (A) umfassen.
2. POSIX-kompatibles Dateisystem (2) nach Anspruch 1, bei dem die Informationen über das wenigstens eine Verzeichnis (A) einen Verweis (18) auf einen dem Verzeichnis (A)
zugeordneten Inode (7A) umfasst.
3. POSIX-kompatibles Dateisystem (2) nach Anspruch 1, bei dem das Dateisystem (2) als WORM-Dateisystem ausgeführt ist und die Information über das wenigstens eine Verzeichnis (A) eine Pfadangabe (12, 13) der zugeordneten Datei (al, a2) von einem vorbestimmten Bezugspunkt, insbesondere einem
Mountpoint des WORM-Dateisystems, umfasst.
4. POSIX-kompatibles Dateisystem (2) nach Anspruch 3, bei dem die Metadaten über die jeweilige Datei (al, a2) eine vollständige Pfadangabe (12) mit einer Pfadangabe (13) zum Verzeichnis, in dem die Datei (al, a2) gespeichert ist, und dem Dateinamen (14) selbst umfasst.
5. POSIX-kompatibles Dateisystem (2) nach einem der
Ansprüche 1 bis 4, bei dem die Metadaten über die Datei (al, a2) zusätzlich einen Verweis (19) auf einen einem
vorbestimmten Bezugspunkt, insbesondere einen Mountpoint, des Dateisystems (2) zugeordneten Inode (7r) umfassen.
6. POSIX-kompatibles Dateisystem (2) nach einem der
Ansprüche 1 bis 5, bei dem der Dateiname (14) und die
Informationen über das wenigstens eine Verzeichnis (A) in einem erweiterten Attribut des Dateisystems (2) gespeichert sind .
7. Verfahren zum Erzeugen einer Dateiliste (10) mit Dateien eines POSIX-kompatiblen Dateisystems (2) mit den Schritten: - Scannen einer vorbestimmten Gruppe von Inodes (7) zum Erfassen von Metadaten einer Mehrzahl von den Inodes (7) jeweils zugeordneten Dateien (al, a2), wobei die Metadaten wenigstens den Dateinamen (14) der jeweils zugeordneten Datei (al, a2) und Informationen über ein Verzeichnis (A) umfassen, in dem die jeweilige Datei (al, a2) gespeichert ist;
Bestimmen von Dateinamen (14) und Pfadangaben (12, 13) von Dateien (al, a2) basierend allein auf den in den Inodes (7) gespeicherten Metadaten; und
Erzeugen einer Dateiliste (10) auf Grundlage der
bestimmten Dateinamen (14) und Pfadangaben (12, 13) .
8. Verfahren nach Anspruch 7, bei dem die Metadaten
wenigstens ein weiteres Attribut (16), insbesondere ein Datum einer letzten Sicherung (20) der jeweils zugeordneten Datei (al, a2) umfassen, wobei das wenigstens eine weitere Attribut (16) in die Dateiliste (10) übernommen wird und/oder eine Übernahme einer Datei in die Dateiliste (10) auf Grundlage des wenigstens einen weiteren Attribut (16) entschieden wird.
9. Verfahren nach Anspruch 8, bei dem
im Schritt des Scannens der vorbestimmten Liste von Inodes (7) überprüft wird, ob die Metadaten eines Inodes (7) wenigstens eine vorgegebene Bedingung erfüllen; und
im Schritt des Erzeugens der Dateiliste (10) nur dann ein Eintrag für eine einem Inode (7) zugeordnete Datei (al, a2) in der Dateiliste (10) erzeugt wird, wenn die vorgegebene Bedingung für die Metadaten des jeweiligen Inodes (7) erfüllt ist.
10. Verwendung von erweiterten Attributen eines POSIX- kompatiblen Dateisystems (2) für die Speicherung von
Metadaten der Datei (al, a2) in einem der Datei zugeordneten Inode (7), wobei die Metadaten wenigstens den Dateinamen (14) der jeweils zugeordneten Datei (al, a2) und Informationen über ein Verzeichnis (A) umfassen, in dem die jeweilige Datei (al, a2) gespeichert ist.
11. Speichervorrichtung (50), umfassend:
wenigstens eine Schnittstelle (54) zum Zugriff von durch die Speichervorrichtung (50) gespeicherten Dateien (al, a2); und
wenigstens ein Massenspeichersystem (51) zum
nichtflüchtigen Speichern der Dateien (al, a2);
wobei
die Speichervorrichtung (50) dazu eingerichtet ist, bei Erhalt eines Schreibbefehls zum Schreiben einer Datei (al, a2) über die wenigstens eine Schnittstelle (54), Metadaten über die wenigstens eine zu schreibende Datei (al, a2) in dem Massenspeichersystem (51) zu speichern, wobei die über die Datei (al, a2) gespeicherten Metadaten wenigstens den
Dateinamen (14) der Datei (al, a2) und Informationen über ein Verzeichnis (A) umfassen, in dem die Datei (al, a2)
gespeichert ist.
12. Speichervorrichtung (50) nach Anspruch 11, weiter umfassend wenigstens eine durch die Speichervorrichtung ausgeführte Softwarekomponente, wobei die wenigstens eine Softwarekomponente dazu eingerichtet ist, eine Dateiliste (10) allein auf Grundlage der gespeicherten Metadaten, insbesondere gemäß einem Verfahren nach einem der Ansprüche 7 bis 9, zu erzeugen.
13. Speichervorrichtung (50) nach Anspruch 12, bei dem die Softwarekomponente zur Dateiverwaltung eingerichtet ist und allein basierend auf den gespeicherten Metadaten Dateien für eine weitere Verarbeitung auswählt.
14. Speichervorrichtung (50) nach Anspruch 13, bei dem die Softwarekomponente zur Sicherung von Dateien (al, a2) basierend auf wenigstens einer in den Metadaten gespeicherten Zeitangabe, insbesondere eines Änderungs-, Erstellungs- , und/oder Sicherungsdatums (20) der den Metadaten zugeordneten Datei (al, a2), eingerichtet ist.
15. Speichervorrichtung (50) nach einem der Ansprüche 11 bis 14, die dazu eingerichtet ist, die Metadaten in den Dateien
(al, a2) zugeordneten Inodes (7) eines POSIX-kompatiblen Dateisystems (2) des wenigstens einen Massenspeichers (51) zu speichern .
16. Speichervorrichtung nach Anspruch 15, bei dem die
Speichervorrichtung (50) dazu eingerichtet ist, wenigstens einen Teil der gespeicherten Metadaten einer ausgewählten Datei (al, a2) umfassend den Dateinamen (14) der Datei (al, a2) und die Informationen über das Verzeichnis (A) , in dem die Datei (al, a2) gespeichert ist, als erweiterte Attribute über die wenigstens eine Schnittstelle (54) bereitzustellen.
EP14783855.1A 2013-12-17 2014-10-13 Posix-kompatibles dateisystem, verfahren zum erzeugen einer dateiliste und speichervorrichtung Withdrawn EP3084638A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102013114214.1A DE102013114214A1 (de) 2013-12-17 2013-12-17 POSIX-kompatibles Dateisystem, Verfahren zum Erzeugen einer Dateiliste und Speichervorrichtung
PCT/EP2014/071892 WO2015090668A1 (de) 2013-12-17 2014-10-13 Posix-kompatibles dateisystem, verfahren zum erzeugen einer dateiliste und speichervorrichtung

Publications (1)

Publication Number Publication Date
EP3084638A1 true EP3084638A1 (de) 2016-10-26

Family

ID=51691057

Family Applications (1)

Application Number Title Priority Date Filing Date
EP14783855.1A Withdrawn EP3084638A1 (de) 2013-12-17 2014-10-13 Posix-kompatibles dateisystem, verfahren zum erzeugen einer dateiliste und speichervorrichtung

Country Status (5)

Country Link
US (1) US20160283501A1 (de)
EP (1) EP3084638A1 (de)
JP (1) JP6430499B2 (de)
DE (1) DE102013114214A1 (de)
WO (1) WO2015090668A1 (de)

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9697227B2 (en) * 2014-10-27 2017-07-04 Cohesity, Inc. Concurrent access and transactions in a distributed file system
WO2016110785A1 (en) 2015-01-06 2016-07-14 Umbra Technologies Ltd. System and method for neutral application programming interface
EP3251301A4 (de) 2015-01-28 2018-10-10 Umbra Technologies Ltd. System und verfahren für ein globales virtuelles netzwerk
EP4325804A2 (de) 2015-04-07 2024-02-21 Umbra Technologies Ltd. Multiperimeter-firewall in der cloud
US10762041B2 (en) * 2015-08-31 2020-09-01 Netapp, Inc. Event based retention of read only files
US11106645B1 (en) * 2015-09-29 2021-08-31 EMC IP Holding Company LLC Multi point in time object store
US9824233B2 (en) 2015-11-17 2017-11-21 International Business Machines Corporation Posixly secure open and access files by inode number
US11106625B2 (en) 2015-11-30 2021-08-31 International Business Machines Corporation Enabling a Hadoop file system with POSIX compliance
ES2931177T3 (es) 2015-12-11 2022-12-27 Umbra Tech Ltd Sistema y método para lanzamiento de información a través de un tapiz de red y granularidad de una marca
WO2017187263A1 (en) 2016-04-26 2017-11-02 Umbra Technologies Ltd. Sling-routing logic and load balancing
US10178173B2 (en) * 2016-08-02 2019-01-08 International Business Machines Corporation Cloud service utilization
CN106354890B (zh) * 2016-11-22 2019-05-21 中国科学院上海微系统与信息技术研究所 一种基于N-ary树结构的随机访问的文件系统的实现方法
US20190005066A1 (en) * 2017-06-29 2019-01-03 International Business Machines Corporation Multi-tenant data service in distributed file systems for big data analysis
CN110019010B (zh) * 2017-11-14 2023-06-13 阿里巴巴集团控股有限公司 处理方法、装置、设备和机器可读介质
CN111104377B (zh) * 2018-10-26 2023-09-12 伊姆西Ip控股有限责任公司 文件管理的方法、电子设备和计算机可读存储介质
US11144502B2 (en) * 2019-03-08 2021-10-12 Netapp Inc. Object store file system format for representing, storing, and retrieving data in an object store according to a structured format
WO2023208404A1 (en) 2022-04-29 2023-11-02 Petagene Ltd Improvements in and relating to object-based storage

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2461025A1 (en) * 2001-09-26 2003-04-03 Mark Saake Efficient mangement of large files
US7752226B1 (en) * 2002-12-20 2010-07-06 Symantec Operating Corporation Reverse pathname lookup by inode identifier
US7092976B2 (en) * 2003-06-24 2006-08-15 International Business Machines Corporation Parallel high speed backup for a storage area network (SAN) file system
US7693880B1 (en) * 2004-05-06 2010-04-06 Symantec Operating Corporation Mirrored storage at the file system level
US7788303B2 (en) * 2005-10-21 2010-08-31 Isilon Systems, Inc. Systems and methods for distributed system scanning
TWI476610B (zh) * 2008-04-29 2015-03-11 Maxiscale Inc 同級間冗餘檔案伺服器系統及方法
US8478799B2 (en) * 2009-06-26 2013-07-02 Simplivity Corporation Namespace file system accessing an object store
JP5463899B2 (ja) * 2009-12-22 2014-04-09 富士通株式会社 ファイル管理情報記憶装置、ファイル管理情報記憶装置の制御方法、およびファイル管理情報記憶装置の制御プログラム
WO2013061463A1 (ja) * 2011-10-28 2013-05-02 株式会社日立製作所 ストレージシステム、及びオブジェクト管理方法
JP5873187B2 (ja) * 2012-02-13 2016-03-01 株式会社日立製作所 階層化ストレージシステムの管理装置及び管理方法
US9361187B2 (en) * 2013-11-04 2016-06-07 Quantum Corporation File system metadata capture and restore

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None *
See also references of WO2015090668A1 *

Also Published As

Publication number Publication date
JP2016526737A (ja) 2016-09-05
WO2015090668A1 (de) 2015-06-25
JP6430499B2 (ja) 2018-11-28
US20160283501A1 (en) 2016-09-29
DE102013114214A1 (de) 2015-06-18

Similar Documents

Publication Publication Date Title
WO2015090668A1 (de) Posix-kompatibles dateisystem, verfahren zum erzeugen einer dateiliste und speichervorrichtung
DE102013204972B4 (de) Hybride Sicherung und Wiederherstellung eines sehr grossen Dateisystems unter Verwendung von Metadaten-Abbildsicherung und herkömmlicher Sicherung
DE102013215535B4 (de) Sicherung oder wiederherstellung von daten mit hilfe eines hauptspeichers und nichtflüchtiger speichermedien
DE10211606B4 (de) Datenverarbeitungseinrichtung mit einem Metadatensicherungsmanagement
DE602005004166T2 (de) Vorrichtung, system und verfahren zur reinitialisierung einer serialisierung von dateisystemen
DE112017005868T5 (de) Verwaltung von e/a-abläufen für datenobjekte in einem speichersystem
DE3743890C2 (de)
DE602005001041T2 (de) Speicherauszugssystem
DE69333906T2 (de) Verfahren und System für die Dateienverwaltung mit einem schnell löschbaren, programmierbaren ROM
DE60213867T2 (de) Vorrichtung zur verwaltung von datenreplikation
DE60112257T2 (de) Virtuelles Dateisystem für dynamisch erzeugte Webseiten
DE112020000749T5 (de) Indexerstellung für sich entwickelnde umfangreiche Datensätze in Hybriden Transaktions- und Analysenverarbeitungssystemen mit mehreren Mastern
DE60128200T2 (de) Methode und System für skalierbare, hochperformante hierarchische Speicherverwaltung
DE112009004503T5 (de) Optimierung der zugriffszeit von auf speichern gespeicherten dateien
DE202010018481U1 (de) Asynchroner verteilter Objekt-Upload für replizierte Assoziativspeichercluster
DE102009031923A1 (de) Verfahren zum Verwalten von Datenobjekten
DE10393771T5 (de) Schnelle Datensicherungsspeicherung und schnelle Datenwiederherstellung (FBSRD)
DE202009019149U1 (de) Asynchron verteilte Speicherbereinigung für replizierte Speichercluster
DE112005003668T5 (de) HSM-Steuerprogramm, HSM-Steuervorrichtung und HSM-Steuerverfahren
DE112011101793T5 (de) Gemeinsame Datennutzung bei Dateiklonen
DE602004007925T2 (de) Verwalten einer beziehung zwischen einem zielvolumen und einem quellenvolumen
DE112019006530T5 (de) Markieren von betroffenen ähnlichkeitsgruppen in freispeichersammeloperationen in duplizierten speichersystemen
DE102021108455B4 (de) Erzeugen von Snapshots eines Schlüssel-Wert-Index
DE102022108673A1 (de) Ressourcenzuweisung für synthetische backups
DE102021109729A1 (de) Schätzung der nutzung der speichersystemkapazität

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: 20160607

AK Designated contracting states

Kind code of ref document: A1

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

AX Request for extension of the european patent

Extension state: BA ME

RIN1 Information on inventor provided before grant (corrected)

Inventor name: KOENIG, CHRISTOPH

Inventor name: KOENIG, ALEXANDER

DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: FUJITSU LIMITED

17Q First examination report despatched

Effective date: 20190313

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

RIC1 Information provided on ipc code assigned before grant

Ipc: G06F 16/14 20190101ALI20191108BHEP

Ipc: G06F 16/11 20190101ALI20191108BHEP

Ipc: G06F 16/13 20190101AFI20191108BHEP

INTG Intention to grant announced

Effective date: 20191211

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: 20200603