US20100115006A1 - Computing device with relatively limited storage space and operating/file system thereof - Google Patents
Computing device with relatively limited storage space and operating/file system thereof Download PDFInfo
- Publication number
- US20100115006A1 US20100115006A1 US12/685,251 US68525110A US2010115006A1 US 20100115006 A1 US20100115006 A1 US 20100115006A1 US 68525110 A US68525110 A US 68525110A US 2010115006 A1 US2010115006 A1 US 2010115006A1
- Authority
- US
- United States
- Prior art keywords
- file
- storage device
- executable file
- virtual
- computing device
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0638—Organizing or formatting or addressing of data
- G06F3/0643—Management of files
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
- G06F3/0604—Improving or facilitating administration, e.g. storage management
- G06F3/0607—Improving or facilitating administration, e.g. storage management by facilitating the process of upgrading existing storage systems, e.g. for improving compatibility between host and storage device
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
- G06F3/0608—Saving storage space on storage systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
- G06F3/0671—In-line storage system
- G06F3/0673—Single storage device
- G06F3/0674—Disk device
Definitions
- the present invention relates to computing devices in general, but especially to a computing device with a relatively limited storage space, such as for example a portable computing device with a relatively small hard disk or a random access memory (RAM) upon which is stored an operating system for such device. More particularly, the present invention relates to such a computing device and the operating/file system thereof, and especially with regard to performing file system operations in a relatively safe and efficient manner.
- a computing device with a relatively limited storage space such as for example a portable computing device with a relatively small hard disk or a random access memory (RAM) upon which is stored an operating system for such device.
- RAM random access memory
- the present invention in which a method is provided for updating an application residing on a storage device of a computing device.
- the update is simulated by performing all necessary actions except for actually committing data relating to the update to the storage device, and it is determined whether the simulated update succeeded. If so, the update is performed by performing the same necessary actions and also actually committing the data relating to the update to the storage device.
- FIG. 7 is block diagram showing a file stored on the storage device of FIG. 2 and executable in place in accordance with one embodiment of the present invention.
- step 311 the installer at some point will have determined that all operations have been performed.
- step one has concluded with the update being successfully simulated. Accordingly, such update may now in fact be performed as at step two.
- the file system 16 now must note the address of the sector 22 , the address of the starting chunk 26 of the first fragment within the sector 22 , the length of the first fragment in chunks 26 , the address of the starting chunk 26 of the second fragment within the sector 22 , and the length of the second fragment in chunks 26 .
- the file 28 may come to reside on multiple sectors 22 and in multiple chunks 26 on each sector, and correspondingly the locating information for locating all the fragments of the file 28 likewise becomes much larger.
- a relatively large file 28 exists on the storage device 12 , but in fact such file 28 is for the most part null data, either in a single contiguous portion or as a plurality of contiguous or non-contiguous portions.
- the segment allocation table 38 may be constructed from such portions based on such references in a manner that should be apparent to the relevant public and therefore need not be set forth herein in any detail.
- the segment allocation table 38 includes ordered references to locations of the actual file data 40 that constitutes the file 28 .
- such references may be to fixed- or variable-length segments of the actual file data 40 .
- the fixed length may for example be the aforementioned minimum-sized block 30
- each reference should include a length attribute.
- employing fixed-length segments obviates the need for such length attributes.
- a file 28 may be executed in place on the storage device 12 of the computing device 10 , even if non-contiguous. To do so, the file 28 must not be compressed and must be stored with correct virtual addresses based on a predefined virtual start address, the storage device 12 must be accessible by the file system 16 by way of an access driver 44 , and a virtual address translator 46 must be able to directly access the storage device 12 based on translations of virtual addresses to physical addresses.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Human Computer Interaction (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
A computing device includes a storage device and a file system for storing and retrieving files on the storage device. The storage device includes storage space divided into sectors and the file system externally addresses the storage device on a per-sector basis, but internally divides each sector of the storage device into chunks and manages data within each sector on a per-chunk basis. Thus, the file system reads a chunk from or writes a chunk to the storage device by reading or writing the sector having the chunk.
Description
- The present application is a continuation of U.S. application Ser. No. 11/000,693, filed on Dec. 1, 2004, which claims the benefit of U.S. Provisional Applications Nos. 60/555,104, 60/555,392, 60/555,155, and 60/555,102, each filed on Mar. 22, 2004.
- The present invention relates to computing devices in general, but especially to a computing device with a relatively limited storage space, such as for example a portable computing device with a relatively small hard disk or a random access memory (RAM) upon which is stored an operating system for such device. More particularly, the present invention relates to such a computing device and the operating/file system thereof, and especially with regard to performing file system operations in a relatively safe and efficient manner.
- In many typical computing devices such as a personal computer, a game computer, a home video recording computer, and the like, the computing device includes a relatively large storage device upon which may be stored data relating the computing device, including of course applications that can be executed thereon and an operating system and/or file system (hereinafter ‘file system’) that is executed thereon to operate same and to allow access to the storage device. Inasmuch as the storage device is relatively large, the amount of space used by applications and the file system thereon is relatively insignificant, and accordingly issues of file maintenance, system upgrading, file access, file storage, and the like are not especially severe.
- However, when the computing device does not include such relatively large storage device, but instead includes a relatively small storage device, the amount of space used by applications and the file system thereon can become relatively significant, and the aforementioned issues can and do become more severe. For example, when the computing device is a portable computing device or the like, such as for example a portable audio or video player or a portable game computer, and is of a relatively small size, it is likely that such computing device includes a relatively small storage device, especially inasmuch as the computing device is likely limited in the functionality required, in what applications can be executed thereon, and the physical size of storage device that can be accommodated. As should be appreciated, inasmuch as the storage device is relatively small, the amount of space used by the file system thereon is relatively significant, and accordingly issues of file maintenance, system upgrading, file access, file storage, and the like now require careful consideration.
- One issue that must be considered is how an application or the file system on the relatively small storage device is to be updated. In particular, in a relatively large storage device, such updating may be achieved by successfully writing update data to an unused part of the storage device and thereafter deleting corresponding old data from another part of the storage device. However, in a relatively small storage device, space thereon may not be available to write the update data prior to deleting the old data, and accordingly the old data must be deleted in order to free space prior to writing the update data.
- Critically, though, if the updating of the application or file system somehow fails and the old data thereof has already been deleted, there may be no way to restore the computing device to the previous state where the non-updated application or file system could be executed on the computing device. In the case of an application, such failure may be an annoyance until the application is reloaded, if possible. However, in the case of a file system, such failure may be catastrophic inasmuch as the computing device may be inoperable without a functioning file system. Accordingly, a need exists for a method for updating an application or file system on a computing device with a relatively small storage device, where the method ensures that the update will succeed or else does not allow the update to be performed.
- Another issue that must be considered is how to store files on a relatively small storage device. In particular, in a relatively large storage device, storing files is performed on a per-cluster basis, with each file using at least one cluster which can be defined as 1, 2, 4, 8, or 16 kilobytes or more. Thus, if a file with only a small amount of data (one byte, for example) is assigned to a particular cluster, all the remaining space in such cluster will go unused by any other file and is thus wasted. Such wasted space is not especially significant in a relatively large storage device, especially one with a capacity on the order of tens or hundreds of gigabytes.
- However, in a relatively small storage device, such wasted space can quickly grow to a significant level, and even to the point where the storage device runs out of space. For example, a storage device with a 16 megabyte capacity and a cluster defined as 16 kilobytes can only hold about 1000 files, even if each file is only a few bytes. Moreover, it can often be the case that the relatively small storage device such as that which was set forth above does indeed have stored thereon a significant number of very small files, on the order of a few to a few hundred bytes. Accordingly, a need exists for a file system framework that efficiently uses the storage capacity of a relatively small storage device without undue wasted space.
- Still another issue that is to be considered is how to store a file on a relatively small storage device when the file contains portions of unallocated or null data. As may be appreciated, such unallocated or null data within a file is data for which space exists within the file, but where such data has not been established. For example, in a particular 128 kilobyte file, it may be the case that a middle portion thereof constitutes 32 kilobytes of null data which acts as a placeholder but is to be filled in at a later time with some type of information. Thus, such null data may be represented as all zeroes or the like, and again may be filled in at some later time with substantive information.
- In particular, in a relatively large storage device, the entirety of such a file including such null data is stored, even though such null data represents nothing. As may be appreciated, such ‘stored’ null data is wasted space on the relatively large storage device that could instead be put to better use. However, and again, such wasted space is not especially significant in a relatively large storage device, especially one with a capacity on the order of tens or hundreds of gigabytes.
- However, and again, in a relatively small storage device, such wasted space can quickly grow to a significant level, and even to the point where the storage device runs out of space. Moreover, it is to be appreciated that such wasted space can interfere when attempting to build a new file on such relatively small storage device based on an old file thereon, especially when the device is almost full. Accordingly, a need exists for a structure of a file that allows for efficient use of storage capacity of a relatively small storage device, especially when the file includes null data therein.
- Yet another issue that is to be considered is how to execute a file on a relatively small storage device. In particular, in a computing device that would have such a relatively small storage device, such as for example a mobile telephone, a position locator, a music player, etc., a user likely wishes that a requested action be taken almost immediately. Put another way, if the requested action requires that an executable file be executed, such a user does not want to wait for however many seconds it could take for the file to be loaded from the storage device to a local RAM or the like and readied for execution. Moreover, in certain circumstances, the nature of the action may even demand almost immediate execution, such as for example if the computing device is a portable communications device that could be employed by emergency personnel during an emergency.
- Accordingly, a need exists for a method and mechanism by which a file on the storage device of a computing device can be executed almost immediately. In particular, a need exists for a method and mechanism where the file is stored on the storage device and can be executed directly therefrom. Still further, a need exists for such a method and mechanism by which the file can be stored on the storage device in a fragmented manner and still can be executed directly from such storage device.
- The aforementioned needs are satisfied at least in part by the present invention in which a method is provided for updating an application residing on a storage device of a computing device. In the method, the update is simulated by performing all necessary actions except for actually committing data relating to the update to the storage device, and it is determined whether the simulated update succeeded. If so, the update is performed by performing the same necessary actions and also actually committing the data relating to the update to the storage device.
- The aforementioned needs are also satisfied at least in part by the present invention in which a computing device includes a storage device and a file system for storing and retrieving files on the storage device. The storage device includes storage space divided into sectors and the file system externally addresses the storage device on a per-sector basis, but internally divides each sector of the storage device into chunks and manages data within each sector on a per-chunk basis. Thus, the file system reads a chunk from or writes a chunk to the storage device by reading or writing the sector having the chunk.
- The aforementioned needs are further satisfied at least in part by the present invention in which a computing device includes a storage device having a file and a file system for storing and retrieving the file on the storage device. The file includes a plurality of segments, where each of at least some of the segments is null data and each of at least some of the segments is substantive data. The file has space allocated therein for each null data segment but such allocated space is not actually filled with information, and the file has space allocated therein for each substantive data segment and such allocated space is actually filled with information. Each null data segment is not actually physically stored on the storage device and each substantive data segment is actually stored on the storage device.
- The aforementioned needs are still further satisfied at least in part by the present invention in which a computing device includes a processor, a storage device having an executable file, and a file system for executing the file in place on the storage device on behalf of the processor. The file is divided into multiple non-contiguous fragments on the storage device, and the computing device further includes a virtual address translator interposed between the processor and the storage device for translating between physical addresses of the fragments of the file on the storage device and corresponding virtual addresses employed by the processor. The file system provides a virtual start address and the physical location and length of each fragment of the executable file to the virtual address translator, which creates a mapping of the physical location and length of each fragment of the executable file to a single contiguous virtual location starting at the virtual start address.
- The foregoing summary, as well as the following detailed description of the embodiments of the present invention, will be better understood when read in conjunction with the appended drawings. For the purpose of illustrating the invention, there are shown in the drawings embodiments which are presently preferred. As should be understood, however, the invention is not limited to the precise arrangements and instrumentalities shown. In the drawings:
-
FIG. 1 is a block diagram representing a general purpose computer system in which aspects of the present invention and/or portions thereof may be incorporated; and -
FIG. 2 is a block diagram showing a computing device with a storage device upon which is stored data including applications and a file system and metadata relating to the data; -
FIG. 3 is a flow diagram showing key steps performed in connection with the computing device ofFIG. 2 in updating an application on the storage device in accordance with one embodiment of the present invention; -
FIG. 4 is a block diagram showing sectors on the storage device ofFIG. 2 subdivided into chunks, andFIG. 4A is a block diagram showing files stored according to the chunks ofFIG. 4 and a minimum-size block for each fragment of each file in accordance with one embodiment of the present invention; -
FIG. 5 is block diagram showing a file stored on the storage device ofFIG. 2 according to a sparse implementation whereby null data segments of the file are not in fact stored in accordance with one embodiment of the present invention; -
FIG. 6 is a flow diagram showing key steps performed in connection with the sparse implementation of file storage ofFIG. 5 in accordance with one embodiment of the present invention; -
FIG. 7 is block diagram showing a file stored on the storage device ofFIG. 2 and executable in place in accordance with one embodiment of the present invention; and -
FIG. 8 is a flow diagram showing key steps performed in connection with executing the file ofFIG. 7 in place in accordance with one embodiment of the present invention. -
FIG. 1 and the following discussion are intended to provide a brief general description of a suitable computing environment in which the present invention and/or portions thereof may be implemented. Although not required, the invention is described in the general context of computer-executable instructions, such as program modules, being executed by a computer, such as a client workstation or a server. Generally, program modules include routines, programs, objects, components, data structures and the like that perform particular tasks or implement particular abstract data types. Moreover, it should be appreciated that the invention and/or portions thereof may be practiced with other computer system configurations, including hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers and the like. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices. - As shown in
FIG. 1 , an exemplary general purpose computing system includes a conventionalpersonal computer 120 or the like, including aprocessing unit 121, asystem memory 122, and a system bus 123 that couples various system components including the system memory to theprocessing unit 121. The system bus 123 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. The system memory includes read-only memory (ROM) 124 and random access memory (RAM) 125. A basic input/output system 126 (BIOS), containing the basic routines that help to transfer information between elements within thepersonal computer 120, such as during start-up, is stored inROM 124. - The
personal computer 120 may further include ahard disk drive 127 for reading from and writing to a hard disk (not shown), amagnetic disk drive 128 for reading from or writing to a removablemagnetic disk 129, and anoptical disk drive 130 for reading from or writing to a removableoptical disk 131 such as a CD-ROM or other optical media. Thehard disk drive 127,magnetic disk drive 128, andoptical disk drive 130 are connected to the system bus 123 by a harddisk drive interface 132, a magneticdisk drive interface 133, and anoptical drive interface 134, respectively. The drives and their associated computer-readable media provide non-volatile storage of computer readable instructions, data structures, program modules and other data for thepersonal computer 120. - Although the exemplary environment described herein employs a hard disk, a removable
magnetic disk 129, and a removableoptical disk 131, it should be appreciated that other types of computer readable media which can store data that is accessible by a computer may also be used in the exemplary operating environment. Such other types of media include a magnetic cassette, a flash memory card, a digital video disk, a Bernoulli cartridge, a random access memory (RAM), a read-only memory (ROM), and the like. - A number of program modules may be stored on the hard disk,
magnetic disk 129,optical disk 131,ROM 124 orRAM 125, including anoperating system 135, one ormore application programs 136,other program modules 137 andprogram data 138. A user may enter commands and information into thepersonal computer 120 through input devices such as akeyboard 140 andpointing device 142. Other input devices (not shown) may include a microphone, joystick, game pad, satellite disk, scanner, or the like. These and other input devices are often connected to theprocessing unit 121 through aserial port interface 146 that is coupled to the system bus, but may be connected by other interfaces, such as a parallel port, game port, or universal serial bus (USB). Amonitor 147 or other type of display device is also connected to the system bus 123 via an interface, such as avideo adapter 148. In addition to themonitor 147, a personal computer typically includes other peripheral output devices (not shown), such as speakers and printers. The exemplary system ofFIG. 1 also includes ahost adapter 155, a Small Computer System Interface (SCSI) bus 156, and anexternal storage device 162 connected to the SCSI bus 156. - The
personal computer 120 may operate in a networked environment using logical connections to one or more remote computers, such as aremote computer 149. Theremote computer 149 may be another personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to thepersonal computer 120, although only amemory storage device 150 has been illustrated inFIG. 1 . The logical connections depicted inFIG. 1 include a local area network (LAN) 151 and a wide area network (WAN) 152. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet. - When used in a LAN networking environment, the
personal computer 120 is connected to theLAN 151 through a network interface oradapter 153. When used in a WAN networking environment, thepersonal computer 120 typically includes amodem 154 or other means for establishing communications over thewide area network 152, such as the Internet. Themodem 154, which may be internal or external, is connected to the system bus 123 via theserial port interface 146. In a networked environment, program modules depicted relative to thepersonal computer 120, or portions thereof, may be stored in the remote memory storage device. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used. - Computing Device with Relatively Small Storage Device
- Turning now to
FIG. 2 , it is seen that the present invention is believed to be especially useful in connection with acomputing device 10 with a relativelysmall storage device 12 upon which is loaded one ormore applications 14 and afile system 16. Thecomputing device 10 may be any type of computing device without departing from the spirit and scope of the present invention, although it is likely that if thestorage device 12 is relatively small, then so too is thecomputing device 10. For example, thecomputing device 10 may be a portable media player or game player, a portable digital assistant, or a portable personal computer. - The
storage device 12 on thecomputing device 10 may be any storage device without departing from the spirit and scope of the present invention. Although the present invention is especially applicable to situations where thestorage device 12 is relatively small,such storage device 12 may indeed be of any size without departing from the spirit and scope of the present invention. Depending on thecomputing device 10, thestorage device 12 may be a hard disk drive, a memory card, flash RAM (random access memory), or the like, andsuch storage device 12 likely has an appropriate hardware driver (not shown), through which access thereto is managed. - Note that in addition to the
storage device 12, thecomputing device 10 likely has alocal RAM 18 from which data from thestorage device 12 may be transferred prior to being manipulated. That is, thecomputing device 10 in at least some instances likely does not operate directly on data stored in thestorage device 10, but instead copies such data from thestorage device 12 to thelocal RAM 18, operates on the data in thelocal RAM 18, and then if necessary copies such operated-on data back to thestorage device 12. Reasons for doing so are many and varied, but as should be appreciated typically involve faster speed and access. At any rate, suchlocal RAM 18 may be any kind of appropriate RAM without departing from the spirit and scope of the present invention. - The
applications 14 on thestorage device 12 may be any applications without departing from the spirit and scope of the present invention, and may be instantiated in thelocal RAM 18 or elsewhere. If thecomputing device 10 is a task-specific device, such as for example an audio player, theapplications 14 likely are likewise task-specific, although it is to be appreciated that in at least some instancesother applications 14 may also be present. - It is to be appreciated that the
file system 16 is in fact a type ofapplication 14, although with special significance to thecomputing device 10. Thefile system 16 on thestorage device 12 may likewise be any file system without departing from the spirit and scope of the present invention, and may be instantiated in thelocal RAM 18 or elsewhere. Thefile system 16 need not necessarily be especially task-specific but instead may be more tailored to the non-task-specific operational requirements of thecomputing device 10. Thus,such file system 16 is employed to operate thecomputing device 10 during start-up thereof and in the course ofloading applications 14 thereon, and also is employed to access data on thestorage device 12, thelocal RAM 18, and elsewhere. - As was noted above, updating an
application 14 or thefile system 16 on the relativelysmall storage device 12 can be complicated, especially if thestorage device 12 does not have much free space available. For example, if the lack of free space onsuch storage device 12 prevents update data from being written thereto without first deleting old data, it can be the case that a failure during the update leaves theapplication 14 orfile system 16 in an incoherent and likely nonfunctional state. Likewise, if the lack of free space onsuch storage device 12 necessitates the update being applied by modifying individual files with ‘delta’ data, it can also be the case that a failure during the update leaves theapplication 14 orfile system 16 in an incoherent and likely nonfunctional state. Again, in the case of theapplication 14 such failure may be an annoyance until the application is reloaded, if possible, but in the case of thefile system 16, such failure may be catastrophic inasmuch as thecomputing device 10 may be inoperable without a functioningfile system 16. - Accordingly, and in one embodiment of the present invention, updating of an
application 14 or the file system 16 (hereinafter, ‘application 14’) on acomputing device 10 is performed as a two-step procedure, whereby in the first step the update is simulated, and in the second step the update is actually performed, but only if the simulated update of the first step is deemed to have succeeded. In particular, in the first step, the simulated update performs all necessary actions except for actually committing data relating to the update to thestorage device 12, and in the second step, the actual update performs the same necessary actions and also actually commits the data relating to the update to thestorage device 12. - To implement the present invention, it should be appreciated that the
file system 16 of thecomputing device 10 typically maintainsmetadata 20 relating to data stored on thestorage device 12. As may be appreciated, such data is typically stored on thestorage device 12 as files, and themetadata 20 may include for each file data including a name, a size, various time stamps, the physical and/or virtual location of the file on thestorage device 12 or the parts that constitute the file on thestorage device 12, and various attributes with regard to the file, among other things. In addition, and assuming thestorage device 12 is organized into portions of data,such metadata 20 may include for the storage device 12 a ‘free’ list of such portions that are available to accept data, or the equivalent. - As should be appreciated, then, modifying data in a file of the
storage device 12 of thecomputing device 10 may also necessitate modifyingmetadata 20 related to the modified file, and perhaps the free list. Also typically, thefile system 16 during operation thereof copies themetadata 20 or a portion thereof to thelocal RAM 18 or the equivalent such that the copy of themetadata 20 on thelocal RAM 18 is modified as necessary during operation of thefile system 16, and the modified copy of themetadata 20 on thelocal RAM 18 is as necessary memorialized to thestorage device 12. - Typically, modifications to a file on the
storage device 12 by thefile system 16 can include adding a new file, deleting an existing file, and modifying an existing file. Briefly, adding a new file is achieved by finding space for the file by way of the free list in themetadata 20, creating appropriate data for the file in themetadata 20, adding the data for the new file to the found space on thestorage device 12, and updating the free list in the metadata to reflect the use of the found space. Likewise, deleting an existing file is achieved by removing data for the file in themetadata 20 as appropriate and updating the free list in the metadata to reflect the now-free space. Modifying an existing file is achieved in a manner akin to adding or deleting a file, depending of course on whether data is added and/or deleted from the file. At any rate, it is to be appreciated that any modification to a file results in a corresponding modification to metadata 20 associated with the file and also to metadata 20 relating to thestorage device 12 itself. - With the aforementioned in mind, then, and in one embodiment of the present invention, the
computing device 10 may be operated in a simulation mode and in a regular mode, whereby during the aforementioned first step where an update is simulated, thecomputing device 10 is operated in the simulation mode. Likewise, during the aforementioned second step where the update is actually performed, but only if the simulated update of the first step is deemed to have succeeded, and during most any other time, thecomputing device 10 is operated in the regular mode. Recognizing that updates to anapplication 14 are typically performed by an installer, thecomputing device 10 may be placed into and out of the simulation mode by such an installer during operation thereof. - Principally, when the
computing device 10 is placed from the regular mode into the simulation mode, a copy of themetadata 20 as set forth in thelocal RAM 18 is saved for later retrieval, either to thestorage device 12, thelocal RAM 18, a cache, or elsewhere. Thereafter, during operation of thecomputing device 10, no data is actually committed to thestorage device 12. At some later point, when thecomputing device 10 is placed back into the regular mode from the simulation mode, the saved copy of themetadata 20 is retrieved and restored to thelocal RAM 18 to reflect the actual state of thestorage device 12 inasmuch as the data on thestorage device 12 should not have been changed during the course of the simulation mode. Thereafter, during operation of thecomputing device 10, data is again actually committed to thestorage device 12. Thus, and as should be appreciated, placing thecomputing device 10 into the simulation mode should not permanently change any of the data stored on thestorage device 12, and ‘changes’ to such data may thus be simulated without much if any risk. - As should now be appreciated, with the use of the simulation mode during the course of updating an
application 14 on acomputing device 10, such updating maybe performed first in a non-destructive manner so as not to modify files on thestorage device 12 ofsuch computing device 10. Thus, such simulation mode allows a pre-determination of whether a series of modifications will succeed or fail without committing the modifications to thestorage device 12. When in simulation mode, all modifications to thestorage device 12 are in fact made only to themetadata 20 maintained in thelocal RAM 18. As file contents are allocated and de-allocated, free space is tracked in the free list in themetadata 20 on thelocal RAM 18, but file data is not actually committed to thestorage device 12. If, for example, free space becomes exhausted or thefile system 16 encounters an error during a file operation, the calling entity will be notified through a return value. Significantly, if a failure occurs, the update should not be allowed to in fact take place when thecomputing device 12 is placed back into regular mode. Correspondingly, if no failures occur, the update should be allowed to in fact take place when thecomputing device 12 is placed back into regular mode, by re-running the same series of modifications. - As should now be appreciated, in the present invention, the code executed during the first step while the
computing device 10 has been placed into simulation mode is identical to the code executed during the second step while thecomputing device 10 has been placed back into regular mode, except that all write operations for writing data to thestorage device 12 are disabled during simulation mode. Therefore, if all modifications succeed in the first step during simulation mode, it can be assumed that the same sequence of modifications will also succeed in the second step during regular mode. Likewise, if any modification fails in the first step during simulation mode, it can be assumed that the same modification will also fail in the second step during regular mode, and such second step is thus not in fact performed. - Turning now to
FIG. 3 , an installer or the like installing or updating anapplication 14 on thestorage device 12 of thecomputing device 10 does so in the following manner. Preliminarily, the installer performs the first step by causing thecomputing device 10 to enter into the simulation mode (step 301). Such step may typically be performed by issuance of a command to thecomputing device 10 and particularly the processor or controller thereof, which of course presumes thatsuch computing device 10 is in fact capable of accepting and understanding such command and is in fact capable of entering into the simulation mode as set forth above. - At any rate, and as was also set forth above, upon entering the simulation mode, the
computing device 10 saves a copy of themetadata 20 as set forth in thelocal RAM 18 for later retrieval, and thereafter thefile system 16 ofsuch computing device 10 is set to not actually commit data to thestorage device 12 during file operations, but to otherwise perform all other actions normally incumbent in such file operations. - Thereafter, for each file operation proscribed by the installer, the
file system 16 in fact performs such file operation, except of course for actually committing data to the storage device 12 (step 303). With the understanding that each such file operation is typically issued as a call with a return value indicative of success or failure, the installer receives the return value associated with the file operation and determines therefrom whether the operation succeeded (step 305). Note, too that such installer may determine whether the operation succeeded based on criteria independent of such a return value, such as for example based on code included with such installer or based on a determination of a particular system value. - If the operation did indeed succeed, the installer performs the next file operation as at
step 303. However, if the operation failed for any reason, the installer instead causes thecomputing device 10 to return to the regular mode (step 307), typically by issuance of a command to thecomputing device 10 and particularly the processor or controller thereof, which again presumes thatsuch computing device 10 is in fact capable of accepting and understanding such command and is in fact capable of returning to the regular mode as set forth above. - Critically, upon returning to the regular mode as at
step 307 by way of the determination that an operation did not succeed as atstep 305, the installer does not in fact perform the update, but instead ends the procedure based on the assumption that thecomputing device 10 is not capable of receiving the update (step 309). As was set forth above, when thecomputing device 10 is placed back into the regular mode from the simulation mode as atstep 307, the saved copy of themetadata 20 is retrieved and restored to thelocal RAM 18 to reflect the actual state of thestorage device 12 inasmuch as the data on thestorage device 12 should not have been changed during the course of the simulation mode. Thereafter, during operation of thecomputing device 10, data is again actually committed to thestorage device 12. - Note that if the update ends at
step 309, the update is not in fact applied and theapplication 14 that was to have been updated should remain on thestorage device 12 in a non-updated state. Significantly, although not updated,such application 14 is at least not left in some unfinished state of update that would either cause theapplication 14 to function in an impaired manner, or worse yet cause theapplication 14 to not function at all. - Returning now to each operation performed as at
step 303, and presuming that no operation has been found to have failed as atstep 305, the installer at some point will have determined that all operations have been performed (step 311). Thus, step one has concluded with the update being successfully simulated. Accordingly, such update may now in fact be performed as at step two. - In particular, with a successful simulation, the installer causes the
computing device 10 to return to the regular mode (step 313), again typically by issuance of a command to thecomputing device 10 and particularly the processor or controller thereof. Critically, upon returning to the regular mode as atstep 313 by way of the determination that all operations succeeded, the installer does in fact perform the update. As was set forth above, when thecomputing device 10 is placed back into the regular mode from the simulation mode as atstep 313, the saved copy of themetadata 20 is retrieved and restored to thelocal RAM 18 to reflect the actual state of thestorage device 12 inasmuch as the data on thestorage device 12 should not have been changed during the course of the simulation mode. Thereafter, during operation of thecomputing device 10, data is again actually committed to thestorage device 12. - To in fact perform the update, and for each file operation proscribed by the installer, the
file system 16 in fact performs such file operation (step 315). Significantly, inasmuch as thecomputing device 10 is now in the regular mode, thefile system 16 does in fact actually commit data to thestorage device 12 in connection with each such operation. Again, the installer at some point will have determined that all operations have been in fact performed, will have thus concluded that the update of theapplication 14 has been successfully installed, and will end (step 317). - Note that the installer in the course of performing each file operation as at
step 315 may determine whether the operation succeeded in a manner akin to that at step 305 (not shown). However, such a step is not believed to be absolutely necessary to the present invention inasmuch as each operation was previously successfully simulated as atstep 303. Nevertheless, instances can occur where an operation could succeed in simulation mode but fail in regular mode. That said, however, such instances are believed to be rare and beyond the scope of the present invention. - The present invention operates by simulating an update without committing any data to the
storage device 12 during such simulated update. The operations performed in simulation mode are identical to the operations performed in regular mode with the exception of committing data to thestorage device 12, which are disabled during simulation mode. Therefore, if all update operations succeed in simulation mode, the installer can assume the same sequence of operations will also succeed in regular operation, except for example certain cases of catastrophic failure of thestorage device 12. - It should be appreciated that certain minor modifications may be necessary if the update includes operations on data that is expected to have been committed to the
storage device 12 but in fact has not. Generally, and as should also be appreciated, such minor modifications require caching of such data and redirecting performance of such operations to such cached data. - Typically, a storage device such as the
storage device 12 cannot address each individual byte of information stored thereon. As should be appreciated, to do so is not usually necessary, and more importantly doing so would require unduly large address information which would be unwieldy and would make tracking information related to the storage device more complicated. Such tracking information may for example include lists of free and/or used space, lists of bad space, etc. Instead, and turning now toFIG. 4 , a storage device usually subdivides the space thereof according toaddressable sectors 22 of information, where eachsector 22 may be defined to have on the order of 512 or 1024 bytes, and such a storage device would then read and write data on a per-sector basis according to an address thereof, even if only a few bytes within asector 22 are to be dealt with. - A typical file system could address such a storage device on a per-sector basis, although with regard to a relatively large storage device upon which is stored
larger files 28 it is usually more convenient to define a cluster 24 as a number ofsectors 22, to address such storage device on a per-cluster basis, and to require that eachfile 28 use at least one cluster 24 (not shown as such inFIG. 4 ). As before, doing so allows the file system to avoid unduly large address information which would be unwieldy and would complicate tracking information related to the storage device, such as the aforementioned free list in themetadata 20. Typically, a cluster 24 is a base-2 multiple ofsectors 22, such as for example 1, 2, 4, 8, or 16 kilobytes or more, and the file system would read from and write to the storage device on a per-cluster basis even if only afew sectors 22 within a cluster 24 are to be dealt with. - However, and as was pointed out above, if a
file 28 with only a small amount of data (a few to a few hundred bytes, for example) is assigned to a particular cluster 24, all the remaining space in such cluster 24 is wasted, and in a relatively small storage device, such wasted space could quickly become significant. Accordingly, in one embodiment of the present invention, and as a first measure, thefile system 16 for thestorage device 12 ofFIG. 2 does not addresssuch storage device 12 on a per-cluster basis but instead addresses same on a per-sector basis, and therefore requires that eachfile 28 use at least onesector 22 of the storage device 12 (not shown as such inFIG. 4 ). As a result, and as may be appreciated, a relativelysmall file 28 on the order of a few to a few tens of bytes stored on for example a 512byte sector 22 wastes only a few hundred bytes, and does not waste thousands of bytes as would be the case with for example an 8 kilobyte cluster 24. - Note that while requiring the
file system 16 to address thestorage device 12 on a per-sector basis results in longer and therefore more complicated addressing as compared with on a per-cluster basis, the amount of space that is to be addressed is relatively small for a relativelysmall storage device 12, and addresses therefor are thus also relatively small. For example, for a 16megabyte storage device 12 with 8 kilobyte clusters and 1 kilobyte sectors, addressing on a per-sector basis requires addresses with three additional bits, but such addresses are still only 14 bits long, which should be considered reasonable. - As may be appreciated, even with the
file system 16 addressing thestorage device 12 on a per-sector basis, it may still be considered unacceptably inefficient to waste hundred or even tens of bytes when a relativelysmall file 28 on the order of a few to a few tens of bytes is stored on for example a 512byte sector 22. Accordingly, in one embodiment of the present invention, and as a second measure, thefile system 16 while still addressing thestorage device 12 on a per-sector basis internally manages the data within each sector on a per-chunk basis, where each chunk 26 (FIG. 4 ) is for example defined as a base-2 division of asector 22. - In storing
files 28 on a per-chunk basis (as shown inFIG. 4 ), and as should be appreciated, thefile system 16 would internally require that eachfile 28 use at least onechunk 26 of thestorage device 12, but would still externally address thestorage device 12 on a per-sector basis. Thus, to read from or write to the storage device 12 aparticular chunk 26, thefile system 16 would have to read or write thesector 22 having thechunk 26. As a result, thefile system 16 not only must keep track of the eachsector 22 used by afile 28 but eachchunk 26 within eachsector 22 used by thefile 28. Doing so, while more elaborate, is not believed to be overly burdensome, and may be performed in any appropriate manner without departing from the spirit and scope of the present invention. At any rate, and as should also be appreciated, a relativelysmall file 28 on the order of a few to a few tens of bytes stored on for example a 64byte chunk 26 wastes only a few to a few tens of bytes, and does not waste hundreds of bytes as would be the case with for example a 512byte sector 22. - Similar to before, it should be noted that while requiring the
file system 16 to internally address files 28 on a per-chunk basis results in longer and therefore more complicated addressing as compared with on a per-sector basis, the amount of space that is to be addressed is relatively small for a relativelysmall storage device 12, and addresses therefor are thus also relatively small. To continue the previous example, for a 16megabyte storage device 12 with 1kilobyte sectors 22 and 256byte chunks 26, addressing on a per-chunk basis requires addresses with two additional bits, but such addresses are still only 16 bits long, which should be considered reasonable. - Note that as with the size of each cluster 24 and the size of each
sector 22, the size of eachchunk 26 should be defined for thefile system 16 when thestorage device 12 is initially formatted and/or partitioned. However, it is to be appreciated that thestorage device 12 is not addressed by thefile system 16 on a per-chunk basis and therefore need not be aware of the size of eachchunk 26. Instead, and again, thefile system 16 internally organizes thefiles 28 on thestorage device 12 on a per-chunk basis, but externally addresses thestorage device 12 on a per-sector basis. - As alluded to above, the
file system 16 must maintain for eachfile 28 on thestorage device 12 locating information for locating eachsector 22 used by thefile 28 and eachchunk 26 within eachsector 22 used by thefile 28. As may be appreciated, doing so is relatively simple in an instance where afile 28 is contiguous on asingle sector 22, in which case thefile system 16 need only note in pertinent part the address of thesector 22, the address of the startingchunk 26 within thesector 22, and the length of the file inchunks 26. However, if thefile 28 is in two contiguous fragments on asingle sector 22, thefile system 16 now must note the address of thesector 22, the address of the startingchunk 26 of the first fragment within thesector 22, the length of the first fragment inchunks 26, the address of the startingchunk 26 of the second fragment within thesector 22, and the length of the second fragment inchunks 26. As may be appreciated, as afile 28 becomes more fragmented,such file 28 may come to reside onmultiple sectors 22 and inmultiple chunks 26 on each sector, and correspondingly the locating information for locating all the fragments of thefile 28 likewise becomes much larger. - As should be understood, such locating information may be stored in a list maintained by the
file system 16. Alternatively, the bulk of such locating information may be stored with thefile 28 itself as a header or the like, in which case thefile system 16 need only maintain so much information as is necessary to find such header. In the latter case, and as should also be understood, if such locating information is relatively large, such information may be separate from the header with such header including references thereto as appropriate. - At any rate, at some point as a
file 28 becomes larger and especially as thefile 28 becomes more fragmented, the locating information therefor becomes unacceptably large, especially in the case where thestorage device 12 is relatively small and use of the space thereof is to be done with relatively high efficiency. Such problem becomes especially exacerbated as the defined size of eachchunk 26 becomes smaller and thefile 28 thus may become spread over more fragments. Also, at some point as afile 28 becomes larger and more fragmented, locating and reading thefile 28 from or writing thefile 28 to thestorage device 12 becomes unacceptably cumbersome, especially in the case where an unacceptably high number of read or write operations must be performed due the number of fragments of thefile 28. As before, such problem becomes especially exacerbated as the defined size of eachchunk 26 becomes smaller and thefile 28 thus may become spread over more fragments. - Thus, and to summarize, the
file system 16 more efficiently stores eachfile 28 on thestorage device 12 space-wise by doing so on a per-chunk basis, where eachchunk 26 is smaller than asector 22, but in doing so thefile 28 likely becomes more fragmented as the file gets larger, to the point where the locating information for suchfragmented file 28 becomes unacceptably large and storing and retrieving thefragmented file 28 becomes unduly cumbersome. Accordingly, in one embodiment of the present invention, and as a third measure, thefile system 16 while still internally managing eachfile 28 on a per-chunk basis nevertheless imposes a minimum size requirement on eachfile 28 such that thefile 28 cannot be fragmented into parts smaller than the minimum size. For example, for astorage device 12 with 4kilobyte sectors 22 and 256 byte chunks 26 (i.e., 16chunks 26 per sector 22) a minimum-size block 30 (FIG. 4 ) could be defined as 1, 2, 4, or even 8 kilobytes or more. Note that in at least some instances such a minimum-size block 30 (FIG. 4A ) could run acrossmultiple sectors 22, but that such an instance is not believed to be problematic. - In storing
files 28 on a minimum-size block basis (as shown inFIG. 4A ), and as should be appreciated, thefile system 16 would internally require that if afile 28 is to be stored in a fragmented form on thestorage device 12, each fragment 32 is to be at least as large as the defined minimum-size block 30, excepting of course for any remainder fragment 32 of thefile 28 that does not fill such a minimum-size block 30. In doing so, thefile system 16 must maintain a ‘free’list 34 ofchunks 26 that are available to accept data, or the equivalent, and consult therewith. Doing so should be known or apparent to the relevant public and therefore need not be set forth herein in any detail. Thefile system 16 may therefore employ any method of employing such afree list 34 and dividing afile 28 into fragments 32 based on suchfree list 34 and a minimum-size block 30 without departing from the spirit and scope of the present invention. - Note that as with the size of each
chunk 26, the minimum-size block 30 should be defined for thefile system 16 when thestorage device 12 is initially formatted and/or partitioned. However, it is to be appreciated that thestorage device 12 is not addressed by thefile system 16 with any direct reference to the minimum-size block 30 and therefore need not be aware of same. - Note, too, that by imposing the requirement of a minimum-size block 30, the
file system 16 may lose some of the efficiency gained by employingchunks 26 in storing data on thestorage device 12. Nevertheless, such lost efficiency should be offset and even outweighed by the increased efficiency obtained from reduced file fragmentation. Moreover,chunks 26 of space on thestorage device 12 that are unavailable to aparticular file 28 based on the requirement of the minimum-size block 30 are still available toother files 28. - In at least some instances, the
file system 16 may increase efficiency of used space on thestorage device 12 by compressing eachfile 28 before storing same. If so, and in one embodiment of the present invention, thefile 28 is divided into fragments 32 having the size of the minimum-size block 30 and each fragment 32 is thus compressed. Each such compressed fragment 32 is thus of a size smaller than the minimum-size block 30 but nevertheless such an arrangement has been found to work well overall. - File Structure for File with Null Data Therein
- As was set forth above, in certain instances a
file 28 on a storage device such as thestorage device 12 may contains portions of unallocated or null data such that space exists within thefile 28 but is not filled with substantive data. Such null data may instead simply be represented as all zeroes or some other placeholder value, and exists only to be filled in at some later time with such substantive data. Alternatively, such null data may be created when substantive data is removed from thefile 28 for whatever reason. - Thus, it may be the case that a relatively
large file 28 exists on thestorage device 12, but in factsuch file 28 is for the most part null data, either in a single contiguous portion or as a plurality of contiguous or non-contiguous portions. In such instance, and particularly where thestorage device 12 is relatively small, it would be highly useful to in fact free the space occupied by the null data of thefile 28. Accordingly, such otherwise occupied space can be made available to be employed by anotherfile 28. - In one embodiment of the present invention, and turning now to
FIG. 5 , to in fact free space occupied by null data within afile 28,such file 28 is stored by thefile system 16 on thestorage device 12 according to the structure shown. In particular, and as seen,such file 28 includes afile header 36, a segment allocation table 38, and theactual file data 40 except for the null data. - As may be appreciated, the
file header 36 includes information about thefile 28 including file attributes, file size, time stamps, the file name, and the like. In addition, and in the present invention, thefile header 36 includes a reference to a location of the segment allocation table 38 therefor on thestorage device 12. Note that such reference may be to a single contiguous segment allocation table 38, or to multiple non-contiguous portions of such a segment allocation tables 38 that are to be combined to form a single contiguous table 38. If the segment allocation table 38 is highly fragmented, thefile header 36 can even refer to a list of secondary data headers 42 which contain references to additional locations of portions of the segment allocation table 38. - At any rate, the segment allocation table 38 may be constructed from such portions based on such references in a manner that should be apparent to the relevant public and therefore need not be set forth herein in any detail. Upon in fact constructing the segment allocation table 38, as is shown in
FIG. 5 , it is to be seen that such table 38 includes ordered references to locations of theactual file data 40 that constitutes thefile 28. As may be appreciated, such references may be to fixed- or variable-length segments of theactual file data 40. In the former case, the fixed length may for example be the aforementioned minimum-sized block 30, while in the latter case each reference should include a length attribute. Of course, employing fixed-length segments obviates the need for such length attributes. - Thus, whenever the
file 28 is opened for reading or writing by an application, thefile header 36 is examined to locate all pieces of the segment allocation table 38, and such pieces are copied from thestorage device 12 into a contiguous section of thelocal RAM 18 or the like. Thereafter,data 40 for thefile 28 may be located by indexing into the contiguous segment allocation table 38 to find the location forsuch data 40 on thestorage device 12. As may be appreciated, as new data is written to thefile 28, the table 38 is extended as necessary to encompass the segment at the furthest offset into thefile 28. Note that in order to limit fragmentation of the table 38, such table 38 may be pre-allocated to the intended file size, especially if the final size of thefile 28 is already known and the segments of thedata 40 are fixed in length. - Significantly, in the present invention, the
data 40 for thefile 28 is stored on thestorage device 12 in a ‘sparse’ manner, whereby substantive segments of thedata 40 are referenced by the segment allocation table 38 and in fact are stored, while null segments of thedata 40 are noted by the segment allocation table 38 but are not in fact stored or referenced. In particular, for each segment withsubstantive data 40, the corresponding entry in the segment allocation table 38 includes a reference, while for each segment with onlynull data 40, the corresponding entry in the segment allocation table 38 includes no reference or else a null reference. Thus, thefile 28 shown inFIG. 5 has 15 segments, butsegments null data 40 and are thus not actually referenced by any entry of the segment allocation table 38. - Note that in writing the
file 28 as shown inFIG. 5 , thefile system 16 of thecomputing device 10 does not actually write the null segments ofdata 40 but instead merely creates appropriate entries therefor in the segment allocation table 38 forsuch file 28. With the present invention, then, thefile system 16 readsdata 40 from any offset of thefile 28 using appropriate calls to thestorage device 12 based on the segment allocation table 38 for thefile 28, and likewise, thefile system 16 writesdata 40 to any offset of thefile 28 using appropriate calls to thestorage device 12 based on the segment allocation table 38 for thefile 28. Significantly, any physical portion of thestorage device 12 allocated to thefile 28 can later be de-allocated if no longer needed, thus freeing space onsuch storage device 12. - Thus, the
file system 16 may replace null segments within afile 28 with substantive segments ofdata 40 by writing such substantive segments of data to thestorage device 12 and updating the entries therefor in the segment allocation table 38 with appropriate references. Similarly, thefile system 16 may replace substantive segments ofdata 40 with null data at some later point by updating the entries therefor in the segment allocation table 38 with null references or to remove existing references. The replacedsubstantive data 40 may for example be physically deleted, moved to another location, or may be left to be overwritten byother data 40. Notably, in the present invention, when replacingsubstantive data 40 withnull data 40, the space on thestorage device 12 occupied by such replacedsubstantive data 40 is in fact freed up and available to acceptother data 40, and accordingly thefile system 16 should update thefree list 34 to reflect same. - With the present invention, and as should now be appreciated, a
file 28 need not necessarily be constructed in a linear fashion from beginning to end. Instead, afile system 16 with knowledge of the size of the file may establish a segment allocation table 38 therefor and then populate segments ofdata 40 for thefile 28 in any order on thestorage device 12. Significantly, while populating each such segment ofdata 40 on thestorage device 12, the file system appropriately references same in a corresponding entry in the table 38. - Notably, with the file structure of the present invention as shown in
FIG. 5 , thefile system 16 may construct anew file 28 with parts of anold file 28 to be deleted, such as for example when updating afile 28, and in doing so can deconstruct the old version of thefile 28 and free space on thestorage device 12 while constructing the new version of thefile 28. In fact, the freed space from the old version of thefile 28 may be used to store at least part of the new version of thefile 28. Thus, and particularly in astorage device 12 with little space left, updating afile 28 does not necessarily require enough free space to construct the new version of thefile 28 without deleting the old version ofsuch file 28. - Instead, and as seen in
FIG. 6 , if the new version of thefile 28 is to include a segment from the old version of thefile 28, such segment may be copied from the old version of the file 28 (step 601) and saved to the new version of the file 28 (step 603) along with appropriate modification of the segment allocation table 38 of the new version of thefile 28. Thereafter, such segment may be deleted from the old version of the file 28 (step 605) along with appropriate modification of the segment allocation table 38 ofsuch file 28, and the space freed from thestorage device 12 based on such action may then be employed to store another segment of the new version of the file 28 (step 607) along with appropriate modification of the segment allocation table 38 ofsuch file 28. - As should now be appreciated, such steps may be repeated numerous times, with the physical size of the new version of the
file 28 increasing on thestorage device 12 as the physical size of the old version of thefile 28 decreases, until eventually the new version of thefile 28 is completely constructed (step 609). The old version of thefile 28 may then be deleted to free up space occupied by any remaining segments of suchold file 28 on the storage device 12 (step 611). - Note that in at least some circumstances, a segment need not be physically copied from the old version of the
file 28, saved to the new version ofsuch file 28, and deleted from the old version of thefile 28, as at steps 601-605. Instead, it maybe enough to merely de-reference the segment from the segment allocation table 38 of the old version of thefile 28, and to reference the same segment in the segment allocation table 38 of the new version of thefile 28. - With the present invention, and as should now be appreciated, a
file 28 may be stored on astorage device 12 in a sparse manner such that null portions of thefile 28 are not in fact stored. Thus, space on thestorage device 12 is freed and available forother files 28, while at the same time such null portions of thefile 28 may be populated withsubstantive data 40 at some later time. - As was set forth above, in certain instances it is desirable to execute an
executable file 28 on thestorage device 12 almost immediately and without loading same to thelocal RAM 18 or another location. For example, it may be the case that thecomputing device 12 is expected to react from user commands on demand and in an almost instantaneous manner, where such commands require executing such anexecutable file 28. Alternatively, it may be desirable to dispense with use of thelocal RAM 18 for executing thefile 28. - As was set forth above, a
typical storage device 12 for acomputing device 10 can only be addressed on a per-cluster or per-sector basis. Each byte in thestorage device 12 therefore cannot be directly accessed therefrom without reading thesector 22 or cluster 24 thereof. As a result, afile 28 cannot normally be executed directly from suchtypical storage device 12, especially inasmuch as such execution normally requires access to such file on a per-byte. Accordingly, to execute thefile 28,such file 28 is typically loaded from thestorage device 12 to the local, where it may be appreciated that each byte ofsuch file 28 can in fact be directly accessed. - In one embodiment of the present invention, however, the
storage device 12 is in fact addressable on a per-byte basis. For example,such storage device 12 may be a NOR flash RAM which, as may be appreciated, in fact allows direct addressable access thereto on a per-byte basis. NOR flash RAM is known to the relevant public and therefore need not be set forth herein in any detail. Accordingly, any appropriate type of such NOR flash RAM may be employed as thestorage device 12 of acomputing device 10 without departing from the spirit and scope of the present invention. - Thus, the
file 28 may be executed in place on such NOR flashRAM storage device 12. However, to in fact be executed in place on such NOR RAM 12 (FIG. 7 ), several requirements should be met. - As a first requirement, and as an initial matter, the NOR
RAM 12 should be accessible to thefile system 16 of thecomputing device 10, just as is such NORRAM 12 were another storage device such as a drive. To do so, then, the NORRAM 12 requires acorresponding access driver 44. Generally, and as should be appreciated, theaccess driver 44 is a piece of software running on thecomputing device 10 which in response to calls fordata 40 from the NORRAM 12 by thefile system 16 based on physical addresses can in fact retrievesuch data 40, among other things. Such anaccess driver 44 is known to the relevant public and therefore need not be set forth herein in any detail. Accordingly, any appropriate type of such anaccess driver 44 may be employed without departing from the spirit and scope of the present invention, presuming of coursesuch access driver 44 includes appropriate functionality. - As a second requirement, the
file 28 should not be stored on the NORRAM 12 in a compressed form. As may be appreciated, doing so would not in fact allow thefile 28 to be executed in place on such NORRAM 12, inasmuch assuch file 28 would have to be loaded elsewhere, such as for example thelocal RAM 18, and decompressed. - Note that unless the
file 28 is stored on the NORRAM 12 in a contiguous or non-fragmented form and with appropriate physical branching addresses,such file 28 typically could not be executed in place on the NORRAM 12. However, in one embodiment of the present invention,such file 28 in fact can be executed in place on the NORRAM 12 even if in a non-contiguous or fragmented form. However, to do so, and as a third requirement,such file 28 specifies a starting virtual address and is stored on the NORRAM 12 with appropriate virtual branching addresses based on the specified starting virtual address. - Thus, as seen in
FIG. 7 , and as a fourth requirement, thecomputing device 10 must include avirtual address translator 46 that can translate between the physical addresses of the fragments 32 of thefile 28 on the NORRAM 12 and corresponding virtual addresses which aprocessor 48 or the like on thecomputing device 10 may employ. As should be appreciated,such processor 48 in executing thefile 28 inplace 28 would do so by fetching instructions from thefile 28 based on such virtual addresses and thevirtual address translator 46. - Thus, with the
virtual address translator 46, thefile 28 on the NORRAM 12 appear to be contiguous, at least to theprocessor 48, and the virtual branching addresses within thefile 28 are correct, presuming of course that the starting virtual address within thefile 28 is in fact employed therefor by thevirtual address translator 46. Generally, and as should also be appreciated, thevirtual address translator 46 functions by maintaining mappings between such physical and virtual addresses for thefile 28. Such avirtual address translator 46 is known to the relevant public and therefore need not be set forth herein in any detail. Accordingly, any appropriate type of such avirtual address translator 46 may be employed without departing from the spirit and scope of the present invention. - In operation, then, and turning now to
FIG. 8 , thecomputing device 10 executes afile 28 in place on the NORRAM 12 in the following manner. Preliminarily, of course, thefile system 16 is engaged by a user or other entity to execute thefile 28 by way of an appropriate command (step 801), and thus locatessuch file 28 on the NORRAM 12 by way of the access driver 44 (step 803). Thereafter, thefile system 16 determines that thefile 28 can in fact be executed in place on the NOR RAM 12 (step 805) by determining that thefile 28 does reside on the NORRAM 12, is not compressed, specifies a virtual start address and contains virtual branch addresses based thereon, and can be virtually mapped, among other things. - Presuming that the
file 28 can in fact be executed in place on the NORRAM 12, then, thefile system 16 obtains necessary information relating to thefile 28 by way of theaccess driver 44, including the aforementioned virtual start address and the physical location and length of each fragment 32 of the file 28 (step 807), and notifies thevirtual address translator 46 regarding same (step 809). As should now be appreciated, with such information, thevirtual address translator 46 creates a mapping of thefile 28 from the multiple non-contiguous physical locations on the NORRAM 12 to a single contiguous virtual location starting at the virtual start address specified by the file 28 (step 811). - Note that inasmuch as the virtual branch addresses within the
file 28 on the NORRAM 12 are already set up to be correct based on the specified virtual start address, neither thevirtual address translator 46 nor theprocessor 48 need concern itself with correcting same. At any rate, with the created mapping, theprocessor 48 is ready to execute the file 28 (step 813) by appropriately issuing commands based on the virtual address as mapped by thevirtual address translator 46. Thus, based on such virtual addresses, thetranslator 46 locatesdata 40 to be executed in connection with thefile 28 directly from the NORRAM 12. Note that in doing so, thefile system 16 and theaccess driver 44 need not be employed by theprocessor 48. - With the present invention, and as should now be appreciated, a
file 28 may be executed in place on thestorage device 12 of thecomputing device 10, even if non-contiguous. To do so, thefile 28 must not be compressed and must be stored with correct virtual addresses based on a predefined virtual start address, thestorage device 12 must be accessible by thefile system 16 by way of anaccess driver 44, and avirtual address translator 46 must be able to directly access thestorage device 12 based on translations of virtual addresses to physical addresses. - Although the present invention is set forth above in terms of specific elements performing specific actions, it is to be appreciated that the functionality of one element may be subsumed by another element without departing from the spirit and scope of the present invention. For example, it may be the case that the
file system 16 includes the functionality of theaccess driver 44, or that theprocessor 48 includes the functionality of thevirtual address translator 46. - Moreover, although the present invention is set forth in terms of directly addressable NOR flash RAM as the
storage device 12, it is to be appreciated that any other directlyaddressable storage device 12 may also be employed without departing from the spirit and scope of the present invention. For example, although most storage devices are not directly presently addressable, it may at some point be the case where a hard drive in fact is directly addressable. - The present invention may be practiced with regard to updating an
application 14 on most anycomputing device 10, regardless of the relative size of thestorage medium 12 thereof. As should now be appreciated, with the present invention as set forth herein, such updating is first simulated before being actually performed, and such actual performance takes place only if the simulation is deemed to have been successful. - The programming necessary to effectuate the processes performed in connection with the present invention is relatively straight-forward and should be apparent to the relevant programming public. Accordingly, such programming is not attached hereto. Any particular programming, then, may be employed to effectuate the present invention without departing from the spirit and scope thereof.
- In the foregoing description, it can be seen that the present invention comprises a new and useful method for updating an
application 14 such as afile system 16 on acomputing device 10, especially one with a relativelysmall storage device 12. The method ensures that the update will succeed or else does not allow the update to be performed. - The present invention also comprises a new and useful framework for the
file system 16 to organize files on thestorage device 12 on a per-chunk basis. The framework allows thefile system 12 to efficiently use the storage capacity of thestorage device 12 without undue waste. - The present invention further comprises a new and useful structure of a
file 28 that allows for efficient use of storage capacity of astorage device 12, especially when thefile 28 includesnull data 40 therein. Such structure allows thefile system 12 to efficiently use the storage capacity of thestorage device 12 without undue waste based on needless storage of such null data within thefile 28. - The present invention still further comprises a method and mechanism by which a
file 28 on thestorage device 12 of thecomputing device 10 can be executed almost immediately. The file is stored on thestorage device 12 and can be executed directly therefrom, even when thefile 12 is stored on thestorage device 12 in a fragmented manner. - It should be appreciated that changes could be made to the embodiments described above without departing from the inventive concepts thereof. In general then, it should be understood, therefore, that this invention is not limited to the particular embodiments disclosed, but it is intended to cover modifications within the spirit and scope of the present invention as defined by the appended claims.
Claims (20)
1. A computing device, comprising:
a storage device addressable on a per-byte basis and having configured thereon a non-contiguously stored executable file;
a file system configured to:
receive a command to execute the executable file,
determine that the executable file can be executed in place on the storage device,
obtain a virtual start address of the executable file, and
obtain a physical location and length of each fragment of the executable file; and
a virtual address translator configured to:
receive the virtual start address of the executable file from the file system,
receive the physical location and length of each fragment of the executable file from the file system, and
create a mapping of the physical location and length of each fragment of the executable file to a single contiguous virtual location starting at the virtual start address.
2. The computing device of claim 1 , wherein the executable file comprises the virtual start address.
3. The computing device of claim 1 , wherein the executable file comprises at least one virtual branch address.
4. The computing device of claim 1 , wherein the virtual address translator is further configured to provide the mapping to a processor.
5. The computing device of claim 1 , wherein the virtual address translator is further configured to locate data within the executable file and provide the data to a processor.
6. The computing device of claim 1 , wherein the file system determines that the executable file can be executed in place on the storage device by determining that the executable file is not compressed.
7. The computing device of claim 1 , wherein the file system determines that the executable file can be executed in place on the storage device by determining that the executable file comprises the virtual start address.
8. The computing device of claim 1 , wherein the file system determines that the executable file can be executed in place on the storage device by determining that the executable file comprises virtual branch addresses.
9. A method of executing a file on a storage device, comprising:
receiving, at a file system configured on a computing device, a command to execute an executable file, wherein the executable file is stored non-contiguously on the storage device, and wherein the storage device is addressable on a per-byte basis;
determining, at the file system, that the executable file can be executed in place on the storage device;
obtaining, at the file system, a virtual start address of the executable file;
obtaining, at the file system, a physical location and length of each fragment of the executable file;
receiving, at a virtual address translator configured on the computing device, the virtual start address of the executable file from the file system;
receiving, at the virtual address translator, the physical location and length of each fragment of the executable file from the file system; and
creating, at the virtual address translator, a mapping of the physical location and length of each fragment of the executable file to a single contiguous virtual location starting at the virtual start address.
10. The method of claim 9 , wherein the executable file comprises the virtual start address.
11. The method of claim 9 , wherein the executable file comprises at least one virtual branch address.
12. The method of claim 9 , further comprising providing the mapping to a processor.
13. The method of claim 9 , further comprising locating, by the virtual address translator, data within the executable file and providing the data to a processor.
14. The method of claim 9 , wherein determining that the executable file can be executed in place on the storage device comprises determining at least one of the executable file is not compressed, the executable file comprises the virtual start address, and the executable file comprises virtual branch addresses.
15. A computer-readable storage medium comprising computer-executable instructions for executing a file on a storage device, the computer-executable instructions comprising instructions for:
receiving a command to execute an executable file, wherein the executable file is stored non-contiguously on the storage device, and wherein the storage device is addressable on a per-byte basis;
determining that the executable file can be executed in place on the storage device;
obtaining a virtual start address of the executable file;
obtaining a physical location and length of each fragment of the executable file;
receiving the virtual start address of the executable file from the file system;
receiving the physical location and length of each fragment of the executable file from the file system; and
creating a mapping of the physical location and length of each fragment of the executable file to a single contiguous virtual location starting at the virtual start address.
16. The computer-readable storage medium of claim 15 , wherein the executable file comprises the virtual start address.
17. The computer-readable storage medium of claim 15 , wherein the executable file comprises at least one virtual branch address.
18. The computer-readable storage medium of claim 15 , further comprising instructions for providing the mapping to a processor.
19. The computer-readable storage medium of claim 15 , further comprising instructions for locating, by the virtual address translator, data within the executable file and providing the data to a processor.
20. The computer-readable storage medium of claim 15 , wherein instructions for determining that the executable file can be executed in place on the storage device comprise instructions for determining at least one of the executable file is not compressed, the executable file comprises the virtual start address, and the executable file comprises virtual branch addresses.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/685,251 US20100115006A1 (en) | 2004-03-22 | 2010-01-11 | Computing device with relatively limited storage space and operating/file system thereof |
Applications Claiming Priority (6)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US55539204P | 2004-03-22 | 2004-03-22 | |
US55515504P | 2004-03-22 | 2004-03-22 | |
US55510404P | 2004-03-22 | 2004-03-22 | |
US55510204P | 2004-03-22 | 2004-03-22 | |
US11/000,693 US7647358B2 (en) | 2004-03-22 | 2004-12-01 | Computing device with relatively limited storage space and operating/file system thereof |
US12/685,251 US20100115006A1 (en) | 2004-03-22 | 2010-01-11 | Computing device with relatively limited storage space and operating/file system thereof |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/000,693 Continuation US7647358B2 (en) | 2004-03-22 | 2004-12-01 | Computing device with relatively limited storage space and operating/file system thereof |
Publications (1)
Publication Number | Publication Date |
---|---|
US20100115006A1 true US20100115006A1 (en) | 2010-05-06 |
Family
ID=34987615
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/000,693 Expired - Fee Related US7647358B2 (en) | 2004-03-22 | 2004-12-01 | Computing device with relatively limited storage space and operating/file system thereof |
US12/685,251 Abandoned US20100115006A1 (en) | 2004-03-22 | 2010-01-11 | Computing device with relatively limited storage space and operating/file system thereof |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/000,693 Expired - Fee Related US7647358B2 (en) | 2004-03-22 | 2004-12-01 | Computing device with relatively limited storage space and operating/file system thereof |
Country Status (1)
Country | Link |
---|---|
US (2) | US7647358B2 (en) |
Families Citing this family (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8069192B2 (en) * | 2004-03-22 | 2011-11-29 | Microsoft Corporation | Computing device with relatively limited storage space and operating / file system thereof |
US7647358B2 (en) * | 2004-03-22 | 2010-01-12 | Microsoft Corporation | Computing device with relatively limited storage space and operating/file system thereof |
EP1591916B1 (en) * | 2004-04-26 | 2013-11-06 | Sap Ag | Method, computer program and device for deleting data sets contained in a table system |
US8819011B2 (en) * | 2008-07-16 | 2014-08-26 | Cleversafe, Inc. | Command line interpreter for accessing a data object stored in a distributed storage network |
US8117343B2 (en) * | 2008-10-28 | 2012-02-14 | Hewlett-Packard Development Company, L.P. | Landmark chunking of landmarkless regions |
US8001273B2 (en) * | 2009-03-16 | 2011-08-16 | Hewlett-Packard Development Company, L.P. | Parallel processing of input data to locate landmarks for chunks |
US9442671B1 (en) * | 2010-12-23 | 2016-09-13 | Emc Corporation | Distributed consumer cloud storage system |
US9203625B2 (en) * | 2011-11-28 | 2015-12-01 | Cleversafe, Inc. | Transferring encoded data slices in a distributed storage network |
JP5687639B2 (en) * | 2012-02-08 | 2015-03-18 | 株式会社東芝 | Controller, data storage device and program |
JP6457249B2 (en) * | 2014-11-18 | 2019-01-23 | ウイングアーク1st株式会社 | Electronic document management apparatus, electronic document management system, and electronic document management program |
US9996463B2 (en) * | 2015-11-10 | 2018-06-12 | International Business Machines Corporation | Selection and placement of volumes in a storage system using stripes |
US10078468B2 (en) | 2016-08-18 | 2018-09-18 | International Business Machines Corporation | Slice migration in a dispersed storage network |
CN113360095B (en) * | 2021-06-04 | 2023-02-17 | 重庆紫光华山智安科技有限公司 | Hard disk data management method, device, equipment and medium |
CN113434438B (en) * | 2021-06-15 | 2023-03-14 | 武汉天喻信息产业股份有限公司 | Method for prolonging FLASH write-in life of smart card |
Citations (46)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5193184A (en) * | 1990-06-18 | 1993-03-09 | Storage Technology Corporation | Deleted data file space release system for a dynamically mapped virtual data storage subsystem |
US5530850A (en) * | 1993-10-25 | 1996-06-25 | International Business Machines Corporation | Data storage library array with log-structured file system which allows simultaneous write and garbage collection |
US5581768A (en) * | 1995-02-27 | 1996-12-03 | Intel Corporation | Method and apparatus for executing applications in place from write once/seldom memories |
US5655146A (en) * | 1994-02-18 | 1997-08-05 | International Business Machines Corporation | Coexecution processor isolation using an isolation process or having authority controls for accessing system main storage |
US5754817A (en) * | 1994-09-29 | 1998-05-19 | Intel Corporation | Execution in place of a file stored non-contiguously in a non-volatile memory |
US5787493A (en) * | 1992-09-25 | 1998-07-28 | International Business Machines Corporation | Control method and apparatus for direct execution of a program on an external apparatus using a randomly accessible and rewritable memory |
US5819298A (en) * | 1996-06-24 | 1998-10-06 | Sun Microsystems, Inc. | File allocation tables with holes |
US5909540A (en) * | 1996-11-22 | 1999-06-01 | Mangosoft Corporation | System and method for providing highly available data storage using globally addressable memory |
US6032160A (en) * | 1995-02-10 | 2000-02-29 | International Business Machines Corporation | Buddy system space allocation management |
US6101590A (en) * | 1995-10-10 | 2000-08-08 | Micro Unity Systems Engineering, Inc. | Virtual memory system with local and global virtual address translation |
US6112210A (en) * | 1997-10-31 | 2000-08-29 | Oracle Corporation | Apparatus and method for null representation in database object storage |
US6151602A (en) * | 1997-11-07 | 2000-11-21 | Inprise Corporation | Database system with methods providing a platform-independent self-describing data packet for transmitting information |
US6212613B1 (en) * | 1999-03-22 | 2001-04-03 | Cisco Technology, Inc. | Methods and apparatus for reusing addresses in a computer |
US6304867B1 (en) * | 1999-02-25 | 2001-10-16 | Electronic Data Systems Corporation | System and method for enhanced performance of a relational database management system through the use of application-specific memory-resident data |
US6467021B1 (en) * | 1996-04-02 | 2002-10-15 | Memquest, Inc. | Data storage system storing data of varying block size |
US6574721B1 (en) * | 1999-08-31 | 2003-06-03 | International Business Machines Corporation | Apparatus and method for providing simultaneous local and global addressing using software to distinguish between local and global addresses |
US20030110263A1 (en) * | 2001-12-10 | 2003-06-12 | Avraham Shillo | Managing storage resources attached to a data network |
US20030115219A1 (en) * | 2001-12-19 | 2003-06-19 | International Business Machines Corporation | Method, system, and program for storing data in a data store |
US20030140210A1 (en) * | 2001-12-10 | 2003-07-24 | Richard Testardi | Dynamic and variable length extents |
US20030149815A1 (en) * | 1999-12-22 | 2003-08-07 | Seagate Technology Llc | Buffer management system for managing the transfer of data into and out of a buffer in a disc drive |
US20030182543A1 (en) * | 1999-10-14 | 2003-09-25 | James B. Keller | Training line predictor for branch targets |
US20030198145A1 (en) * | 1997-10-21 | 2003-10-23 | Sony Corporation | Recording and/or reproduction apparatus, file management method and providing medium |
US6658437B1 (en) * | 2000-06-05 | 2003-12-02 | International Business Machines Corporation | System and method for data space allocation using optimized bit representation |
US6697846B1 (en) * | 1998-03-20 | 2004-02-24 | Dataplow, Inc. | Shared file system |
US20040044708A1 (en) * | 2002-08-27 | 2004-03-04 | Linke Scott L. | Executable file system for an embedded computer |
US6732124B1 (en) * | 1999-03-30 | 2004-05-04 | Fujitsu Limited | Data processing system with mechanism for restoring file systems based on transaction logs |
US6730667B2 (en) * | 2001-11-26 | 2004-05-04 | William R. Deagle | Iontophoresis disc pain blocker |
US20040107217A1 (en) * | 1991-06-21 | 2004-06-03 | Reed Hastings | Method and apparatus for modifying relocatable object code files and monitoring programs |
US20040167916A1 (en) * | 1998-01-26 | 2004-08-26 | At&T Corp. | System and method of organizing data to facilitate access and streaming |
US20040230573A1 (en) * | 2000-04-12 | 2004-11-18 | Rhoads Edward R. | Accessing file data stored in non-volatile re-programmable semiconductor memories |
US20040243643A1 (en) * | 2003-05-29 | 2004-12-02 | Glen Hattrup | Method and apparatus for managing autonomous third party data transfers |
US20050015378A1 (en) * | 2001-06-05 | 2005-01-20 | Berndt Gammel | Device and method for determining a physical address from a virtual address, using a hierarchical mapping rule comprising compressed nodes |
US20050071838A1 (en) * | 2003-09-30 | 2005-03-31 | Keisuke Hatasaki | System-updating method and computer system adopting the method |
US20050132161A1 (en) * | 2003-12-15 | 2005-06-16 | Nokia Corporation | Creation of virtual memory space in a memory |
US20050132179A1 (en) * | 2003-12-16 | 2005-06-16 | Microsoft Corporation | Applying custom software image updates to non-volatile storage in a failsafe manner |
US20050209991A1 (en) * | 2004-03-22 | 2005-09-22 | Microsoft Corporation | Computing device with relatively limited storage space and operating / file system thereof |
US6988163B2 (en) * | 2002-10-21 | 2006-01-17 | Microsoft Corporation | Executing binary images from non-linear storage systems |
US20060015528A1 (en) * | 2004-07-14 | 2006-01-19 | Microsoft Corporation | Generic representation of optional values |
US7020664B1 (en) * | 1999-11-30 | 2006-03-28 | Matsushita Electric Industrial Co., Ltd. | File management apparatus and method |
US7089354B2 (en) * | 2003-07-30 | 2006-08-08 | International Business Machines Corporation | Disk fragmentation test system |
US7184424B2 (en) * | 2002-11-12 | 2007-02-27 | Zetera Corporation | Multiplexing storage element interface |
US7206915B2 (en) * | 2004-06-03 | 2007-04-17 | Emc Corp | Virtual space manager for computer having a physical address extension feature |
US7257675B2 (en) * | 2003-10-21 | 2007-08-14 | Nec Corporation | Disk array device having snapshot simulation function |
US20090038011A1 (en) * | 2004-10-26 | 2009-02-05 | Rudra Technologies Pte Ltd. | System and method of identifying and removing malware on a computer system |
US7506131B2 (en) * | 2002-07-31 | 2009-03-17 | Texas Instruments Incorporated | Reformat logic to translate between a virtual address and a compressed physical address |
US7647358B2 (en) * | 2004-03-22 | 2010-01-12 | Microsoft Corporation | Computing device with relatively limited storage space and operating/file system thereof |
-
2004
- 2004-12-01 US US11/000,693 patent/US7647358B2/en not_active Expired - Fee Related
-
2010
- 2010-01-11 US US12/685,251 patent/US20100115006A1/en not_active Abandoned
Patent Citations (46)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5193184A (en) * | 1990-06-18 | 1993-03-09 | Storage Technology Corporation | Deleted data file space release system for a dynamically mapped virtual data storage subsystem |
US20040107217A1 (en) * | 1991-06-21 | 2004-06-03 | Reed Hastings | Method and apparatus for modifying relocatable object code files and monitoring programs |
US5787493A (en) * | 1992-09-25 | 1998-07-28 | International Business Machines Corporation | Control method and apparatus for direct execution of a program on an external apparatus using a randomly accessible and rewritable memory |
US5530850A (en) * | 1993-10-25 | 1996-06-25 | International Business Machines Corporation | Data storage library array with log-structured file system which allows simultaneous write and garbage collection |
US5655146A (en) * | 1994-02-18 | 1997-08-05 | International Business Machines Corporation | Coexecution processor isolation using an isolation process or having authority controls for accessing system main storage |
US5754817A (en) * | 1994-09-29 | 1998-05-19 | Intel Corporation | Execution in place of a file stored non-contiguously in a non-volatile memory |
US6032160A (en) * | 1995-02-10 | 2000-02-29 | International Business Machines Corporation | Buddy system space allocation management |
US5581768A (en) * | 1995-02-27 | 1996-12-03 | Intel Corporation | Method and apparatus for executing applications in place from write once/seldom memories |
US6101590A (en) * | 1995-10-10 | 2000-08-08 | Micro Unity Systems Engineering, Inc. | Virtual memory system with local and global virtual address translation |
US6467021B1 (en) * | 1996-04-02 | 2002-10-15 | Memquest, Inc. | Data storage system storing data of varying block size |
US5819298A (en) * | 1996-06-24 | 1998-10-06 | Sun Microsystems, Inc. | File allocation tables with holes |
US5909540A (en) * | 1996-11-22 | 1999-06-01 | Mangosoft Corporation | System and method for providing highly available data storage using globally addressable memory |
US20030198145A1 (en) * | 1997-10-21 | 2003-10-23 | Sony Corporation | Recording and/or reproduction apparatus, file management method and providing medium |
US6112210A (en) * | 1997-10-31 | 2000-08-29 | Oracle Corporation | Apparatus and method for null representation in database object storage |
US6151602A (en) * | 1997-11-07 | 2000-11-21 | Inprise Corporation | Database system with methods providing a platform-independent self-describing data packet for transmitting information |
US20040167916A1 (en) * | 1998-01-26 | 2004-08-26 | At&T Corp. | System and method of organizing data to facilitate access and streaming |
US6697846B1 (en) * | 1998-03-20 | 2004-02-24 | Dataplow, Inc. | Shared file system |
US6304867B1 (en) * | 1999-02-25 | 2001-10-16 | Electronic Data Systems Corporation | System and method for enhanced performance of a relational database management system through the use of application-specific memory-resident data |
US6212613B1 (en) * | 1999-03-22 | 2001-04-03 | Cisco Technology, Inc. | Methods and apparatus for reusing addresses in a computer |
US6732124B1 (en) * | 1999-03-30 | 2004-05-04 | Fujitsu Limited | Data processing system with mechanism for restoring file systems based on transaction logs |
US6574721B1 (en) * | 1999-08-31 | 2003-06-03 | International Business Machines Corporation | Apparatus and method for providing simultaneous local and global addressing using software to distinguish between local and global addresses |
US20030182543A1 (en) * | 1999-10-14 | 2003-09-25 | James B. Keller | Training line predictor for branch targets |
US7020664B1 (en) * | 1999-11-30 | 2006-03-28 | Matsushita Electric Industrial Co., Ltd. | File management apparatus and method |
US20030149815A1 (en) * | 1999-12-22 | 2003-08-07 | Seagate Technology Llc | Buffer management system for managing the transfer of data into and out of a buffer in a disc drive |
US20040230573A1 (en) * | 2000-04-12 | 2004-11-18 | Rhoads Edward R. | Accessing file data stored in non-volatile re-programmable semiconductor memories |
US6658437B1 (en) * | 2000-06-05 | 2003-12-02 | International Business Machines Corporation | System and method for data space allocation using optimized bit representation |
US20050015378A1 (en) * | 2001-06-05 | 2005-01-20 | Berndt Gammel | Device and method for determining a physical address from a virtual address, using a hierarchical mapping rule comprising compressed nodes |
US6730667B2 (en) * | 2001-11-26 | 2004-05-04 | William R. Deagle | Iontophoresis disc pain blocker |
US20030140210A1 (en) * | 2001-12-10 | 2003-07-24 | Richard Testardi | Dynamic and variable length extents |
US20030110263A1 (en) * | 2001-12-10 | 2003-06-12 | Avraham Shillo | Managing storage resources attached to a data network |
US20030115219A1 (en) * | 2001-12-19 | 2003-06-19 | International Business Machines Corporation | Method, system, and program for storing data in a data store |
US7506131B2 (en) * | 2002-07-31 | 2009-03-17 | Texas Instruments Incorporated | Reformat logic to translate between a virtual address and a compressed physical address |
US20040044708A1 (en) * | 2002-08-27 | 2004-03-04 | Linke Scott L. | Executable file system for an embedded computer |
US6988163B2 (en) * | 2002-10-21 | 2006-01-17 | Microsoft Corporation | Executing binary images from non-linear storage systems |
US7184424B2 (en) * | 2002-11-12 | 2007-02-27 | Zetera Corporation | Multiplexing storage element interface |
US20040243643A1 (en) * | 2003-05-29 | 2004-12-02 | Glen Hattrup | Method and apparatus for managing autonomous third party data transfers |
US7089354B2 (en) * | 2003-07-30 | 2006-08-08 | International Business Machines Corporation | Disk fragmentation test system |
US20050071838A1 (en) * | 2003-09-30 | 2005-03-31 | Keisuke Hatasaki | System-updating method and computer system adopting the method |
US7257675B2 (en) * | 2003-10-21 | 2007-08-14 | Nec Corporation | Disk array device having snapshot simulation function |
US20050132161A1 (en) * | 2003-12-15 | 2005-06-16 | Nokia Corporation | Creation of virtual memory space in a memory |
US20050132179A1 (en) * | 2003-12-16 | 2005-06-16 | Microsoft Corporation | Applying custom software image updates to non-volatile storage in a failsafe manner |
US20050209991A1 (en) * | 2004-03-22 | 2005-09-22 | Microsoft Corporation | Computing device with relatively limited storage space and operating / file system thereof |
US7647358B2 (en) * | 2004-03-22 | 2010-01-12 | Microsoft Corporation | Computing device with relatively limited storage space and operating/file system thereof |
US7206915B2 (en) * | 2004-06-03 | 2007-04-17 | Emc Corp | Virtual space manager for computer having a physical address extension feature |
US20060015528A1 (en) * | 2004-07-14 | 2006-01-19 | Microsoft Corporation | Generic representation of optional values |
US20090038011A1 (en) * | 2004-10-26 | 2009-02-05 | Rudra Technologies Pte Ltd. | System and method of identifying and removing malware on a computer system |
Also Published As
Publication number | Publication date |
---|---|
US7647358B2 (en) | 2010-01-12 |
US20050210076A1 (en) | 2005-09-22 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP1580664B1 (en) | Computing device with relatively limited storage space and operating / file system thereof | |
US20100115006A1 (en) | Computing device with relatively limited storage space and operating/file system thereof | |
US7698699B2 (en) | Computing device with relatively limited storage space and operating/file system thereof | |
US7496586B1 (en) | Method and apparatus for compressing data in a file system | |
US8892846B2 (en) | Metadata management for virtual volumes | |
US8549051B2 (en) | Unlimited file system snapshots and clones | |
US7415653B1 (en) | Method and apparatus for vectored block-level checksum for file system data integrity | |
US8051050B2 (en) | Block-level data de-duplication using thinly provisioned data storage volumes | |
US20120005163A1 (en) | Block-based incremental backup | |
US7877554B2 (en) | Method and system for block reallocation | |
US7783847B2 (en) | Method and system for reallocating blocks in a storage pool | |
US7970804B2 (en) | Journaling FAT file system and accessing method thereof | |
KR20130066639A (en) | Mount-time reconciliation of data availability | |
US7899989B2 (en) | Method and system for using a block allocation policy | |
US8495010B2 (en) | Method and system for adaptive metadata replication | |
US20070106868A1 (en) | Method and system for latency-directed block allocation | |
US7499929B2 (en) | Computing device with relatively limited storage space and operating/file system thereof | |
US7526622B1 (en) | Method and system for detecting and correcting data errors using checksums and replication | |
US7480684B2 (en) | Method and system for object allocation using fill counts | |
US7424574B1 (en) | Method and apparatus for dynamic striping | |
US7281188B1 (en) | Method and system for detecting and correcting data errors using data permutations | |
US7533225B1 (en) | Method and apparatus for enabling adaptive endianness | |
US7603568B1 (en) | Method and apparatus for self-validating checksums in a file system | |
US7925827B2 (en) | Method and system for dirty time logging | |
US20220164135A1 (en) | Apparatus, method and computer program for managing memory page updates within non-volatile memory |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: EXPRESSLY ABANDONED -- DURING EXAMINATION |
|
AS | Assignment |
Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC, WASHINGTON Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MICROSOFT CORPORATION;REEL/FRAME:034766/0001 Effective date: 20141014 |