[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 20:38:41 +1000
User-agent: Mutt/1.2.5i

On Wed, Aug 08, 2001 at 11:04:57AM +0100, Anton Altaparmakov wrote:
> Actually it does move one thing: the file $Boot since this _has_ to start
> at the beginning of the volume (it contains the boot sector). But that is
> not exactly a problem... - It's just 8kb at the start of the volume that
> need moving forward and the cool thing is that the run list for $MFT
> doesn't even need updating because it will still occupy the same clusters
> (the first 8kb worth). - Of course, after moving it, you will actually
> have to edit the boot sector to reflect the new size of the volume.

Right.  This isn't a big deal.  Unconditionally mark the clusters you
need to invade for duplication, and non-atomically update them at
the end.  This shouldn't be a problem, if the number of non-atomic
updates is very small (not worth complicating the resize, IMHO)  I
was just worried about big things, like the MFT.

> And the other thing that will need to move os the backup boot sector. - It
> is usually at the end of the disk but if you are on a NT3.51 or earlier
> partition it is in the middle of the disk. Obviously it has to be in the
> middle of the disk or it won't work... But you could just say you require
> NT4.0 or above and forget about the issue when resizing the front of
> the partition. There aren't many people using NT3.51 nowadays...

As I said, no big deal :)  But thanks for telling me anyway ;)

> That's one other thing none of the existing NTFS code copes with: bad
> blocks. This is partly because I consider modern hard drives to never have
> any (they remap them in hardware to spare region of blocks at end of
> device) so haven't been bothered to write the code and partly because we
> are not quite sure how they work exactly (we know the theory but we are
> unsure of the on disk run list format used by $BadClus). 

Yeah, there something we should do eventually, but no big deal for now.


reply via email to

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