U.S. patent number 8,001,165 [Application Number 12/774,752] was granted by the patent office on 2011-08-16 for storage system format for transaction safe file system.
This patent grant is currently assigned to Microsoft Corporation. Invention is credited to Yadhu Gopalan, Sachin Patel, Andrew Rogers.
United States Patent |
8,001,165 |
Patel , et al. |
August 16, 2011 |
**Please see images for:
( Certificate of Correction ) ** |
Storage system format for transaction safe file system
Abstract
A transaction safe file system uses two sets of file allocation
tables and bitmap images to perform file modifications on one of
the sets while the other set remains a last known good set. After a
modification is complete, a pointer is changed to the newly
modified set, and the newly modified set becomes the last known
good set. The sets are then synchronized. The file allocation table
is used to define cluster chains while the bitmap image is used to
determine if a cluster is free or not. In some operations, only the
bitmap image may need to be manipulated. The file system may be
used in a transaction safe mode as well as a non-transaction safe
mode.
Inventors: |
Patel; Sachin (Bellevue,
WA), Gopalan; Yadhu (Redmond, WA), Rogers; Andrew
(Bellevue, WA) |
Assignee: |
Microsoft Corporation (Redmond,
WA)
|
Family
ID: |
39618583 |
Appl.
No.: |
12/774,752 |
Filed: |
May 6, 2010 |
Prior Publication Data
|
|
|
|
Document
Identifier |
Publication Date |
|
US 20100217788 A1 |
Aug 26, 2010 |
|
Related U.S. Patent Documents
|
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
Issue Date |
|
|
11653588 |
Jan 16, 2007 |
7747664 |
|
|
|
Current U.S.
Class: |
707/826; 707/648;
707/610; 707/682 |
Current CPC
Class: |
G06F
11/1435 (20130101) |
Current International
Class: |
G06F
17/30 (20060101); G06F 12/00 (20060101) |
References Cited
[Referenced By]
U.S. Patent Documents
Other References
Microsoft Press Computer Dictionary Third Edition, "fragmentation",
Microsoft Press, 1997, p. 206. cited by other .
Microsoft Press Computer Dictionary Third Edition, "flush",
Microsoft Press, 1997, p. 202. cited by other .
Jonge, "The Logical Disk: A New Approach to Improving File
Systems", In Proceedings of the 14th ACM Symposium on Operating
Systems Principles, 1993, 14 pages. cited by other .
Farr et al., "An Optimum Disc Organization for a Virtual Memory
System", Computer Design, Jun. 1971, pp. 49-54. cited by other
.
Lee, Chiung-San, "Server-Based Maintenance Approach for Computer
Classroom Workstations", IEICE Trans. Inf. & Syst., vol. E83-D,
No. 4, Apr. 2000, pp. 807-815. cited by other .
"Transactional file access", Date: Jun. 2, 2005,
http://jakarta.apache.org/commons/transaction/file/index.html, 1
page. cited by other .
"ZFS, Sun's Cutting-Edge File System (Part 1: Storage Integrity,
Security, and Scalability)", Date: Aug. 2006, http://
www.sun.com/bigadmin/features/articles/zfs.sub.--part1.scalable.html#tran-
saction, 8 pages. cited by other .
Chen, et al., "The Rio File Cache: Surviving Operating System
Crashes",
http://www.cs.ucsd.edu/classes/wi01/cse221/chen,ng,rajamani,aycock.the.su-
b.--rio-file.sub.--cache.surviving.sub.--operating.sub.--system.sub.--cras-
hes.pdf, 11 pages. cited by other .
Kashyap,Aditya, "File System Extensibility and Reliability Using an
in-Kernal Database", Date: Dec. 2004,
http://www.am-utils.org/docs/kbdbfs-msthesis/index.html, 30 pages.
cited by other .
Barreto et al., "A Highly Available Replicated File System for
Resource-Constrained Windows CE .Net Devices", in 3rd International
Conference on .NET Technologies, 2005, 6 pages. cited by other
.
"Transaction-Safe FAT File System",
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcemain4-
/html/cmcontransaction-safefatfilesystem.asp, last updated May 30,
2006, 1 page. cited by other .
Otoo et al., "Non-shared disk cluster--a fault tolerant, commodity
approach to hi-bandwidth data analysis", 2001, available at
http://www.ihep.ac.cn/-chep01/paper/4-026.pdf, 7 pages. cited by
other .
Sivathanu et al., "Life or Death at Block-Level", In Proceedings of
the 6th Symposium on Operating Systems Design and Implementation
(OSDI '04), Dec. 2004, 17 pages. cited by other.
|
Primary Examiner: Robinson; Greta L
Assistant Examiner: Wilcox; James J
Parent Case Text
CROSS-REFERENCE TO RELATED APPLICATIONS
This application claims priority to and is a continuation of U.S.
patent application Ser. No. 11/653,588, now U.S. Pat. No. 7,747,664
B2, entitled "Storage System Format for Transaction Safe File
System" and filed Jan. 16, 2007, which is incorporated herein by
reference.
Claims
What is claimed is:
1. A method comprising: indicating a first bitmap image associated
with a file allocation table of a file system as a last known good
bitmap image, the file allocation table defining storage segments
allocated to a file in the file system, the first bitmap image
adapted to store an allocation bit for each storage segment
allocated to the file in the file system; synchronizing a second
bitmap image to the first bitmap image resulting in the second
bitmap image and the first bitmap image identically indicating each
storage segment allocated to the file in the file system, wherein
the second bitmap image is to be modified and the first bitmap
image is to remain unchanged when an operation to change the file
system is performed; performing an operation to change a portion of
the file system, the operation comprising deleting the file in the
file system, wherein deleting the file in the file system does not
require a change to the file allocation table of the file system;
modifying the second bitmap image to indicate that each storage
segment allocated to the file in the file system is free for
overwriting as result of deleting the file in the file system;
after the operation is completed, indicating that the second bitmap
image is the last known good bitmap image; and synchronizing the
first bitmap image to the second bitmap.
2. The method of claim 1, wherein the allocation bit for a
particular storage segment identifies whether the particular
storage segment is free or not.
3. The method of claim 1, wherein indicating the first bitmap image
as the last known good bitmap image comprises an atomic change of a
single flag.
4. The method of claim 1, wherein indicating the first bitmap image
as the last known good bitmap image comprises toggling an indicium
to the first bitmap image.
5. The method of claim 1, wherein a contiguous indicium is
associated with the file, the contiguous indicates indicating when
the storage segments allocated to the file in the file system are
contiguous.
6. The method of claim 1, further comprising performing a
non-transaction safe change to a portion of the file system in a
non-transaction safe mode.
7. The method of claim 1, further comprising performing a
transaction safe change to a portion of the file system in a
transaction safe mode.
8. The method of claim 1, wherein each storage segment allocated to
the file is a cluster of the file system.
9. A computer-readable storage medium comprising computer
executable instructions encoded thereon that perform acts
comprising: indicating a first bitmap image associated with a file
allocation table of a file system as a last known good bitmap
image, the file allocation table of the file system defining
clusters allocated to a file in the file system, the first bitmap
image to indicate usage of each cluster allocated to the file in
the file system; synchronizing a second bitmap image to the first
bitmap image resulting in the second bitmap image and the first
bitmap image identically indicating the usage of each cluster
allocated to the file in the file system, wherein the second bitmap
image is to be modified and the first bitmap image is to remain
unchanged when an operation to change the file system is performed;
performing an operation that comprises deleting the file in the
file system, wherein deleting the file in the file system does not
require a change to the file allocation table of the file system;
modifying the second bitmap image to indicate that each cluster
allocated to the file in the file system is free for overwriting as
result of deleting the file in the file system; after the operation
is completed, indicating that the second bitmap image is the last
known good bitmap image; and synchronizing the first bitmap image
to the second bitmap.
10. The computer-readable storage medium of claim 9, wherein the
first bitmap image stores an allocation bit for each cluster
allocated to the file in the file system, the allocation bit for a
particular cluster identifying whether the particular cluster is
free or not.
11. The computer-readable storage medium of claim 9, wherein
indicating the first bitmap image as the last known good bitmap
image comprises an atomic change of a single flag.
12. The computer-readable storage medium of claim 9, wherein
indicating the first bitmap image as the last known good bitmap
image comprises toggling an indicium to the first bitmap image.
13. The computer-readable storage medium of claim 9, wherein
modifying the second bitmap image comprises changing one or more
allocation bits associated with the clusters allocated to the file
in the file system to indicate that each cluster is free.
14. The computer-readable storage medium of claim 9, further
comprising performing a non-transaction safe change to a portion of
the file system in a non-transaction safe mode.
15. The computer-readable storage medium of claim 1, further
comprising performing a transaction safe change to a portion of the
file system in a transaction safe mode.
16. The computer-readable storage medium of claim 1, wherein a
contiguous bit is associated with the file, the contiguous bit
indicating when the clusters allocated to the file are
contiguous.
17. A computing device, comprising: a data storage device having a
file system, the file system comprising: a first bitmap image
associated with a file allocation table of a file system and
indicated to be a last known good bitmap image, the file allocation
table of the file system defining clusters allocated to a file in
the file system, the first bitmap image to indicate whether each
cluster allocated to the file in the file system is used or unused;
a second bitmap image being a synchronized copy of the first bitmap
image to identically indicate whether each cluster allocated to the
file in the file system is used or unused, wherein the second
bitmap image is to be modified and the first bitmap image is to
remain unchanged when an operation to change the file system is
performed; a processor adapted to: perform an operation that
comprises deleting the file in the file system, wherein deleting
the file in the file system does not require change to the file
allocation table of the file system; modify the second bitmap image
to indicate that each cluster allocated to the file in the file
system is free for overwriting as a result of deletion of the file
in the file system; after the operation is completed, indicate that
the second bitmap image is the last known good bitmap image; and
synchronize the first bitmap image to the second bitmap.
18. The computing device of claim 17, wherein the first bitmap
image and the second bitmap image each comprise an allocation bit
corresponding to each cluster allocated to the file in the file
system, a state of each allocation bit indicating whether a
corresponding cluster is free or not.
19. The computing device of claim 17, wherein modifying the second
bitmap image comprises changing one or more allocation bits
associated with the clusters allocated to the file in the file
system to indicate that each is free.
20. The computing device of claim 17, wherein a contiguous bit is
associated with the file, the contiguous bit indicating when the
clusters allocated to the file are contiguous.
Description
BACKGROUND
Data on storage systems such as disk drives, flash memory, and
other data storage devices are often arranged in a file system. The
file system enables easy access to data on the storage system by
organizing the data into files and defining the location of the
files on the storage system. In some such systems, the files may be
arranged in a hierarchical fashion using directories and
subdirectories. The data contained in the files may be any type of
storable information in any type of format.
Many file systems use a file allocation table otherwise known as
FAT. The FAT may be used differently in various applications. In
some applications, a FAT may be used to link various clusters of
data together into a file that is comprised of several such
clusters.
As file systems have become more and more complex, some operations
performed on the file system may take several steps. The file
system may be vulnerable to corruption if a power disruption or
other interruption occurs during such steps and before they are
complete.
SUMMARY
A transaction safe file system uses two sets of file allocation
tables and bitmap images to perform file modifications on one of
the sets while the other set remains a last known good set. After a
modification is complete, a pointer is changed to the newly
modified set, and the newly modified set becomes the last known
good set. The sets are then synchronized. The file allocation table
is used to define cluster chains while the bitmap image is used to
determine if a cluster is free or not. In some operations, only the
bitmap image may need to be manipulated. The file system may be
used in a transaction safe mode as well as a non-transaction safe
mode.
This Summary is provided to introduce a selection of concepts in a
simplified form that are further described below in the Detailed
Description. This Summary is not intended to identify key features
or essential features of the claimed subject matter, nor is it
intended to be used to limit the scope of the claimed subject
matter.
BRIEF DESCRIPTION OF THE DRAWINGS
In the drawings,
FIG. 1 is a flowchart illustration of an embodiment showing a
method for transaction-safe file modification.
FIG. 2 is a diagram illustration of an embodiment showing a system
for using a file system.
FIG. 3 is a diagram illustration of an embodiment showing a file
system configuration.
FIG. 4 is a timeline diagram of an embodiment showing a process for
deleting a file.
FIG. 5 is a timeline diagram of an embodiment showing a process for
modifying a file.
FIG. 6 is a flowchart illustration of an embodiment showing a
method for transaction-safe file replacement.
DETAILED DESCRIPTION
In order to perform transaction safe modifications to a file
system, one set of file allocation tables and bitmap images are
modified while another set is kept as a last known good set. Once a
modification is complete, a flag is set to indicate that the
modified set is now the last known good set. If a power outage or
other disruption occurs while the modification is in progress but
before the flag is set, the changes will be lost but the file
system will be intact because the last known good set of file
allocation tables and bitmap images will be current.
In some operations, a modification to the data may require a change
to the bitmap image and not the file allocation table. An example
of such an operation is the deletion of a file.
The transaction safe modification occurs by performing the steps
required to make the modification, with the last step being an
atomic change of a single flag. Such a system may be useful in any
application where power failure may be problematic. For example,
removable storage media in a consumer product such as a data
storage card in a camera, video recorder, or other product may be
subject to instantaneous disconnection by a user during read,
write, or other modification action.
Specific embodiments of the subject matter are used to illustrate
specific inventive aspects. The embodiments are by way of example
only, and are susceptible to various modifications and alternative
forms. The appended claims are intended to cover all modifications,
equivalents, and alternatives falling within the spirit and scope
of the invention as defined by the claims.
Throughout this specification, like reference numbers signify the
same elements throughout the description of the figures.
When elements are referred to as being "connected" or "coupled,"
the elements can be directly connected or coupled together or one
or more intervening elements may also be present. In contrast, when
elements are referred to as being "directly connected" or "directly
coupled," there are no intervening elements present.
The subject matter may be embodied as devices, systems, methods,
and/or computer program products. Accordingly, some or all of the
subject matter may be embodied in hardware and/or in software
(including firmware, resident software, micro-code, state machines,
gate arrays, etc.) Furthermore, the subject matter may take the
form of a computer program product on a computer-usable or
computer-readable storage medium having computer-usable or
computer-readable program code embodied in the medium for use by or
in connection with an instruction execution system. In the context
of this document, a computer-usable or computer-readable medium may
be any medium that can contain, store, communicate, propagate, or
transport the program for use by or in connection with the
instruction execution system, apparatus, or device.
The computer-usable or computer-readable medium may be, for example
but not limited to, an electronic, magnetic, optical,
electromagnetic, infrared, or semiconductor system, apparatus,
device, or propagation medium. By way of example, and not
limitation, computer readable media may comprise computer storage
media and communication media.
Computer storage media includes volatile and nonvolatile, removable
and non-removable media implemented in any method or technology for
storage of information such as computer readable instructions, data
structures, program modules or other data. Computer storage media
includes, but is not limited to, RAM, ROM, EEPROM, flash memory or
other memory technology, CD-ROM, digital versatile disks (DVD) or
other optical storage, magnetic cassettes, magnetic tape, magnetic
disk storage or other magnetic storage devices, or any other medium
which can be used to store the desired information and which can
accessed by an instruction execution system. Note that the
computer-usable or computer-readable medium could be paper or
another suitable medium upon which the program is printed, as the
program can be electronically captured, via, for instance, optical
scanning of the paper or other medium, then compiled, interpreted,
of otherwise processed in a suitable manner, if necessary, and then
stored in a computer memory.
Communication media typically embodies computer readable
instructions, data structures, program modules or other data in a
modulated data signal such as a carrier wave or other transport
mechanism and includes any information delivery media. The term
"modulated data signal" means a signal that has one or more of its
characteristics set or changed in such a manner as to encode
information in the signal. By way of example, and not limitation,
communication media includes wired media such as a wired network or
direct-wired connection, and wireless media such as acoustic, RF,
infrared and other wireless media. Combinations of the any of the
above should also be included within the scope of computer readable
media.
When the subject matter is embodied in the general context of
computer-executable instructions, the embodiment may comprise
program modules, executed by one or more systems, computers, or
other devices. Generally, program modules include routines,
programs, objects, components, data structures, etc. that perform
particular tasks or implement particular abstract data types.
Typically, the functionality of the program modules may be combined
or distributed as desired in various embodiments.
FIG. 1 is a diagram of an embodiment 100 showing a method for a
transaction-safe file modification. In block 102, a boot sector
pointer is set to the last known good file allocation table (`FAT`)
and bitmap image of cluster usage. An out of date FAT is updated to
the last known good FAT in block 104. Similarly, the last known
good bitmap image is used to update an out of date bitmap image in
block 106. Changes to the file system are begun in block 108. If
the change is not complete in block 110, the process returns to
block 108 and further changes are made. If the changes are complete
in block 110, the boot sector pointer is flipped to indicate that
the changed FAT and bitmap images are now the last known good
versions. The process continues in block 104.
Embodiment 100 is a method by which transaction-safe file
modifications may be performed and then completed by toggling a
pointer to the updated FAT and bitmap images. The toggling
operation in block 120 may be an atomic operation that commits the
entire transaction. Prior to toggling the boot sector pointer in
block 120, the file system may be operational in the last known
good state.
When a modification is performed to the file system, the changes
may be made to areas of the file system that are open. For example,
a new file may be added by writing to clusters that are unused and
by referencing those clusters in the modified FAT and bitmap image.
After all of the changes that relate to the modification, such as
writing the new clusters on the storage media, changing the FAT,
modifying the bitmap image, updating directories, etc, the change
is made complete by toggling the boot sector flag that points to
the newly modified FAT and bitmap.
In some embodiments, the FAT and bitmap structure used to describe
a file system may be used in a non-transaction safe manner. For
example, an application or operating system that references a file
system in a non-transaction safe manner may update a single set of
FAT and bitmap image, while a transaction safe application or
operating system may read and write the same data storage system
but use two sets of FAT and bitmap image. The transaction safe
application or operating system may keep the sets of FAT and bitmap
image synchronized so that a non-transaction safe application or
operating system may read and write without error.
FIG. 2 illustrates an embodiment 200 of a system for using a file
system. A processor 202 uses operating system software 204 to read
and write data from a data storage device 206.
The embodiment 200 may be any type of computing device, from a
server computer to a personal computer or handheld device such as a
cellular telephone, digital camera, personal digital assistant,
video recording device, or any other device that stores data using
a file system.
In many cases, the data storage device 206 may be a removable data
storage device. For example, the data storage device 206 may be a
hot swappable hard disk drive, solid state memory stick, a
Universal Serial Bus (`USB`) attached data storage device, memory
card, or any other removable data storage device. In other cases,
the data storage device 206 may generally be a non-removable device
but a user may desire to have protection from power surges,
brownouts, or unexpected power failures.
The processor 202 may be any type of computational device. In some
cases, the processor 202 may be a state machine, gate array,
specialized processor, or other type of logic device, or the
processor 202 may be a general purpose processor capable of
executing various instructions.
The operating system software 204 may be software that is executed
by a general purpose processor 202, or may be built-in logic in a
hardware state machine such as a gate array. In some instances, the
operational logic may be a set of processor instructions that are
stored on the data storage device 206 or on some other data storage
device such as a programmable read only memory device, including
those that are erasable as well as those that are not.
FIG. 3 is an illustration of an embodiment 300 showing a file
system configuration. Embodiment 300 will be the basis of examples
discussed later in this specification. The file system comprises a
file directory 302 that contains two files, foo.doc of a file size
4 and starting cluster 07, and bar.xls with a file size 3 and
starting cluster 03. The file sizes are given in number of clusters
of storage space in this example.
The file allocation table 304 contains the sequence of clusters
allocated for each file. Each register in the file allocation table
304 represents a cluster of data storage space, and the address
stored within each register is the next cluster in sequence for
that particular file. An EOF designation in a register means that
the end of file has been reached. In this example, bar.xls begins
in cluster 02, then clusters 05 and 03 where the EOF has been
reached. Similarly, foo.doc begins in cluster 07, then sequences
through clusters 09 and 11 before reaching EOF at cluster 11.
The bitmap image 306 designates the clusters that are allocated. As
with the file allocation table 304, each register within the bitmap
image 306 represents a specific cluster in the data storage media
and corresponds with the file allocation table 304. In the present
example, a single bit is used to represent whether the particular
cluster is being used, with a 0 indicating that the cluster is
unused and a 1 indicating that the cluster is used. The bitmap 306
indicates that clusters 02, 03, 05, 07, 08, 09, and 11 are
allocated, which corresponds with the manner in which files foo.doc
and bar.xls are stored.
In some embodiments, a contiguous bit may be added to a directory
entry for a file. The contiguous bit may be used to indicate that
the clusters assigned to a file are contiguous. Thus, a file may be
described by a starting cluster and total number of clusters when
the file is contiguous. In such cases, the bitmap 306 may be used
to indicate that the clusters are assigned for the contiguous file,
but the file allocation table 304 may not be referenced or
updated.
FIG. 4 is a timeline illustration of an embodiment 400 of a
sequence of steps that may be used for deleting a file. Embodiment
400 illustrates an example of deleting the file `foo.doc` from
embodiment 300 illustrated in FIG. 3.
A first bitmap 402 is illustrated on the left side while a second
bitmap 404 is illustrated on the right side. The two bitmap images
are synchronized in block 406, resulting in identical bitmaps 408
and 410. The first bitmap is set as last known good in block 412.
An operation to delete foo.doc is initiated in block 414.
In addition to any changes made to directory listings, the result
of the delete operation is that second bitmap is modified in block
416, resulting in a second bitmap image 418. The second bitmap
image 418 has blocks 08, 09, and 11 set to 0, indicating that the
blocks 08, 09, and 11 are unused. In practice, a bitmap image may
be used to indicate whether or not a cluster is used or unused,
regardless what the file allocation table indicates or whether data
are actually stored in the clusters.
After all the modifications to the file system are complete, the
final step may be to set the second bitmap image as last known good
in block 422. At this stage, the file system will operate using the
bitmap image 418 and the space formerly allocated to foo.doc will
be free for overwriting. In block 424, the bitmap images are
synchronized, resulting in the first bitmap image 426 being
synchronized to the second bitmap image 428.
The embodiment 400 illustrates an atomic operation for a change to
the file system that involves only the bitmap images. Two copies of
a bitmap image are used: one that represent the last known good
bitmap image and a second that is modified during the processing of
the transaction. After all changes are finalized for the
transaction, a single operation of setting the second bitmap image
as last known good will commit the transaction. After the
transaction is committed, the two bitmap images are synchronized
and the process may be repeated.
FIG. 5 illustrates an embodiment 500 showing a sequence for
modifying a file. Embodiment 500 is a timeline sequence
illustrating the modification of bar.xls from embodiment 300 shown
in FIG. 3.
A first FAT 502 and a first bitmap 504 are shown in the left side
while a second FAT 506 and second bitmap 508 are shown on the
right. The FATs and bitmaps are synchronized in block 510,
resulting in identical FATs 512 and 516 and bitmaps 514 and 518.
For the purposes of illustration, only a portion of the FATs and
bitmaps are shown.
The first set of FAT/bitmap is set as last known good in block
520.
A portion of bar.xls is modified in block 522, resulting in changes
to the second FAT 524 and second bitmap 526. Meanwhile, the first
FAT 528 and first bitmap 530 remain unchanged.
The changes to bar.xls involved modifying one cluster of the file,
specifically cluster 05, and appending a cluster. In performing the
change, a new cluster 04 was used in place of the previous cluster
05 and cluster 01 was appended. In this example, the change to
cluster 05 may involve changing the value of a portion of the data.
The change may be implemented by copying the contents of cluster 05
into previously unused cluster 04, and modifying the data as
required. The data in clusters 02 and 03 may remain unchanged.
This change resulted in modifications to both the FAT 524 and
bitmap 526. The bitmap 526 reflects the changes that cluster 04 is
now in use and cluster 05 is now free. The bitmap 526 further
reflects the change that cluster 01 has been appended and is also
now in use. FAT 524 reflects the change that cluster 02 now points
to cluster 04 rather than 05, and cluster 04 now points to cluster
03. FAT 524 further reflects the change that cluster 03 now points
to cluster 01 which is the new end of file cluster.
Changes to the directory entries are made in a transaction-safe
manner in block 523. As part of the modification to the file
bar.xls, the length of file has been changed from 3 clusters to 4
clusters, thus the directory entry for bar.xls is modified.
Modification of a directory in a transaction-safe manner is
performed in a similar manner as the modification to the file
bar.xls: a copy of the modified portion of the directory is made in
a previously unused portion of the data storage system, the FAT and
bitmap images are updated to reflect the modified portion of the
directory, and the entire transaction is committed when the last
known good flag is toggled.
The second FAT and second bitmap are set as last known good in
block 532 and the FATs and bitmaps are synchronized in block 534.
The result is that FAT 536 is now identical to FAT 540 and bitmap
538 is identical to bitmap 542.
Embodiment 500 illustrates how a complex file modification
transaction may be performed in an atomic fashion. A copy of the
last known good file allocation table and bitmap image are used to
prepare a transaction prior to committing the transaction in the
atomic step of setting the last known good flag for the FAT and
bitmap. In performing the changes in an atomic fashion, a file may
be modified by copying a cluster of data to an unused cluster and
making the modification in the copied location. If the transaction
is aborted before setting the flag, the changes would not be saved,
but the file system would remain in the last known good state.
In some embodiments, file allocation tables may be very large. In
order to speed up the synchronization process for the file
allocation table, the portions of the file allocation table that
are modified may be identified and tracked so that during
synchronization, the identified portions may be overwritten while
the remaining portion of the FAT may be left alone. In such an
embodiment with very large file allocation tables, the speed of
synchronization may be greatly enhanced.
FIG. 6 is a flowchart illustration showing an embodiment 600 of a
method for transaction-safe file replacement. A modified version of
a file may be created over a period of time. The original file may
be replaced by the modified version of the file in a single
transaction using a second FAT and bitmap and committed by toggling
the boot sector pointer. The embodiment 600 performs a rather
complex transaction in a transaction-safe mode with an atomic
action. The transaction includes deleting a first file and renaming
a second file to have the first name and directory location as the
first file.
A first file is created in block 602 and assigned to a directory in
block 604. A modified version of the file is created in block 606
and updated in block 608. If the modification is not complete in
block 610, more modifications are performed in block 608. When
modifications are complete in block 610, a single transaction is
begun in block 612. A portion of the directory is copied and
modified in block 614 to point to the modified file in place of the
original file. The original file is deleted by updating the bitmap
image to reflect the deletion in block 616. The entire transaction
is committed by the atomic action of flipping the boot sector
pointer to the updated FAT and bitmap in block 618.
In embodiment 600, the directory is modified in block 614 in a
similar fashion as illustrated in FIG. 5. The directory is treated
within the file system as another file, so one or more clusters
that make up the directory may be copied to a previously unused
location, modified, and then the transaction may be committed.
The foregoing description of the subject matter has been presented
for purposes of illustration and description. It is not intended to
be exhaustive or to limit the subject matter to the precise form
disclosed, and other modifications and variations may be possible
in light of the above teachings. The embodiment was chosen and
described in order to best explain the principles of the invention
and its practical application to thereby enable others skilled in
the art to best utilize the invention in various embodiments and
various modifications as are suited to the particular use
contemplated. It is intended that the appended claims be construed
to include other alternative embodiments except insofar as limited
by the prior art.
* * * * *
References