lkml.org 
[lkml]   [2000]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Want to help with NTFS
On Mon, 10 Jul 2000, Jeff V. Merkey wrote:
> "Jeff V. Merkey" wrote:
> > "Jeff V. Merkey" wrote:
> > > Anton Altaparmakov wrote:
> > > > At 16:24 09/07/2000, Steve Dodd wrote:
> > > > >On Sun, Jul 09, 2000 at 02:05:19PM +0200, Igmar Palsenberg wrote:
> > > > > > Any clues yet in what way NTFS v 3.0 (win 2K) differs ?? The old driver
> > > > > > ate the FS :-))
> > > > >
> > > > >I inferred from something Jeff said a while back that the volume management
> > > > >stuff was storing data in blocks that were marked free in the block bitmap.
> > > >
> > > > I don't think so. This would cause corruption by the WinNT4 driver as
> > > > well... (Unless there is a safe-guard in NT4 we are missing in linux.)
> > > >
> I went through your code, and without giving up too much info, and
> wanting to help MS customers with trashed volumes, I also recommend:
>
> 1. Check for the duplicate boot sector at sectors-1 instead of always
> assumming it's supposed to be at sectors/2. This looks fixed, but you
> should check to make certain you are not blindly writing to n/2
> somewhere in the code when you update the boot sector for the volume.

Argh. I thought it was checking at sectors-1 anyway. - This obviously
needs to be changed ASAP. Everybody knows/should know that only WinNT 3.x
used sectors/2 and WinNT4 + 2k use sectors-1 (I think this is stated in
Regis <can't spell surname> infos).

> 2. NTFS journalling is covered under a bunch of patents, and is
> probably impossible to implement properly without infringing them. The

)-:

> way NTFS journalling works is that changes to the MFT are transacted
> real time for performance, and logfile entries get rolled out by the VM
> Cache Manager in the background. There are some assumptions about
> ordering in the logfile and the way the MFT gets layed out, and it's
> rather complicated. The moment you write to the volume, if you are not
> updating the logfile with their "gap file" methods, then the log gets
> out of sync with the MFT. Since NTFS on W2K does a rollout of the
> logfile after the fact, if you shutdown the volume and have the shutdown
> bits in an inconsistent state, NT will start rolling out these changes
> in an arbitrary and unpredictable manner on the next mount, and start
> clipping and pruning the MFT and possibly trashing files. Write '0's
> into the logfile entry in the MFT before they boot to W2K so the VM
> Cache Manager will not read an inconsistent journal, and start trashing
> the volume.

I am well aware of the operational concepts of the LFS+NTFS. And your
reasoning is also the same why I think there is corruption by not handling
the journal. - Seing the patents issue which I was not aware off, I now
think that the implementation for the linux driver will be without the
journal BUT when mounting a volume read/write, we will scan the journal
and check whether it is as it were "empty", i.e. a proper shutdown has
occured. - If yes then everything is fine since NT/2k will stop after the
analysis pass, or at least the redo and undo passes will have nothing to
do (that's my understanding of it). If however the system was not shutdown
properly we will either (user selectable mount option maybe?):

- 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.

- 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.

Thinking about this, the first option should probably be the one to
implement since the second will cause data corruption and we don't want
that...

> 3. There's a "dirty squared" bit in the Volume Attribute Field that gets
> set by chkdsk on W2K when it is invoked so in the event the power gets
> knocked out while chkdsk is repairing a NTFS volume, on the next boot,
> it will drop chkdsk into a mode where it does not trust any of the meta
> files on the volume, and does a very thorough consistency check of these
> files and repairs them. Be warned, chkdsk in this mode will do some
> pretty severe changes if it finds inconsistencies, and can cause massive
> data loss if the volume is badly damaged, but this may allow NTFS
> volumes tashed by Linux to get repaired properly on the first pass of
> chkdsk rather than letting chkdsk run in "wimp" mode first, and possibly
> take your out-of-sync journal and apply (and trash the volume) before
> dropping into "dirty squared" mode and tashing the volume even further.
> I'm not going to tell you which exact bit -- you need to play around
> with these bits and boot W2K and see which one does it.

I actually did some comparisons between NTFS v1.2 and NTFS v3.0 partitions
and the way they are dealt with by NT/2k last weekend and found something
interesting: NT4 when it sees a v3.0 NTFS parititon sets the 4th bit
(=0x8) in the volume flags field. - I think that this is to signal win2k
that an older NTFS driver has written to the new version NTFS partition.
Win2k then presumably will take this into consideration and "fix" the NT4
caused corruption. - Assuming this is the only signal required then
setting this bit in the Linux driver should fix the corruption
(disregarding journalling based corruption and overwritting system
data corruption and any other bugs in the driver of course...)

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...]

Anton

> 4. I think so long as this is being enabled for Linux/W2K migration, MS
> may be more open to tolerating NTFS on Linux. Read only is already
> there and without their help, but at the very least, MS customers who
> want to migrate Linux/W2K should be allowed to without too much pain.
>
> :-)
>
> 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/
>


--

Anton Altaparmakov Phone: +44-(0)1223-333541 (lab)
Christ's College eMail: AntonA@bigfoot.com
Cambridge CB2 3BU WWW: http://www-stu.christs.cam.ac.uk/~aia21/
United Kingdom ICQ: 8561279


-
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.112 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site