US20120265792A1 - Data storage access device - Google Patents

Abstract

A data storage access device for providing access by an external device to data stored according to a first file system on physical storage, comprises a file system interface operator (8) for providing a file system interface to the external device, wherein the file system interface represents data stored on the physical storage according to the first file system as being stored according to a second file system.

Description

FIELD OF THE INVENTION
• The present invention relates to a data storage access device, and to methods of performing file system operations on data storage devices. The invention relates, for example, to a data storage access device forming part of a mobile peripheral device (such as a portable navigation device, a mobile phone, a portable games machine, a camera, an MP3 or other portable music player, a video camera or video player) that can be connected to a host computer for the performance of file system operations, for example uploading or downloading of data, by the host computer.
BACKGROUND TO THE INVENTION
• A wide variety of electronic devices now include memory for storage of data. Flash memory devices for instance have become increasingly commonly used either as permanently installed internal data storage devices or as removable data storage devices, for example memory cards.
• Smart mobile peripheral devices (for example, portable navigation devices, mobile phones, portable games machines, cameras, MP3 or other portable music players, video cameras or video players) usually include a memory for storing files. When connecting such smart mobile peripherals with file storage to a computer, the file storage should be accessible to the computer. When disconnected, the file storage should be usable by the device itself, at which point the device is usually running on battery power.
• The most common way to make the file storage of the peripheral device accessible to a computer is to expose the raw storage hosting the file storage of the peripheral device to the computer when the device is connected to the computer. Upon connection of the peripheral device to the computer, the computer accesses the file storage by sending a read request for the boot sector of the storage. If the computer determines that the raw storage is formatted using a file system type that is known to the computer, the computer can than access the file storage of the peripheral device using that file system.
• However, this introduces a trade off in the file storage technology choice, in particular the type of file system used by the peripheral device. A known approach is to use a file allocation table (FAT) file system such as Microsoft VFAT/FAT32 for the file store of the device. Files stored on the device can be accessed in a straightforward manner by a host computer when the underlying storage of the device is exposed to the operating system of the host computer, as such file systems are almost universally used in personal computers. However, the choice of a FAT file system such as a Microsoft VFAT/FAT32 file system may not be optimal for use by the device, particularly if it is a battery powered device as due to lack of journaling features provided by such file systems reading to or writing from such file systems is not power-fail safe. For example, the relationship between file contents and file metadata, as well as the internal consistency of the file system may be damaged by a power failure, in particular if the power failure occurs during a write operation.
• Some electronic devices monitor power levels and ensure a safe shutdown if power is close to being exhausted. However, even in the case of such devices, problems can occur if a removable data storage device is forcibly removed during a read or write operation, or if power failure occurs due to an unforeseen device or component failure.
• Power failure problems can be particularly acute in an automotive environment, as power is often delivered by the vehicle battery to electronic devices associated with the vehicle. Examples of such electronic devices in an automotive environment include navigation devices, for example portable navigation devices (PNDs). The software, or other control system, of such electronic devices may have little or no control over the level of power delivered. For example, during an engine start, power can drop to dangerously low levels especially if the vehicle battery is old. That may cause corruption of data if a non-power fail safe file system, such as FAT, is used.
• More generally, power failure problems can occur if an SD card, or any other removable memory device, is removed from a device or computer, for example a PC, whilst the SD card or memory device is being written to.
• FAT file systems or other PC-compatible power systems may not be the most appropriate for a device, depending on the nature of the device. Many highly optimized file systems exist for peripheral or other electronic devices but they cannot be read or written by a standard PC directly and therefore are often not used despite their greater suitability for operation of the devices
• It is an aim of the present invention to provide an improved, or at least alternative, device and method for accessing stored data.
SUMMARY OF THE INVENTION
• In a first, independent aspect of the invention there is provided a data storage access device for providing access by an external device to data stored according to a first file system on physical storage, the data storage access device comprising: a file system interface operator for providing a file system interface to the external device, wherein the file system interface represents data stored on the physical storage under the first file system as being stored under a second file system.
• Thus, a desired file system for data stored on the physical storage can be used, whilst still maintaining compatibility with a file system used by the external device. For example, a power-safe file system can be used, regardless of whether the external device is configured to use that, or any, power-safe file system.
• Alternatively or additionally, a file system can be used which supports file attributes not generally understood by file systems that might be used on the external device, such as file owners, or access control lists. Furthermore, the operating system of the host computer need not be modified to deal with the subtleties of a file system optimized for use in the data storage device.
• The external device may comprise a desktop or laptop computer, for example a PC or Mac. The file system interface operator may comprise a driver or other executable software, hardware or combination of software and hardware. The file system interface operator may comprise one or more modules. The data may comprise a file, sub-directory, root directory or boot sector.
• The data storage access device may include the physical storage. Alternatively the physical storage may be external to the data storage access device.
• The file system operator may comprise a file system driver for the first file system.
• The data storage access device may further comprise a processing resource, for example a processor. The processing resource may be operable to perform file system operations using the first file system on data stored on the physical storage. The file system interface operator may be stored on the physical storage and may be readable and/or executable from the physical storage by the processing resource.
• The device may further comprise, or being configured to communicate with, a file system operator for accessing data on the physical storage according to the first file system.
• The file system operator may comprise a file system driver. The file system operator may be stored on the physical storage and may be readable and/or executable from the physical storage by the processing resource.
• The first file system may be of a first type and the second file system may be of a second, different type.
• The file system interface operator may be configured to intercept a request according to the second file system from the external device and to perform the request using the first file system.
• The file system interface operator may be configured to respond to the request with a response in a response format of the second file system. For example, the response may comprise metadata of the second file system. The metadata may be indicative that the data is stored under a file system of the second type. The response may exclude any metadata of the first file system.
• The file system interface operator may be configured to assign at least one logical storage element of the second file system to a file stored in the first file system.
• The file system interface operator may be configured to map at least one logical storage element of the second file system to at least one storage element of the first file system.
• The file system operator may be configured to generate a file allocation table that allocates files stored on the physical storage to logical storage elements of the second file system.
• The request may comprise a request to perform an operation on at least one logical storage element of the second file system, for example a request to read or write at least one logical storage element of the second file system.
• The file system interface operator may be configured to translate the request into a request according to the first file system.
• The file system interface operator may be configured to translate the request into a request to perform an operation on at least one logical or physical storage element of the first file system, for example a request to read or write at least one logical storage element of the first file system.
• The file system operator may be configured to translate the request into a request to perform a file operation according to the first file system, and then to translate the request to perform a file operation into a request to perform an operation on a logical or physical storage element of the first file system. The file operation may comprise at least one of a read request; a write request; an open file, sub-directory or directory request; a close file, sub-directory or directory request; a move file, sub-directory or directory request; a save request, or a rename request.
• The file system interface operator may be configured to respond to a read request by the external device by providing a response that comprises as at least one logical storage element of the second file system.
• The file system interface operator may be configured to receive a write request to write to at least one logical storage element of the second file system, to determine at least one storage element of the first file system corresponding to the at least one logical storage element of the second file system, and to write the data to the at least one storage element of the first file system.
• The or each logical storage element of the second file system may comprise a block or sector. The storage element of the first file system may comprise a block, sector or cluster.
• The file system interface operator may be configured to respond to a read request for the boot sector of the physical storage with a response that indicates that the physical storage is formatted according to a file system of the second type.
• The file system interface may comprise representations of files, directories and/or sub-directories in the second file system that correspond to files, directories and/or sub-directories stored in the physical storage under the first file system.
• The file system interface operator may be configured to update the file system interface in response to changes to files, directories or sub-directories stored in the physical storage under the first file system so that the file system interface represents the changes as occurring under the second file system.
• The file system interface operator may represent the changes as occurring under the second file system by modifying metadata of the second file system.
• The metadata of the second file system may comprise at least one of: filename; file size; directory or sub-directory name; directory or sub-directory size; file, sub-directory or directory history data; read time; and write time.
• The file system interface may be configured to represent at least some of the data stored on the physical storage under the first file system as being stored under the second file system, and to represent at least some of the data stored on the physical storage under the first file system as being stored under at least one further file system. The file system of the first type may comprise an Ext-type file system. The Ext file system may comprise an Ext3 file system or a successor to the Ext3 file system.
• The file system of the second type may comprise a FAT-based file system or NTFS file system. The FAT-based file system may comprise one of a FAT, vFAT, FAT16, or FAT32 file system.
• The physical storage may comprise NAND flash storage, and the first file system may comprise a log-structured file system, for example JFFS2. In a further independent aspect of the invention there is provided a method of accessing data stored under a first file system on a data storage device comprising providing a file system interface that represents data stored on the data storage device under the first file system as being stored under a second file system,
• The first file system may be a file system of a first type and the second file system may be a file system of a second, different type.
• The method may comprise intercepting a request according to the second file system and performing the request using the first file system.
• The method may comprise responding to the request with a response in a response format of the second file system.
• The request may comprise a request to perform an operation on at least one logical storage element of the second file system, for example a request to read or write at least one logical storage element of the second file system.
• The method may comprise translating the request into a request according to the first file system.
• The method may comprise translating the request into a request to perform an operation on at least one logical or physical storage element of the first file system, for example a request to read or write at least one logical or physical storage element of the first file system. The method may comprise responding to a read request by providing a response that comprises as at least one logical storage element of the second file system.
• The method may comprise receiving a write request to write to at least one logical storage element of the second file system, to determine at least one storage element of the first file system corresponding to the at least one logical storage element of the second file system, and to write the data to the at least one storage element of the first file system.
• The method may comprise responding to a read request for the boot sector of the physical storage with a response that indicates that the physical storage is formatted using a file system of the second type.
• The method may comprise representing files, directories and/or sub-directories stored in the physical storage under the first file system as files, directories and/or sub-directories in the second file system.
• The method may comprise updating the file system interface in response to changes to files, directories or sub-directories stored in the physical storage under the first file system so that the file system interface represents the changes as occurring under the second file system.
• The method may comprise representing at least some of the data stored under the first file system as being stored under the second file system, and to represent at least some of the data stored under the first file system as being stored under at least one further file system. The method may comprise representing the changes as occurring under the second file system by modifying metadata of the second file system.
• In a further independent aspect of the invention there is provided a computer program product comprising computer readable instructions that are executable to perform a method as claimed or described herein.
• The computer readable instructions may be executable by the processor of an electronic device, for example a mobile peripheral device such as a portable navigation device, a mobile phone, a portable games machine, a camera, an MP3 or other portable music player, a video camera or video player.
• There may also be provided an apparatus or method substantially as described herein with reference to the accompanying drawings.
• Any feature in one aspect of the invention may be applied to other aspects of the invention, in any appropriate combination. For example, device features may be applied to method features and vice versa.
DETAILED DESCRIPTION OF EMBODIMENTS
• Embodiments of the invention are now described, by way of non-limiting example, and are illustrated in the following figures, in which:
• FIG. 1 is a schematic diagram of a data storage device according to one embodiment;
• FIG. 2 is a schematic diagram of a navigation device;
• FIG. 3 is schematic representation of an architectural stack of the navigation device ofFIG. 2;
• FIG. 4 is a schematic representation of the data structure of a file system of the data storage device;
• FIG. 5 is a schematic diagram showing the navigation device ofFIG. 2 connected to a computer;
• FIG. 6 is a schematic diagram of a file system interface driver of the data storage device ofFIG. 1;
• FIG. 7 is a flowchart illustrating in overview a read operation and subsequent write operation; and
• FIG. 8 is a schematic diagram showing the correspondence between a root directory, sub-directory and files of a file store of the data storage device ofFIG. 1 and root directory, sub-directory and files in a virtual file system interface provided by the file system interface driver ofFIG. 6.
• Embodiments of the present invention will now be described, by way of example only.
• Adata storage device2 that can be accessed by a data storage access system according to a first embodiment is illustrated inFIG. 1. Thedata storage device2 may be inserted into an electronic device and used for data storage by the electronic device. In the embodiment ofFIG. 1, thedata storage device2 is intended for use in anavigation device20, but it can be used in any suitable electronic device, for example a mobile phone, a portable games machine, a camera, an MP3 or other portable music player, a video camera or video player.
• Thedata storage device2 is in the form of an SD card comprising a file system4 (in this case an Ext3-file system) in which can be stored a plurality of data andother files6. The files include various executable program files, including applications, operating system components and drivers. The files include a file storing a filesystem interface driver8, which is executable to provide a file system interface to enable a host computer to access the data storage device using a different file system to that used by thedata storage device2 itself, as will be described in more detail below.
• Thenavigation device20 is illustrated inFIG. 2, and provides a processing resource that is operable to execute the filesystem interface driver8 when thestorage device2 is installed in the navigation device. The filesystem interface driver8 provides a file system interface to enable a host computer to access thedata storage device2 using a different file system to that used by thedata storage device2 itself, as will be described in more detail below. Thenavigation device20 can thus operate as a data storage access device enabling access to thestorage device2 by external devices.
• Thenavigation device20 is located within a housing (not shown). The housing includes aprocessor22 connected to aninput device24 and adisplay screen26. Theinput device24 can include a keyboard device, voice input device, touch panel and/or any other known input device utilised to input information; and thedisplay screen26 can include any type of display screen such as an LCD display, for example. In one arrangement theinput device24 anddisplay screen26 are integrated into an integrated input and display device, including a touchpad or touchscreen input so that a user need only touch a portion of thedisplay screen26 to select one of a plurality of display choices or to activate one of a plurality of virtual buttons.
• The navigation device may include or be connected to anoutput device28, for example an audible output device (e.g. a loudspeaker or vehicle radio). Asoutput device28 can produce audible information for a user of thenavigation device20, it should equally be understood thatinput device24 can include a microphone and software for receiving input voice commands as well.
• In thenavigation device20,processor22 is operatively connected to and set to receive input information frominput device24 via aconnection30, and operatively connected to at least one ofdisplay screen26 andoutput device28, viaoutput connections32, to output information thereto. Further, theprocessor22 is operably coupled to thedata storage device2 viaconnection36 and to an internal Flash memory37 (in this case a MoviNand device) viaconnection39. Theprocessor22 is further adapted to receive/send information from/to input/output (I/O)ports38 viaconnection40, wherein the I/O port38 is connectible to a further I/O device42 external to thenavigation device20. Thenavigation device20 also comprises a volatile memory (not shown) such as a Random Access Memory (RAM).
• FIG. 2 further illustrates an operative connection between theprocessor22 and a GPS antenna/receiver44 viaconnection46. The antenna/receiver44 are combined schematically for illustration purposes but may be separately positioned components. The antenna can be, for example, a GPS patch antenna or helical antenna.
• Referring now toFIG. 3 of the accompanying drawings, theinternal flash memory37 stores a boot loader program that is executable by theprocessor22 in order to load anoperating system50 and application software from thestorage device2 for execution by functional hardware components, which provides an environment in which theapplication software52 can run. Theoperating system50 serves to control the functional hardware components and resides between theapplication software52 and the functional hardware components. It can be seen that theoperating system50 includes the filesystem interface driver8. The operating system also includes standard file system drivers for accessing the file system4 (in this case the Ext3 file system) used by thestorage device2.
• Theapplication software52 provides an operational environment including a GUI that supports core functions of thenavigation device20, for example map viewing, route planning, navigation functions and any other functions associated therewith. In variants of the described embodiment, theoperating system50 and/or theapplication software52 are stored on theFlash memory37. The filesystem interface driver8 can also be stored in theFlash memory37 rather than in thestorage device2 according to some of those variants. In some further embodiments nointernal flash memory37 is included in thedevice20, and the boot loader,operating system50 andapplication software52 are all stored on thestorage device2.
• Data that is used by the application software, including map data, can be stored on thedata storage device2. The operating system and applications are installed in the volatile memory of the device upon start-up.
• In the embodiment ofFIGS. 1 and 2, the file system4 is an Ext3 file system and theprocessor22 of the navigation device is able to perform read, write and other standard operations on files stored in the data storage device by using known Ext3 file system drivers included in theoperating system50. The Ext3 file system provides journaling capabilities and thus can provide for power-fail safe operation.
• As shown inFIG. 4, the Ext3 file system4 comprises aboot area70, aninode area72, and adata area76. Theboot area70 contains basic information concerning the Ext3 file system, for example cluster and sector sizes, and the size and location of theinode area72. Theinode area72 contains metadata in the form of inodes representative of properties of the files stored in the Ext3 file system, for example, file type, file size, one or more attributes (for example whether a file is read-only, or access privileges), and time stamps representative of time of creation and/or modification, if required, as well as the identity and location of the clusters in thedata area76 containing the file data. Each inode is 128 bytes in size, and extended attributes are not used. Thedata area76 contain the file data, and also contains directory data (comprising at least root directory data) and journal entries that are used to journal data and/or metadata during the writing of data and metadata by the file system.
• Thenavigation device20 can be connected to a PC or other computer to enable data (for example log data concerning use of the navigation device) to be transferred to the computer, or to enable data (for example software upgrades, or map or other data) to be transferred from the computer to thenavigation device20 and stored in thestorage device2.FIG. 5 shows thenavigation device20 connected to aPC100 via aUSB cable102. ThePC100 includes anapplication layer104 that comprises application software, and a known operating system106 (for example, MS Windows or Mac OS X) that includes a FATNFAT/FAT-32 driver108 in its kernel. When thenavigation device20 is connected to thepersonal computer100, a user can perform functions relating to thenavigation device20 via the functionality provided by theapplication software104 running on thepersonal computer100.
• In the arrangement shown inFIG. 5, thePC100 does not include any Ext3 file system drivers. Nevertheless, thePC100 is able to perform operations on files (for example, reading, writing or deleting files) stored using theExt3 file system6 on thedata storage device2, via operation of the filesystem interface driver8.
• In operation, the filesystem interface driver8 intercepts read and write requests received from thecomputer100, and provides a file system interface to thecomputer100. The interface provided to thecomputer100 does not directly represent theraw storage device2 but instead appears as a block-structured storage device containing a FAT file system.
• The structure of the filesystem interface driver8 is shown in more detail inFIG. 6. The file system interface driver includes aninterception module120 that is operable to intercept read requests and other file system requests from a computer or other external apparatus. The file system interface driver also includes a virtual filesystem creation module122, amapping module124, and anoutput module126.
• The virtual filesystem creation module122 is operable to create a virtual file system corresponding to thefile system8 of thestorage device2. The virtual file system is of a different type (for example, VFAT or FAT32) to that of the file system of the storage device2 (for example Ext3). The choice of which type of file system to use as the virtual file system in a particular embodiment can depend on the particular application for which the embodiment is to be used, and on the size or content of the stored files. For example, FAT16 is supported more widely than FAT32, but FAT32 can hold more than 2 GB of data, and in that case a choice between FAT16 and FAT32 may depend on the size of the Ext3 or other type of file system of the physical storage.
• In embodiments in which the device presents a FAT file system interface to thecomputer100, the virtual filesystem creation module122 generates a file allocation table that allocates files stored on the physical storage to logical storage elements of the second file system
• Themapping module124 is operable to map files, directories, sub-directories and file system logical elements (for example sectors or blocks) of the virtual file system to files, directories, sub-directories and file system logical or physical storage elements (for example sectors, blocks or clusters) of thefile system8, or vice versa. Theoutput module126 is operable to receive requests or data from one of the computer or thestorage device2, to modify the requests or data based upon mappings by themapping module124 and to output the modified request or data to the other of the computer orstorage device2.
• In one mode of operation, when a read request for the boot sector of the storage device2 (for example a request for sector0) arrives, the filesystem interface driver8 responds with a prepared response comprising a fake FAT boot sector (a fixed512 byte data structure) that indicates that the storage device is formatted using a file system used by the computer, in this case FAT32. The response from the file system interface driver in this example includes the string “FAT32” at offset 0×52 and the bytes 0×55 0×AA at offsets 0×1 FE.
• Thecomputer100 receives and processes the response and determines that the storage device is using a FAT32 file system (although the storage device is in fact using an Ext3 file system). In this example, if the filesystem interface driver8 were not present then the response returned to the external device to the boot sector request would indicate, correctly, that the storage device was using an Ext3 file system. In that case the external device, in this case a PC would give up as it does not include Ext3 file system drivers.
• In normal operation, in order to access data stored on thedata storage device2 thecomputer100 would next transmit a read request for the FAT32 root directory to thedevice20. When the read request for the FAT32 root directory arrives, the filesystem interface driver8 intercepts it, and then retrieves the root directory of the actual file storage (which in this case uses Ext3 rather than VFAT/FAT32) and creates a synthetic VFAT/FAT32 root directory in memory (for example in the navigation device RAM). Each entry in this VFAT/FAT32 directory corresponds to an entry in the “exposed root” directory of the file storage. As VFAT supports both “long” and “short” names for a single file, there might be two VFAT entries for a single physical file.
• In one mode of operation, if thecomputer100 attempts to write to sector0 theinterception module120 will report a write failure, preventing any attempt by thecomputer100 to reformat the device. In another mode of operation, if thecomputer100 attempts to write to sector0 in order to reformat the device, the filesystem interface driver8 reads a file system identifier included in the request from thecomputer100, reformats the device and then provides to the computer a file system interface comprising a file system of the type determined from the file system identifier included in the reformat request.
• For example, the physical storage device may include an Ext3 file system and the filesystem interface driver8 may by default provide a file system interface representing the data on the physical storage as being stored under a FAT32 file system. If the filesystem interface driver8 then receives from the computer100 a request to write to sector0 for a FAT16 file system, the filesystem interface driver8 in one mode of operation alters the file system interface in response so that it subsequently represents data stored on the physical storage as being stored under the FAT16 file system, thus enabling thecomputer100 to perform operations on the physical storage via the filesystem interface driver8. If the request was received as part of a reformat request then the filesystem interface driver8 may also remove all existing files and directories from the physical storage, for example by writing new file system data representative of an empty disk. Alternatively, the filesystem interface driver8 may represent to thecomputer100 under the virtual file system that all existing files and directories had been overwritten whilst retaining them on the physical storage.
• The entries (for example files and sub-directories) in the root directory include unique virtual block numbers that thecomputer100 interprets as representing the location of the data blocks corresponding to the files and sub-directories in accordance with usual FAT32 file system.
• In fact, the virtual block numbers do not relate to actual physical storage locations but are used in future requests.
• An application at thecomputer100 may then create a read request a file or directory stored under the virtual FAT file system. The operating system at thecomputer100 converts the read request into a FAT file read request, and a FAT file system driver at thecomputer100 translates the request into one or more FAT sector read requests. The one or more sector read requests include identifiers identifying the FAT block in which the sector(s)s are located.
• When the read request arrives from thecomputer100 at the filesystem interface driver8, thedriver8 translates the request back into a FAT file read request and checks whether the block number included in the request corresponds to a directory or file entry in the virtual file system. If it is a file entry, thedriver8 maps the block number to the original filename, translates the FAT file read request into a read request according to the Ext3 file system, in this embodiment, and returns the corresponding bytes of data from the file in the file store of thestorage device2 using the Ext3 file system drivers to access the data.
• If the block number refers to a subdirectory, a synthetic subdirectory is created in the virtual file system. This process is similar to the creation of a synthetic root directory except that the entries are taken from the corresponding subdirectory on the file store rather than from the root directory on the file store. Thedriver8 reads the corresponding sub-directory from Ext3 file system and reformats/translates the contained sub-directory entries to correspond to the FAT format, for example it removes or replaces Ext3-specific information. An example of information that is removed is an identifier identifying the file owner or creator (Ext3 stores such an identifier in the file's directory entry, FAT doesn't store it at all).
• A similar process is followed to perform write operations. A write operation is interpreted by the filesystem interface driver8 as relating to either a file write or a directory modification, and thedriver8 then passes corresponding instructions to the Ext3 file system driver. It some cases due to write reordering a physical write cannot be classified immediately as either a file write or a directory modification. In that case the data written is held in reserve by the filesystem interface driver8 until it can be classified, after which the file store is updated accordingly.
• If thecomputer100 wishes to modify a retrieved file it can return the modified data as modified blocks, in accordance with normal FAT32 techniques. However, instead of writing the modified blocks to physical storage using normal FAT32 techniques, themapping module124 instead determines which Ext3 storage elements correspond to the modified virtual blocks and theoutput module126 writes to those Ext3 storage elements on thephysical storage device2 via the Ext3 file system drivers included in thenavigation device20.
• A flowchart illustrating in overview one mode of operation of the filesystem interface driver8 is provided inFIG. 7.
• In some modes of operation each entry (file, sub-directory, directory) in the file store of thestorage device2 has a corresponding entry in the virtual file system.
• In other modes of operation, the device may expose only part of its file store to thecomputer100. For example the device may ensure that the synthetic FAT root directory does not coincide with the root directory on thestorage device2, but instead themapping module124 may map the synthetic root directory to another directory or sub-directory stored on thestorage device2.
• FIG. 8 illustrates the correspondence between a subdirectory (named Vroot)140,files142,144,146,150,152 and afurther sub-directory148 stored in the file store of thestorage device2 and a correspondingsynthetic root directory160,files162,164,166,170,172 andsub-directory168 created by the filesystem interface driver8 and stored as a virtual file system in RAM of thedevice20. In this case, thesynthetic root directory160 maps to the Vroot sub-directory of the Ext3 file system rather than to the actual Ext3 root directory. File content for the synthetic files is not stored in the RAM. Instead, as described above, if the content of such synthetic files is requested by thecomputer100 or other external device it is obtained by the filesystem interface driver8 from thephysical storage device2 using the Ext3 file system drivers.
• In operation the filesystem interface driver8 modifies the virtual file system to match modifications to the actual file system. For example, the filesystem interface driver8 deletes file or sub-directory entries from the virtual file system in response to the corresponding files or sub-directories being deleted from thestorage device2.
• The filesystem interface driver8 maintains and stores in RAM metadata (for example, filename, file location, file size, directory name, directory location, directory size, file or directory history data, read time, and write time) for the virtual file system, and represents changes by modifying the metadata of the virtual file system. Any operations performed by the computer on the data stored in thedata storage device2 via the filesystem interface driver8 can be represented by modifications to the virtual file system metadata stored in the RAM. For example, if the computer or other external device requests that a file be moved from one sub-directory to another sub-directory, that operation is performed by the filesystem interface driver8 sending a corresponding request via the Ext3 file system drivers. The Ext3 file system metadata stored on thephysical storage device2 is modified to reflect the change in location of the file in the Ext3 file system. In addition, the virtual file system metadata (in this case FAT32 metadata) stored in RAM and available to thecomputer100 or other external device is also modified to reflect the change.
• In alternative embodiments the metadata mentioned in the preceding paragraph is stored or other volatile memory instead of RAM, or is stored in non-volatile memory, or is regenerated whenever it is needed.
• In alternative embodiments the file system interface driver is configured to provide an interface between other types of file system, for example between any combination of: NTFS, any type of FAT file system (for example FAT12, FAT16, FAT32), UDF, Ext2, Ext3, Ext4, Btrfs, or JFFS2. For example, in certain embodiments, on the computer side the file system is one of CDFS (usually used by CDs), UDF (usually used by DVDs), NTFS, or any type of FAT file system, and on the device side the file system is one of Ext3, Ext4, Btrfs, JFFS2 or any other log-structured file system.
• In one embodiment the physical storage of the device is NAND flash memory. A JFFS2 file system is used on the NAND flash memory. JFFS2 file systems or other log-structured file systems are often used for NAND flash memory devices as such devices only allow large (for example 128 KB) blocks of data to be erased, and as some blocks of memory are unusable after production and others fail over time. The use of a log-structured file system protects the integrity of the stored data in the event of such failures. In the embodiment, a filesystem interface driver8 maps the JFFS2 file system to a virtual FAT-based interface, thus enabling a PC or other external device to access data stored on the flash memory without requiring the PC or other external device to include JFFS2 drivers.
• In other embodiments the filesystem interface driver8 is configured to operate such that the virtual filesystem creation module122 creates two or more different virtual file system of different types (for example one FAT16 file system and one FAT32 file system) to represent the file system of the device. Themapping module124 is configured to map different files, sub-directories, root directory, and sectors or blocks of the device to one or other of the different virtual file systems.
• In the embodiment ofFIGS. 1 and 2 the physical storage that stores data under the first file system is included in physical device (the navigation device20) that provides the file system interface driver that enables access to the data using an file system interface comprising a virtual file system. In other embodiments the physical storage is separate from the device that includes the file system interface driver or other file system interface operator. For example, in one such embodiment a processing resource operable to provide the file system interface driver or other file system interface operator for providing the file system interface is included in an SD card reader that can accept EXT-formatted SD cards and create a virtual FAT file system enabling access to data on the SD cards by a PC or other device using a FAT file system.
• In another embodiment, a processing resource operable to provide the file system interface driver or other file system interface operator for providing the file system interface is included in an adapter box that can be connected on one side to a USB disk (formatted under Ext3, for example) and on the other side to a PC. The adapter box would be operable to represent the USB disk as a FAT-formatted disk, or as being formatted according to any other desired format.
• Embodiments, or features of such, can be implemented as a computer program product for use with a computer system, the computer program product being, for example, a series of computer instructions stored on a tangible data recording medium, such as a diskette, CD-ROM, ROM, or fixed disk, or embodied in a computer data signal, the signal being transmitted over a tangible medium or a wireless medium, for example, microwave or infrared. The series of computer instructions can constitute all or part of the functionality described above, and can also be stored in any memory device, volatile or non-volatile, such as semiconductor, magnetic, optical or other memory device.
• It will also be well understood by persons of ordinary skill in the art that whilst embodiments implement certain functionality by means of software, that functionality could be implemented solely in hardware (for example by means of one or more ASICs (application specific integrated circuit)) or by a mix of hardware and software. As such, embodiments are not limited only to being implemented in software.
• It will be understood that the present invention has been described above purely by way of example, and modifications of detail can be made within the scope of the invention.
• Each feature disclosed in the description, and (where appropriate) the claims and drawings may be provided independently or in any appropriate combination.

