[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Wed, 8 Aug 2001 07:45:56 +1000
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
(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.
- NTFS resizer,
Andrew Clausen <=