Re: [Linux-NTFS-Dev] NTFS resizer

[Anton Altaparmakov]

On Wed, 8 Aug 2001, Andrew Clausen wrote:
> On Wed, Aug 08, 2001 at 12:42:42AM +0100, Anton Altaparmakov wrote:
> > >(5) activate the new metadata.  The MFT likes to be at the start
> > >of the partition, so what should we do here?  Create a massive
> > >journal entry for the update of the MFT?  (/me hasn't looked at
> > >the journal at all yet)  Or we can sacrifice atomicity... just given
> > >the size of the MFT, this makes me nervous...
> > 
> > No it doesn't care at all. In fact if you use Partition Magic you will 
> > notice it doesn't move anything at all. It only rewrites all the run lists 
> > and stops there. Obviously this applies only when you are making the 
> > partition bigger! In fact my C: drive has it's MFT smack in the middle of 
> > the 10Gb volume (well not quite in the middle but it's not too far from 
> > it...)
> 
> Cool!  Well, that makes the resizer very easy to write then :)
> (Except for the extended record stuff, ergh)

Actually it does move one thing: the file $Boot since this _has_ to start
at the beginning of the volume (it contains the boot sector). But that is
not exactly a problem... - It's just 8kb at the start of the volume that
need moving forward and the cool thing is that the run list for $MFT
doesn't even need updating because it will still occupy the same clusters
(the first 8kb worth). - Of course, after moving it, you will actually
have to edit the boot sector to reflect the new size of the volume.

And the other thing that will need to move os the backup boot sector. - It
is usually at the end of the disk but if you are on a NT3.51 or earlier
partition it is in the middle of the disk. Obviously it has to be in the
middle of the disk or it won't work... But you could just say you require
NT4.0 or above and forget about the issue when resizing the front of
the partition. There aren't many people using NT3.51 nowadays...

> > Note you cannot create any journal entries because nobody has a clue how 
> > the journal works. If you reverse engineer it of course that is another 
> > matter. I would be _extremely_ interested to read the docs/code you would 
> > write afterwards. (-: What we know so far is barely enough to understand 
> > the restart area but we don't really understand that either.. )-:
> 
> Well, it's 100% atomic without journaling, so no need.  Sorry :P

I thought you might say that...

> > >Accepting patches?
> > 
> > Of course! Patches are always very welcome! (-:
> > 
> > I am quite happy to grant you CVS access, too.
> 
> Prolly isn't necessary, if I'm the only one hacking for a while...

ok.

> One other thing: libparted has a nice (IMHO) error handling system.
> It allows users to say things like "Yes/No/Cancel?".  Also, it allows
> C++ style try-catch (which is useful for things like bad-blocks).
> 
> It's VERY simple :)  (have a look in include/parted/exception.h)
> 
> I have found the first particularly useful: it is BAD to stop a resize,
> just because you found 1 bad sector, or whatever.

That's one other thing none of the existing NTFS code copes with: bad
blocks. This is partly because I consider modern hard drives to never have
any (they remap them in hardware to spare region of blocks at end of
device) so haven't been bothered to write the code and partly because we
are not quite sure how they work exactly (we know the theory but we are
unsure of the on disk run list format used by $BadClus). 

> So, what do you think?  Options:
> * cut&paste
> * create a similar system, and make libparted wrap it, to integrate
> with libparted's system

I will have a look at it and let you know. (-:

Best regards,

        Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/