At 18:40 10/07/2000, Jeff V. Merkey wrote:
>Anton Altaparmakov wrote:
> > - tell the user that she/he needs to mount the volume under NT/2k and run
> > chkdsk on it (we can set the chkdsk flag if it is not set but it shouldn't
> > be required since the NTFS+LFS will operate regardless but chkdsk might
> > fix some more things [refering to bit 1, run chkdsk on mount]). We would
> > then mount read-only and refuse r/w mounting.
>
>Set the flag.
ok. can certainly do that. (-:
> > - ignore the contents of the journal but mark it as empty anyway or
> > completely get rid of it. - This is a nasty way of doing things, since it
> > will result in data corruption due to log file contents not being
> > redone/undone but it will stop the corruption due to windows
> > redoing/undoing things randomly from an inconsistent journal.
>
>Mark it empty. The info the journal will have already been committed to
>the MFT -- the journal just allows the cache manager to go back and
>verify each transaction. Just zapping it the first time it's munted
>read/write will completely avoid this problem :-).
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?
> > I was unable to complete my experimenting since Win2k decided to commit
> > suicide on the system partition and even though it did a clean shutdown it
> > refused to mount the partition again afterwards and the only way to read
> > the partition now is using your diskedit utility from my NT4 install
> > (which refuses to display the mounted partition stating there are errors).
> > Diskedit does work and I can't see anything immediately wrong with it
> > apart from the two MFT copies are inconsistent. )-: Anyway a reinstall is
> > probably required here but I might first try to copy one of the MFTs on
> > top of the other and see what happens first... [Note this is not the linux
> > driver or NT4 at fault, since I only rebooted the computer and haven't
> > done any writting to the partition in between and I never write mount the
> > system partition on linux anyway...]
>
>Sounds like we need a repair utility first so you don't have to keep
>reinstalling W2K everytime the drive gets trashed. Set the dirty
>squared bit, and you'll find that chkdsk will be able fix the volume
>more often without always needing to re-install. You may also want to
Unfortunately in this case it doesn't get to run chkdsk since it can't find
any of the required bootfiles (it gets as far as selecting which OS to load
but this is not on the win2k ntfs system partition so is fine and then
fails immediately when it tries to actually find things on the ntfs
partition) - the obvious reason is the partition being corrupt in some
stupid way...
Also it wasn't linux causing the damage but win2k itself. - I didn't even
BOOT linux inbetween shutdown win2k and attempt to reboot into win2k...
So yes a repair utility would be good but quite how it would fix my current
problem is not clear to me. - It would have no way of knowing whether the
mft or the mftmirror is correct for example.
>download alritis image blaster or express from www.altris.com so you can
>image your NTFS volumes and store them offline so when one gets trashed
>you can just boot to DOS or linux and restore the volume. Will save you
>a lot of time ....
We use ImageCast IC3 from www.imagecast.com here to distribute NT to the
computer lab PCs using premade ntfs volumes, which allows you to do this
kind of thing over the network and from within a nice GUI in Windows so I
think I will stick with that. But thanks for the link. Hadn't heard of them
before. Might give them a try. - We have so far tried ghost and drive image
as well but weren't happy with them (drive image doesn't do multicasting
and like ghost seems to be rather messy with lots of bootdisks involved.
ghost causes NTFS corruption so some machines won't even boot after
imaging, so does IC3 but they keep improving it and the ntfs corruption is
less severe so a chkdsk upon first boot (I set the chkdsk flag before
making the image) seems to fix everything fine.
Regards,
Anton
--
"Programmers never die. They do a GOSUB without RETURN." - Unknown source
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
ICQ: 8561279
WWW: http://www-stu.christs.cam.ac.uk/~aia21/
-
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/
This archive was generated by hypermail 2b29 : Sat Jul 15 2000 - 21:00:11 EST