|
From: Anton A. <ai...@ca...> - 2004-01-27 12:54:16
|
Hi, That is very good news! I have created a snapshot of the -devel repository in which Szaka committed the code. It is available on the Linux-NTFS website. http://linux-ntfs.sourceforge.net/snapshots/ntfsprogs-devel-200401271247.tar.bz2 Cheers, Anton On Tue, 2004-01-27 at 11:24, Szakacsits Szabolcs wrote: > 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 -- Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/ |