Claims (18)

1. A navigation device for providing access by an external device to data stored according to a first file system on physical storage, comprising:

a file system interface operator for providing a file system interface to the external device, wherein the file system interface represents data stored on the physical storage according to the first file system as being stored according to a second file system, wherein the first file system is a power-safe file system.

2. A device according toclaim 1, further comprising:

being configured to communicate with, a file system operator for accessing data on the physical storage according to the first file system.

3. A device according toclaim 1, wherein the first file system is of a first type and the second file system is of a second, different type.

4. A device according toclaim 1, wherein the file system interface operator is configured to intercept a request according to the second file system from the external device and to perform the request using the first file system.

5. A device according toclaim 4, wherein the file system interface operator is configured to respond to the request with a response in a response format of the second file system.

6. A device according toclaim 4, wherein the request comprises a request to perform an operation on at least one logical storage element of the second file system, for example a request to read or write at least one logical storage element of the second file system.

7. A device according toclaim 6, wherein the file system interface operator is configured to translate the request into a request according to the first file system.

8. A device according toclaim 7, wherein the file system interface operator is configured to translate the request into a request to perform an operation on at least one logical or physical storage element of the first file system, for example a request to read or write at least one logical storage element of the first file system.

9. A device according toclaim 4, wherein the file system interface operator is configured to respond to a read request by the external device by providing a response that comprises at least one logical storage element of the second file system.

