Why is there 376MB "used" in empty 45GB NTFS logical drive?

R

Robbie Hatley

I'm trying to back-convert a logical drive on my machine from
NTFS to FAT32, so that it will be accessible both from Win2K
and from Linux, but I ran into an anomaly which has made me
stop short.

My plan of action was:
1. Move all files and folders from E: (an NTFS logical drive
in my extended partition) to other logical drives.
2. Delete E:.
3. Create a new drive E: with FAT32 file system.
4. Move contents back to E:.

But after moving everything out of E:, Windows still reports
376MB of data on E:!!! No files, no folders, just "376MB used"!
That makes no sense to me at all! I could see a few hundred
bytes of space used at track 0 of the logical drive for
indexing purposes, but not 376MB.

Is there a reasonable explanation for this, or is something
screwed up on my system? I don't want to delete E: until
I know I'm not deleting 376MB of actual data (such as "lost"
files that somehow got "detached" from the file allocation
table, or whatever NTFS uses in place of a FAT).

Very curious,
Robbie Hatley
Tustin, CA, USA
email: lonewolfintj at pacbell dot net
web: home dot pacbell dot net slant earnur slant
 
D

Dave Patrick

Schedule chkdsk /f on the drive. Then check the application log for the
result.

--

Regards,

Dave Patrick ....Please no email replies - reply in newsgroup.
Microsoft Certified Professional
Microsoft MVP [Windows]
http://www.microsoft.com/protect
 
R

Robbie Hatley

I had mysterious "used" 376MB in a supposedly-empty logical drive,
and asked about it here.

Dave Patrick replied
Schedule chkdsk /f on the drive. Then check the application log
for the result.

OK. I ran chkdsk /f from cmd.exe. It didn't offer to schedule or
restart. It did balk about "volume in use", but it offered to
dismount the volume and I answered "yes". It printed:

%chkdsk e: /f
The type of the file system is NTFS.

Chkdsk cannot run because the volume is in use by another
process. Chkdsk may run if this volume is dismounted first.
ALL OPENED HANDLES TO THIS VOLUME WOULD THEN BE INVALID.
Would you like to force a dismount on this volume? (Y/N) y
Volume dismounted. All opened handles to this volume are now invalid.
Volume label is Kadath.

CHKDSK is verifying files (stage 1 of 3)...
File verification completed.
CHKDSK is verifying indexes (stage 2 of 3)...
Index verification completed.
CHKDSK is verifying security descriptors (stage 3 of 3)...
Security descriptor verification completed.

47239100 KB total disk space.
996 KB in 3 files.
700 KB in 12 indexes.
0 KB in bad sectors.
383876 KB in use by the system.
65536 KB occupied by the log file.
46853528 KB available on disk.

4096 bytes in each allocation unit.
11809775 total allocation units on disk.
11713382 allocation units available on disk.

wd=C:\
%

Chkdsk did not post any errors, warnings, or messages to the
system log.

So the question remains: Why is there still 383876KB
"in use by the system" if the volume is EMPTY??????????????

For that matter, why is there still 65536KB in an
invisible, unnamed "log file" that doesn't even show up
in explorer or cmd, if the volume is EMPTY??????????????

I tried running Norton SpeedDisk, just to get the disk map
with mouse-hover tool-tips showing what files each used
block is associated with. It does show dozens of blocks
all over the drive that are still in-use, but when I click
"optimize", the program hangs and hogs 100%CPU time apparently
forever. (Though I got tired of waiting after 20minutes and
pressed the "reset" button, which was the only way to stop
it, since it had locked out Ctrl-Alt-Del or Restart).

Perhaps I should try Win2k's built-in "Defragment" command
instead of Norton SpeedDisk, and see what that does.

Still VERY puzzled,
Robbie Hatley
Tustin, CA, USA
email: lonewolfintj at pacbell dot net
web: home dot pacbell dot net slant earnur slant
 
S

Steve Parry [MVP]

Robbie Hatley fumbled, fiddled and fingered:
I'm trying to back-convert a logical drive on my machine from
NTFS to FAT32, so that it will be accessible both from Win2K
and from Linux, but I ran into an anomaly which has made me
stop short.

My plan of action was:
1. Move all files and folders from E: (an NTFS logical drive
in my extended partition) to other logical drives.
2. Delete E:.
3. Create a new drive E: with FAT32 file system.
4. Move contents back to E:.

But after moving everything out of E:, Windows still reports
376MB of data on E:!!! No files, no folders, just "376MB used"!
That makes no sense to me at all! I could see a few hundred
bytes of space used at track 0 of the logical drive for
indexing purposes, but not 376MB.

Is there a reasonable explanation for this, or is something
screwed up on my system? I don't want to delete E: until
I know I'm not deleting 376MB of actual data (such as "lost"
files that somehow got "detached" from the file allocation
table, or whatever NTFS uses in place of a FAT).


NTFS MFT?

http://support.microsoft.com/default.aspx?scid=kb;en-us;Q174619

--
Steve Parry BA (Hons) MCP MVP


