ext3 defragmentation
Posted Apr 22, 2004 16:42 UTC (Thu) by
Duncan (guest, #6647)
In reply to:
ext3 defragmentation by jbh
Parent article:
ext3 block reservation
There's not enough info in that limited quote to tell for sure, but if an
ext2 defragger is run on an ext3 filesystem either mounted, or unmounted
but with unsynced data in the journal, it WILL likely corrupt data,
because the ext3 side of things won't be aware of the data-blocks moving
out from where it expects them to be, and could easily attempt to write
data to the OLD location.
Some years ago, back in early '98, b4 I switched from MSWormOS and while I
was participating in the public betas for IE4, it had a similar conflict
between the IE cache code and the 95 defragger. IE3 had used a mechanism
where by the cache index file location was kept in memory for direct
writing, bypassing the file-system lookup after it was loaded and writing
directly to disk, for performance reasons. That worked with IE3, because
it was only temporarily loaded and was shut down during defrags. MS
changed the rules with IE4 and its desktop extensions, however, and it
remained loaded as long as Windows Explorer was loaded, because it WAS now
Windows Explorer as WELL as IE. Normally, such constantly loaded "system"
files remained untouched and unmoved by the defragger. Unfortunately in
the IE4 second beta, they forgot to set the IE cache index file as
"system" and the defragger would move it out from under the still live
IE/WE process, which would then write all over whatever replaced the file,
when it tried to rewrite it to disk. The simple enough fix was to set the
system flag on the file, but IE would reset it every time it was started,
so one had to keep on top of things.
Fortunately, here, I'd set up my temp dir as a seperate partition, and had
the IE cache set to use my temp partition. Thus, the only data I had
exposed was temporary anyway, and the bug wasn't a big problem for me.
However, some of the other beta newsgroup regulars and others that posted
only when they had problems, lost valuable data to that bug. Keeping temp
files in their own partition saved my butt, but I've never forgotten that,
as it left a BIG impression on me, not only on the risks of beta, but ALSO
on the wisdom of limiting potential damage with multiple partitions. Of
course, it also impressed me with the wisdom of making SURE nothing is
going to be writing to that defragged partition without being aware of the
new location of the data.
It's entirely possible the test was done with a properly unmounted and
journal-empty ext3 partition for the defrag, but if it wasn't, it's no
surprise there were data integrity issues.
Duncan
(
Log in to post comments)
