|
From: Szakacsits S. <sz...@si...> - 2004-01-27 11:29:50
|
Hello Everybody,
After a two months extensive automatic and voluntary testing, thanks to
Miguel Lastra and his collegues at the University of Granada, furthermore
to Dewey M. Sasser, Erik Meade, Martin Fick, Sandro Hawke, Dave Croal,
Lorrin Nelson, Geert Hendrickx, Robert Bjorkman and Richard Burdick, I
commited ntfsresize relocation support into the BK repository.
This means,
- no need to defragment before resizing NTFS
- no more "unmovable" blocks
- no more "volume end is fragmented" messages
Altough during testing we didn't have any corruption problem, the new code
is still a work-in-progress and not for general use. But it's perfect to
test and you should not find any corruption problem. Otherwise please let
me know but see below.
It's strongly recommended to ntfsclone(8) NTFS before resizing/testing.
Well, actually you can test even on an ordinary or metadata-only image
got by ntfsclone. If you think you found a problem and you have the
metadata-only image then we can investigate and fix the problem.
There are still some minor restriction during resizing but the chance to
hit them in real world usage is low. Ntfsresize will catch them anyway and
will prevent you to destory your data. Adding support for them depends on
user demand (usually 2-3 requests, willing to test the new code is enough).
Here are the left cases,
- NTFS with bad sectors isn't supported yet. This will be supported,
I actually even have the code but nobody needed it recently. It seems
the need for this is much higher during the hot summers :)
- Extremely highly fragmented $MFT isn't supported yet. Technically
this means $MFT having attribute list attribute. Relatively rare but
they exist.
- Relocation of the first $MFT extent isn't supported yet. This
may manifest as a shrink limit around 3GB for big partitions, mostly
on XP.
- Usually the smallest shrunken size possible is around
<used space> + "10-200 MB"
even if ntfsresize says "You might resize at <used space>".
Note, the advice is not *could* but *might*. Just do --no-action test
runs and you can see what would happen. Depending on many factors the
above "10-200 MB" could be even higher than 200 MB. The maximum we've
ever seen was 800 MB. This will be improved later on.
Note, it's probably wise to leave some free space for Windows to
be able to safely boot. Usually <used space> + "50-100 MB" is
recommended. Anybody has some more exact data on this?
- Resizing in the middle of some metadata isn't supported yet. This
will be solved later on and for now ntfsresize advises the closest
size to the original one that will work.
Things that left to do are cleanups, adding support for the more rare,
still unsupported cases, make it robust, more internal consistency checks,
better error reporting for external tools, moving towards being in libntfs
(Parted integration) and you name it.
Have fun,
Szaka
|
