|
From: Bird, B. <bar...@ed...> - 2003-07-11 13:53:30
|
> Just to be sure, did you run chkdsk between these tries?
Sometimes yes, sometimes no. I often did, but not before the attempt to
pause Norton Antivirus.
If I understand the output of ntfsresize correctly, it is saying that 1 bit
in the cluster bitmap has one cluster (out of 39 million) in use when in
fact
nothing is using it (or nothing that ntfsresize knows about).
The position of this cluster may be significant. Isn't it just before where
the MFTMirror ought to be? Perhaps there is a bug in chkdsk?
I do not think this is a big error and it seems that Windows can tolerate
it.
Of course, there is a risk that it IS valid.
I appreciate your desire to ensure that chkdsk does get run if errors are
found. However, it seems to me that ntfsresize could allow (with suitable
warnings) resizes down to such a cluster without jeopardising anything.
Additionally, it could be more restrictive and only allow this in 'special'
circumstances.
ntfsclone might be useful, here. I'd have thought that toleration of
inconsistencies should be allowed in debugging use (2), especially if the
case I have here crops up now and then. Could it be used to extract at
least
the first few records of MFT Mirror? The volume of data will need to be
kept
down because I am writing it to the floppy - there is nowhere else!
Unfortunately I don't have fsutil, I can't find it on the resources disc
- isn't this only in XP? BUT - I used the sysinternals program ntfsinfo
(even though it's not supposed to work for W2k!):-
Volume Size
-----------
Volume size : 19084 MB
Total sectors : 39085137
Total clusters : 39085137
Free clusters : 35890639
Free space : 17524 MB (91% of drive)
Allocation Size
----------------
Bytes per sector : 512
Bytes per cluster : 512
Bytes per MFT record : 1024
Clusters per MFT record: 2
MFT Information
---------------
MFT size : 12 MB (0% of drive)
MFT start cluster : 16
MFT zone clusters : 4420000 - 9279808
MFT zone size : 2372 MB (12% of drive)
MFT mirror start : 29208
The results look good on the whole, apart from the MFT mirror start which
looks
wrong, surely it should be half of total clusters (19542568 not 29208)? It
is
that value (half the total) on my other W2k machine (on both its 2 NTFS
partitions), so I think ntfsinfo is giving the correct answer.
BTW ntfsresize finds no errors on those partitions.
Thanks for your help,
Regards,
Barry
-----Original Message-----
From: Szakacsits Szabolcs [mailto:sz...@si...]
Sent: 11 July 2003 10:36
To: Bird, Barry
Cc: 'lin...@li...'
Subject: RE: [Linux-NTFS-Dev] Extra cluster half-way along NT flelsystem
On Fri, 11 Jul 2003, Bird, Barry wrote:
> Thanks for taking an interest in this problem.
You're welcome :)
> Totally 1 cluster accounting mismatches
> ----
> Yes, it's always the same cluster number, and only one.
Just to be sure, did you run chkdsk between these tries?
> If you care to send me a special program that can extract slices
> of this filesystem for inspection, I'd be happy to run it and send
> you the results.
I recently finished 'ntfsclone'. This can be used to
1) make a full backup to a sparse file, another partiton or standard
output, e.g. for full backup through network (basically it's like
'dd' however it can be _much_ faster because it understands NTFS).
2) save only the important NTFS structures. This can be very
useful for developers for debugging, etc.
However it doesn't support inconsistent NTFS, if you think I could add this
feature, I'd be interested in 2).
If you do have backup then another, additional way could be I add optional
support for inconsistent NTFS to the development version of ntfsresize. I
don't think it would cause problems [of course you won't be able to resize
below to stalled/lost cluster], still I'm quite unwilling to do it because
people would use it instead of doing chkdsk (and that always fixed the NTFS
inconsistencies ... so far).
> PS I got hold of your ntfsmeta program
BTW, if you have 'fsutil' on your Windows (should be default or in the
Resource Kit), could you do a
fsutil fsinfo ntfsinfo C:
> and ran it to get the 'boot record', if that helps (the small number of
> unused sectors seems at variance with the report in Windows that more
> than 91% of the disc is unused 8388736/39085137 = 21.5% unused! - I
> suppose I just don't know how to interpret this):
"Unused" below means the field is "unused", not "unused sectors".
"Reserved or "unknown" would have been a better naming. Well, actually
it's used, because it's value is usually 8388736 or 128 if NTFS is on
an USB device.
> Unused : 8388736
> Number of sectors : 39085137
Cheers,
Szaka
|
