Andreas Dilger wrote:
On Aug 03, 2007 00:02 +0530, Aneesh Kumar K.V wrote:
Andreas Dilger wrote:
Is this the mtime and UUID of the new filesystem or the old one? It
should be the UUID and mtime of the new filesystem, so that the
undo file can be verified against the current superblock. This poses
a bit of a problem, because that information isn't saved until after
the mke2fs run is finished.
One possibility is to overwrite this information at the end of mke2fs
after the new UUID and mtime are written?
This can be done by writing the file system identity during the the
io_channel_close.
How about this patch on top of the last series. I will merge this into the
patcheset
I thought about this also, but in fact for most uses of the undo manager
we want to save the information at the start instead of the end, so it
is possible to undo e.g. a partial e2fsck that crashes before it finishes.
Only with mke2fs (and, I guess tune2fs -U) does the UUID change at the
end.
I am not sure whether saving the information at start is needed. I understand
that what we are looking for is the case when the application crashes without
doing a io_channel_close. In that case i would say the user can use the
--force option and replay the data from the tdb file. The UUID could very well
be changed on the disk before the application crashed. So even if we save
UUID at the start, there are cases where it won't match with the disk UUID.
That actually brings me to another change. I would be moving the block size
recording changes from write_file_system_identity to a separate function
and will be calling it at the first write. That make sure we have a record
that carry the blocksize even though we don't have one with mtime and UUID
in the tdb file.
Also, can you check if mke2fs does any non-iomanager output? I think
there is code to "zap" the old superblock at the start and old RAID info
at the end of the block device, and I'm not sure if this uses the normal
IO manager or not.
The zap_sector and zap_zero uses the io manager to zero out the blocks. So
they should be ok. I found that when we use -J device=<journal-device>. mke2fs
uses unix I/O manager to write to the journal super block. I guess that is ok
because we are not tracking changes to journal device.
I found that the journal_super_block have only space for 48 s_users
UUID entries. But in ext2fs_add_journal_device we are not checking
the limit. Does that mean repeated mke2fs with -J can lead to corruption ?
-aneesh
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
