[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Linux-NTFS-Dev] NTFS resizer
From: |
Andrew Clausen |
Subject: |
Re: [Linux-NTFS-Dev] NTFS resizer |
Date: |
Wed, 8 Aug 2001 15:03:49 +1000 |
User-agent: |
Mutt/1.2.5i |
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
- NTFS resizer, Andrew Clausen, 2001/08/07
- Re: [Linux-NTFS-Dev] NTFS resizer, Anton Altaparmakov, 2001/08/07
- 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