http://www.gwynfryn.co.uk

http://www.petitiononline.com/X30WM5/petition.html
 
R

Robbie Hatley

Regarding my 376MB "used" space in a (supposedly) emapty NTFS

Fascinating article. Thanks. I see the problem:

======================= BEGIN QUOTE ===================================

NTFS Master File Table (MFT) Expansion
When an NTFS volume is first created and formatted, NTFS metafiles are created. One of these metafiles is called the
Master File Table (MFT). It is very small when first created (approximately 16 KB), but it grows as files and
directories are created on the volume. When a file is first created, it is entered into the MFT as a File Record Segment
(FRS), which is always 1024 bytes (1 KB) in size. As files are added to the volume, the MFT grows as required. However,
when files are deleted, the associated FRSs are marked as free to be reused, but the total FRSs and associated MFT
allocation remains. This explains why, after deleting a large number of files, you don't regain the space used by the
MFT.

To see exactly how large the MFT is, you can use the built-in defrag utility to analyze the volume. The resulting defrag
report provides detailed information about the size and number of fragments in the MFT.

EXAMPLE:


Master File Table (MFT) fragmentation
Total MFT size = 26,203 KB
MFT record count = 21,444
Percent MFT in use = 81 %
Total MFT fragments = 4
However, for a more complete picture of how much space (overhead) is being used by the entire NTFS file system,
perform a chkdsk, and then look at the resulting output for the following line:
In use by system.
Currently, only third-party defrag utilities consolidate unused MFT FRS records and reclaim unused MFT allocated space.

====================== END QUOTE =================================================

Which means, I maybe should have been more patient with my SpeedDisk,
and let it finish analyzing the drive. But since I was going to delete
the drive anyway and replace it with a FAT32 drive (for Linux compatibility),
as soon as I was certain the 376MB "used" space truly was old junk system
files, I just deleted the whole thing. But thanks for the fascinating link.


Cheers,
Robbie Hatley
Tustin, CA, USA
email: lonewolfintj at pacbell dot net
web: home dot pacbell dot net slant earnur slant
 
R

Robbie Hatley

Steve Parry said:
NTFS MFT?

Yep. Bloated to the size of "MFT from Hell", because I had
just moved 35GB of files from the partition, but apparently,
according to MS's website, NTFS's MFTs never shrink, except
when defragged with certain 3rd-party defraggers. So I
basically had an index to tens of thousands of non-existant
files. All fixed now, though.


Cheers,
Robbie Hatley
Tustin, CA, USA
email: lonewolfintj at pacbell dot net
web: home dot pacbell dot net slant earnur slant
 
D

Dave Patrick

You're welcome.

--

Regards,

Dave Patrick ....Please no email replies - reply in newsgroup.
Microsoft Certified Professional
Microsoft MVP [Windows]
http://www.microsoft.com/protect

:
| Regarding my 376MB "used" space in a (supposedly) emapty NTFS
| logical drive, Dave Patrick wrote:
|
| > http://support.microsoft.com/?kbid=303079
|
| Fascinating article. Thanks. I see the problem:
|
| ======================= BEGIN QUOTE ===================================
|
| NTFS Master File Table (MFT) Expansion
| When an NTFS volume is first created and formatted, NTFS metafiles are
created. One of these metafiles is called the
| Master File Table (MFT). It is very small when first created
(approximately 16 KB), but it grows as files and
| directories are created on the volume. When a file is first created, it is
entered into the MFT as a File Record Segment
| (FRS), which is always 1024 bytes (1 KB) in size. As files are added to
the volume, the MFT grows as required. However,
| when files are deleted, the associated FRSs are marked as free to be
reused, but the total FRSs and associated MFT
| allocation remains. This explains why, after deleting a large number of
files, you don't regain the space used by the
| MFT.
|
| To see exactly how large the MFT is, you can use the built-in defrag
utility to analyze the volume. The resulting defrag
| report provides detailed information about the size and number of
fragments in the MFT.
|
| EXAMPLE:
|
|
| Master File Table (MFT) fragmentation
| Total MFT size = 26,203 KB
| MFT record count = 21,444
| Percent MFT in use = 81 %
| Total MFT fragments = 4
| However, for a more complete picture of how much space (overhead) is being
used by the entire NTFS file system,
| perform a chkdsk, and then look at the resulting output for the following
line:
| In use by system.
| Currently, only third-party defrag utilities consolidate unused MFT FRS
records and reclaim unused MFT allocated space.
|
| ====================== END QUOTE
=================================================
|
| Which means, I maybe should have been more patient with my SpeedDisk,
| and let it finish analyzing the drive. But since I was going to delete
| the drive anyway and replace it with a FAT32 drive (for Linux
compatibility),
| as soon as I was certain the 376MB "used" space truly was old junk system
| files, I just deleted the whole thing. But thanks for the fascinating
link.
|
|
| Cheers,
| Robbie Hatley
| Tustin, CA, USA
| email: lonewolfintj at pacbell dot net
| web: home dot pacbell dot net slant earnur slant
|
|
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top