Re: [Linux-NTFS-Dev] NTFS resizer

[Andrew Clausen]

On Wed, Aug 08, 2001 at 12:42:42AM +0100, Anton Altaparmakov wrote:
> libntfs is in no way prepared to do any of this at this point. Just thought 
> you should know...

Ok.  I'm still only "just" groking this stuff ;)

> In particular there is _no_ support for extension mft 
> records.

Oh... I hadn't noticed...

> mkntfs contains a lot of write code but it is there and not in the library 
> and it uses global variables all over the place so it can't just move to 
> the library. That was necessary to write a reliable mkntfs FAST. I left 
> cleanups for a later time.

OK.

> >(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)

> 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

> Our approach to the journal is: fill the entire file with 0xff bytes and 
> forget it ever existed. - ntfsfix does just this and it uses libntfs to do 
> so. - Windows is happy to accept that a journal filled with 0xff bytes 
> means the journal is empty and initializes it on boot.

OK :)

> >Anyway, how sane does all this sound?  FWICT, libntfs looks mature
> >enough to implement this.
> 
> I beg to differ. It's stable all right but it doesn't provide you with the 
> required functionality. mkntfs looks more like your friend here. My long 
> term plan is to move most of the mktnfs code into libntfs but I am busy 
> with other stuff at the moment (and am going to be for the next few months 
> at least).

Ah, ok.

> >BTW: it would be nice to have library functions, ntfs_mkfs(), etc.,
> 
> Now that would be easy. Just take mkntfs.c and rename main() to ntfs_mkfs() 
> and fiddle with option parsing...

Yep.  And also need that iochannel thing.

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

> When you are finished/it's 
> sufficiently stable I can merge it into the main trunk

Sounds good :)

> (at this stage I 
> like to keep the main trunk stable because as you said yourself it is very 
> stable now and destabilizing it is something I would like to avoid).

Certainly, separating stable&devel is a Good Thing TM.

Anyway, I haven't actually run any code yet... just reading ;)


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.

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

Andrew