"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.)
> > >
>
Anton,
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.
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.
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.
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/
This archive was generated by hypermail 2b29 : Sat Jul 15 2000 - 21:00:11 EST