Messages in this thread | | | Date | Mon, 10 Jul 2000 18:10:00 +0100 (BST) | From | Anton Altaparmakov <> | Subject | Re: 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/
| |