10. A device according toclaim 6, wherein each logical storage element of the second file system comprises a block or a sector.

11. A device according toclaim 1, wherein the file system interface operator is configured to respond to a read request for the boot sector of the physical storage with a response that indicates that the physical storage is formatted according to a file system of the second type.

12. A device according toclaim 1, wherein the file system interface comprises representations of files, directories and/or sub-directories in the second file system that correspond to files, directories and/or sub-directories stored in the physical storage under the first file system.

13. A device according toclaim 1, wherein the file system interface operator is configured to update the file system interface in response to changes to files, directories or sub-directories stored in the physical storage under the first file system so that the file system interface represents the changes as occurring under the second file system.

14. A device according toclaim 13, wherein the file system interface operator represents the changes as occurring under the second file system by modifying metadata of the second file system.

15. A device according toclaim 1, wherein the file system interface is configured to represent at least some of the data stored on the physical storage under the first file system as being stored under the second file system, and to represent at least some of the data stored on the physical storage under the first file system as being stored under at least one further file system.

16. A device according toclaim 1, wherein the first file system comprises an Ext-type file system, and/or the second file system comprises a FAT-based file system or NTFS file system.

17. A device according toclaim 1, wherein the physical storage comprises NAND flash storage, and the first file system comprises a log-structured file system, for example JFFS2.

18-19. (canceled)

Images