US20120265792A1

US20120265792A1 - Data storage access device

Info

Publication number: US20120265792A1
Application number: US13/394,590
Authority: US
Inventors: Michiel Salters
Original assignee: Individual
Current assignee: Individual
Priority date: 2009-09-07
Filing date: 2010-05-19
Publication date: 2012-10-18
Also published as: EP2475962B1; US20120265437A1; TW201116808A; WO2011026660A1; WO2011026656A1; WO2011027224A1; US20120259478A1; WO2011026994A1; EP2475962A1; US20120226436A1; US8793033B2; EP2476049A1; TW201109956A; US8706403B2; WO2011026654A1; WO2011026664A1; TW201113506A; TW201109705A; WO2011026530A1

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 of FIG. 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 of FIG. 2 connected to a computer;
FIG. 6 is a schematic diagram of a file system interface driver of the data storage device of FIG. 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 of FIG. 1 and root directory, sub-directory and files in a virtual file system interface provided by the file system interface driver of FIG. 6.
Embodiments of the present invention will now be described, by way of example only.
A data storage device 2 that can be accessed by a data storage access system according to a first embodiment is illustrated in FIG. 1. The data storage device 2 may be inserted into an electronic device and used for data storage by the electronic device. In the embodiment of FIG. 1, the data storage device 2 is intended for use in a navigation device 20, 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.
The data storage device 2 is in the form of an SD card comprising a file system 4 (in this case an Ext3-file system) in which can be stored a plurality of data and other files 6. The files include various executable program files, including applications, operating system components and drivers. The files include a file storing a file system interface driver 8, 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 the data storage device 2 itself, as will be described in more detail below.
The navigation device 20 is illustrated in FIG. 2, and provides a processing resource that is operable to execute the file system interface driver 8 when the storage device 2 is installed in the navigation device. The file system interface driver 8 provides a file system interface to enable a host computer to access the data storage device 2 using a different file system to that used by the data storage device 2 itself, as will be described in more detail below. The navigation device 20 can thus operate as a data storage access device enabling access to the storage device 2 by external devices.
The navigation device 20 is located within a housing (not shown). The housing includes a processor 22 connected to an input device 24 and a display screen 26. The input device 24 can include a keyboard device, voice input device, touch panel and/or any other known input device utilised to input information; and the display screen 26 can include any type of display screen such as an LCD display, for example. In one arrangement the input device 24 and display screen 26 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 the display screen 26 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 an output device 28, for example an audible output device (e.g. a loudspeaker or vehicle radio). As output device 28 can produce audible information for a user of the navigation device 20, it should equally be understood that input device 24 can include a microphone and software for receiving input voice commands as well.
In the navigation device 20, processor 22 is operatively connected to and set to receive input information from input device 24 via a connection 30, and operatively connected to at least one of display screen 26 and output device 28, via output connections 32, to output information thereto. Further, the processor 22 is operably coupled to the data storage device 2 via connection 36 and to an internal Flash memory 37 (in this case a MoviNand device) via connection 39. The processor 22 is further adapted to receive/send information from/to input/output (I/O) ports 38 via connection 40, wherein the I/O port 38 is connectible to a further I/O device 42 external to the navigation device 20. The navigation device 20 also comprises a volatile memory (not shown) such as a Random Access Memory (RAM).
FIG. 2 further illustrates an operative connection between the processor 22 and a GPS antenna/receiver 44 via connection 46. The antenna/receiver 44 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 to FIG. 3 of the accompanying drawings, the internal flash memory 37 stores a boot loader program that is executable by the processor 22 in order to load an operating system 50 and application software from the storage device 2 for execution by functional hardware components, which provides an environment in which the application software 52 can run. The operating system 50 serves to control the functional hardware components and resides between the application software 52 and the functional hardware components. It can be seen that the operating system 50 includes the file system interface driver 8. The operating system also includes standard file system drivers for accessing the file system 4 (in this case the Ext3 file system) used by the storage device 2.
The application software 52 provides an operational environment including a GUI that supports core functions of the navigation device 20, for example map viewing, route planning, navigation functions and any other functions associated therewith. In variants of the described embodiment, the operating system 50 and/or the application software 52 are stored on the Flash memory 37. The file system interface driver 8 can also be stored in the Flash memory 37 rather than in the storage device 2 according to some of those variants. In some further embodiments no internal flash memory 37 is included in the device 20, and the boot loader, operating system 50 and application software 52 are all stored on the storage device 2.
Data that is used by the application software, including map data, can be stored on the data storage device 2. The operating system and applications are installed in the volatile memory of the device upon start-up.
In the embodiment of FIGS. 1 and 2, the file system 4 is an Ext3 file system and the processor 22 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 the operating system 50. The Ext3 file system provides journaling capabilities and thus can provide for power-fail safe operation.
As shown in FIG. 4, the Ext3 file system 4 comprises a boot area 70, an inode area 72, and a data area 76. The boot area 70 contains basic information concerning the Ext3 file system, for example cluster and sector sizes, and the size and location of the inode area 72. The inode area 72 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 the data area 76 containing the file data. Each inode is 128 bytes in size, and extended attributes are not used. The data area 76 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.
The navigation device 20 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 the navigation device 20 and stored in the storage device 2. FIG. 5 shows the navigation device 20 connected to a PC 100 via a USB cable 102. The PC 100 includes an application layer 104 that comprises application software, and a known operating system 106 (for example, MS Windows or Mac OS X) that includes a FATNFAT/FAT-32 driver 108 in its kernel. When the navigation device 20 is connected to the personal computer 100, a user can perform functions relating to the navigation device 20 via the functionality provided by the application software 104 running on the personal computer 100.
In the arrangement shown in FIG. 5, the PC 100 does not include any Ext3 file system drivers. Nevertheless, the PC 100 is able to perform operations on files (for example, reading, writing or deleting files) stored using the Ext3 file system 6 on the data storage device 2, via operation of the file system interface driver 8.
In operation, the file system interface driver 8 intercepts read and write requests received from the computer 100, and provides a file system interface to the computer 100. The interface provided to the computer 100 does not directly represent the raw storage device 2 but instead appears as a block-structured storage device containing a FAT file system.
The structure of the file system interface driver 8 is shown in more detail in FIG. 6. The file system interface driver includes an interception module 120 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 file system creation module 122, a mapping module 124, and an output module 126.
The virtual file system creation module 122 is operable to create a virtual file system corresponding to the file system 8 of the storage device 2. The virtual file system is of a different type (for example, VFAT or FAT32) to that of the file system of the storage device 2 (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 the computer 100, the virtual file system creation module 122 generates a file allocation table that allocates files stored on the physical storage to logical storage elements of the second file system
The mapping module 124 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 the file system 8, or vice versa. The output module 126 is operable to receive requests or data from one of the computer or the storage device 2, to modify the requests or data based upon mappings by the mapping module 124 and to output the modified request or data to the other of the computer or storage device 2.
In one mode of operation, when a read request for the boot sector of the storage device 2 (for example a request for sector 0) arrives, the file system interface driver 8 responds with a prepared response comprising a fake FAT boot sector (a fixed 512 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.
The computer 100 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 file system interface driver 8 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 the data storage device 2 the computer 100 would next transmit a read request for the FAT32 root directory to the device 20. When the read request for the FAT32 root directory arrives, the file system interface driver 8 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 the computer 100 attempts to write to sector 0 the interception module 120 will report a write failure, preventing any attempt by the computer 100 to reformat the device. In another mode of operation, if the computer 100 attempts to write to sector 0 in order to reformat the device, the file system interface driver 8 reads a file system identifier included in the request from the computer 100, 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 file system interface driver 8 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 file system interface driver 8 then receives from the computer 100 a request to write to sector 0 for a FAT16 file system, the file system interface driver 8 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 the computer 100 to perform operations on the physical storage via the file system interface driver 8. If the request was received as part of a reformat request then the file system interface driver 8 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 file system interface driver 8 may represent to the computer 100 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 the computer 100 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 the computer 100 may then create a read request a file or directory stored under the virtual FAT file system. The operating system at the computer 100 converts the read request into a FAT file read request, and a FAT file system driver at the computer 100 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 the computer 100 at the file system interface driver 8, the driver 8 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, the driver 8 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 the storage device 2 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. The driver 8 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 file system interface driver 8 as relating to either a file write or a directory modification, and the driver 8 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 file system interface driver 8 until it can be classified, after which the file store is updated accordingly.
If the computer 100 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, the mapping module 124 instead determines which Ext3 storage elements correspond to the modified virtual blocks and the output module 126 writes to those Ext3 storage elements on the physical storage device 2 via the Ext3 file system drivers included in the navigation device 20.
A flowchart illustrating in overview one mode of operation of the file system interface driver 8 is provided in FIG. 7.
In some modes of operation each entry (file, sub-directory, directory) in the file store of the storage device 2 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 the computer 100. For example the device may ensure that the synthetic FAT root directory does not coincide with the root directory on the storage device 2, but instead the mapping module 124 may map the synthetic root directory to another directory or sub-directory stored on the storage device 2.
FIG. 8 illustrates the correspondence between a subdirectory (named Vroot) 140, files 142, 144, 146, 150, 152 and a further sub-directory 148 stored in the file store of the storage device 2 and a corresponding synthetic root directory 160, files 162, 164, 166, 170, 172 and sub-directory 168 created by the file system interface driver 8 and stored as a virtual file system in RAM of the device 20. In this case, the synthetic root directory 160 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 the computer 100 or other external device it is obtained by the file system interface driver 8 from the physical storage device 2 using the Ext3 file system drivers.
In operation the file system interface driver 8 modifies the virtual file system to match modifications to the actual file system. For example, the file system interface driver 8 deletes file or sub-directory entries from the virtual file system in response to the corresponding files or sub-directories being deleted from the storage device 2.
The file system interface driver 8 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 the data storage device 2 via the file system interface driver 8 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 file system interface driver 8 sending a corresponding request via the Ext3 file system drivers. The Ext3 file system metadata stored on the physical storage device 2 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 the computer 100 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 file system interface driver 8 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 file system interface driver 8 is configured to operate such that the virtual file system creation module 122 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. The mapping module 124 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 of FIGS. 1 and 2 the physical storage that stores data under the first file system is included in physical device (the navigation device 20) 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

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 to claim 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 to claim 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 to claim 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 to claim 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 to claim 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 to claim 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 to claim 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 to claim 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 to claim 6, wherein each logical storage element of the second file system comprises a block or a sector.

11. A device according to claim 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 to claim 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 to claim 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 to claim 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 to claim 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 to claim 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 to claim 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)