lkml.org 
[lkml]   [2000]   [Jul]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Want to help with NTFS


Anton Altaparmakov wrote:
>

> I agree for the normal shutdown case. But what about this scenario:
>
> User is in NT. It crashes. User is fed up and reboots into Linux. User then
> r/w mounts his NTFS volume under Linux and continues working on their word
> document but now using some linux "word compatible(TM)" program.
> NTFS linux driver marks journal empty. - BANG! - We have just caused
> corruption due to removing the journal which contained incomplete
> transactions which would have been fixed in either the REDO or UNDO passes.
>
> For example the cache manager might have written the journal already but
> the actual changes as defined by the redo fields have NOT occured yet. We
> might not even have a "transaction committed" record yet and the UNDO pass
> might be needed to return to a sane state.
>
> To my knowledge the cache manager will flush the log file (induced by LFS
> daemon) before flushing the actual on disk changes. - If a crash occurs
> during this time then the logfile is actually required and we can't just
> throw it away. - Unless of course we say the we reset the logfile and set
> the chkdsk bit (and possibly the 2ndary chkdsk bit you mentioned as well?)
> so that windows chkdsk can read and repair inconsistencies even tough we
> have killed the logfile.
>
> In an ideal world we would check the logfile and perform something similar
> to the analysis pass of NTFS recovery and if we find that there are
> transactions without commit then we refuse to do a r/w mount and tell the
> user to mount the partition under windows to fix it before using it for
> writing in linux. - For now we can resort to just emptying the logfile but
> I am worried about causing corruption as described above.
>
> Am I wrong?

No. You are not wrong. This is pretty simple. Since the MFT is
updated real time in W2K, the journal contents are pretty much
irrelevant for Linux -- the MFT WILL BE THE MOST RECENT COPY. In the
situation you describe, unless they boot under W2K before booting under
Linux, the journal will get recovered. If you simply wipe the journal
file when Linux boots, chkdsk will drop into a more agressive mode the
next time W2K mounts the volume and consistency check the MFT (which is
probably better than trying to recover from an out-of-sync journal).
The safest way would be to always wipe this file if Linux mounts the
volume, and implement our own JFS variant for NTFS as a simple journal
file on the volume (and update the MFT real time and use a background
process to rollout the journal entries as they do) -- but make certain
you set some bits somewhere so you know when not to trust your journal
since W2K may have booted on the volume and got the MFT out of sync with
your journal file -- or always zero the NTFS default journal entry, and
if you ever see that W2K has been booted (and rebuilt this MFT entry)
you know that your journal may be out of sync. This way, the next time
W2K mounts the volume, it will see that the journal file is missing and
consistency check the entire MFT. It will make booting on W2K slower,
but since it takes so long for W2K to boot anyway, most MS customers may
not notice :-).

Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.061 / U:1.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site