[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.
Hm.
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,
Anton
--
"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/
- NTFS resizer, Andrew Clausen, 2001/08/07
- Re: [Linux-NTFS-Dev] NTFS resizer,
Anton Altaparmakov <=
- Re: [Linux-NTFS-Dev] NTFS resizer, Andrew Clausen, 2001/08/08
- Re: [Linux-NTFS-Dev] NTFS resizer, Anton Altaparmakov, 2001/08/08
- Re: [Linux-NTFS-Dev] NTFS resizer, Andrew Clausen, 2001/08/08
- Re: [Linux-NTFS-Dev] NTFS resizer, Anton Altaparmakov, 2001/08/08
- Re: [Linux-NTFS-Dev] NTFS resizer, Andrew Clausen, 2001/08/16
- Re: [Linux-NTFS-Dev] NTFS resizer, Anton Altaparmakov, 2001/08/16