[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Linux-NTFS-Dev] NTFS resizer

From: Anton Altaparmakov
Subject: Re: [Linux-NTFS-Dev] NTFS resizer
Date: Wed, 08 Aug 2001 00:42:42 +0100

At 22:45 07/08/2001, Andrew Clausen wrote:
I'm thinking about writing an NTFS resizer soon.  I would rather
it be a "resize-the-start" one.  i.e. it can safely move the start
without interruption, and without doing a "slide" dumb-copy.

General algorithm: (modelled on my FAT resizer)

(1) figure out which clusters need to be moved.  Add attributes (and
therefore file records and the MFT) to the list... we want a copy of
this for (4).

(2) allocate those clusters a new home in free space, and keep in
memory.  [*]

(3) copy them

(4) in the copy of the metadata, update the block references (i.e.
the run-lists).  Note, that since we are moving the start (in the
general case), *ALL* block numbers get changed.  Also, the size
of the run-lists might change, so we need to be prepared to allocate
more file records, or make internal attributes external.  (NTFS's
special cases are a PITA!)

libntfs is in no way prepared to do any of this at this point. Just thought you should know... In particular there is _no_ support for extension mft records.

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.

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

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

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.

[*] the LVM guys are going to write a generic block mapper (yay!)
A nice side-effect of this, is we can get some swap space when
before there is a swap partition (say, during a GNU/Linux install...),
by finding some free space on the NTFS partition (if we're shrinking,
in the area that will become unused would be a good choice!), and
create a logical volume out of it.  Then swapon!

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

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

that I can call from libparted.  Also, a general "abstract block device"
interface (a la e2fsprog's ext2_io.h's iochannel thingy) would be nice.


Accepting patches?

Of course! Patches are always very welcome! (-:

I am quite happy to grant you CVS access, too. You could create your own branch and commit to it as much as you like. When you are finished/it's sufficiently stable I can merge it into the main trunk (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). But if you prefer to stick with patches fine by me, too. Your call. - Using your own branch would have the advantage that we can make unstable releases without affecting the main branch nor the stable releases.

Best regards,


  "Nothing succeeds like success." - Alexandre Dumas
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/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]