NTFS resizer

[Andrew Clausen]

Hi all,

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

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


[*] 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.

BTW: it would be nice to have library functions, ntfs_mkfs(), etc.,
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?

Andrew