|
From: Anton A. <ai...@ca...> - 2004-03-25 09:28:27
|
On Thu, 25 Mar 2004, Szakacsits Szabolcs wrote: > On Wed, 24 Mar 2004, Anton Altaparmakov wrote: > > Really, the only way is to scan $LogFile to determine the state. If the > > log is fully check pointed and no uncommitted transactions are remaining > > it means the volume is clean. And otherwise it means it is dirty. I > > have been planning to implement this in ntfsprogs (and in the kernel for > > that matter) but haven't had time as it is rather a lot of work. > > Why is it a lot of work? Unknown? > > Just a "clean" or "dirty" answer would be enough. No need to redo or > undo the log/update records. Oh, of course. I have absolutely no intention of implementing redo/undo of the journal. Or at least not until we have a complete ntfs rw library and driver, then maybe I will look into it but otherwise no way... The difficulty is that there is no single bit saying "journal clean" or "journal dirty". You have to actually parse the entirety of $LogFile reading every single record, parsing each of them, and finding the last written record. Then you have to backtrace what you did till you find the last checkpointed record and then I am not too sure. Probably something along the lines of "if any records requiring undo or redo are present after the last checkpoint record assume journal is dirty otherwise assume it is clean". When we find it is clean we then proceed to empty the journal as we do now so that a Windows boot doesn't gratuitously perform a redo pass on us and corrupt something. This is a lot of code most of which requires existing $LogFile analysis and further reverse engineering. This is not a piece of cake... Best regards, Anton -- Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/ |
