Are there a way to calculate the overhead in NTFS? I understand that the
MFT zone gets 12.5% initially(cf. <(E-Mail Removed)>), but
is there some way of calculating the entire use?

--
Med Venlig Hilsen | Best Regards
Troels Ringsmose<ringsmose*AT*gmail*DOT*com>
I get so ****ed of sometimes that my caps lock key seems to get stuck.

On 26 Jan 2005 10:23:42 GMT, Troels Ringsmose <(E-Mail Removed)> wrote:

>Are there a way to calculate the overhead in NTFS? I understand that the
>MFT zone gets 12.5% initially(cf. <(E-Mail Removed)>), but
>is there some way of calculating the entire use?


See tip 697 in the 'Tips & Tricks' at http://www.jsiinc.com
See tip 5351
See tip 7891 for an example of scripting the extraction of the data you want.


Jerold Schulman
Windows Server MVP
JSI, Inc.
http://www.jsiinc.com

The MFT zone is not overhead. Its just the seperation between the initial
MFT and where the filesystem starts allocating for files. It will be used
for file data if the disk is filled. The reason the seperation is there,
initially, is to allow the MFT to grow in a contiguous allocation
(unfragmented).

--
Dan Lovinger
Microsoft Corporation
Please do not send e-mail directly to this alias. This alias is for
newsgroup purposes only.

"Troels Ringsmose" <(E-Mail Removed)> wrote in message
news:41f76fae$0$33779$(E-Mail Removed)...
> Are there a way to calculate the overhead in NTFS? I understand that the
> MFT zone gets 12.5% initially(cf. <(E-Mail Removed)>),
> but
> is there some way of calculating the entire use?
>
> --
> Med Venlig Hilsen | Best Regards
> Troels Ringsmose<ringsmose*AT*gmail*DOT*com>
> I get so ****ed of sometimes that my caps lock key seems to get stuck.

Jerold Schulman <(E-Mail Removed)> wrote in
news:(E-Mail Removed):

<SNIP>
>
>
> See tip 697 in the 'Tips & Tricks' at http://www.jsiinc.com
> See tip 5351
> See tip 7891 for an example of scripting the extraction of the data
> you want.
>
<SNIP>

well what I was really looking for was some kind of formula for
calculating the overhead, but extremely useful site though, one for the
bookmarks.

--
Med Venlig Hilsen | Best Regards
Troels Ringsmose<ringsmose*AT*gmail*DOT*com>
I get so ****ed of sometimes that my caps lock key seems to get stuck.

"Dan Lovinger [MSFT]" <(E-Mail Removed)> wrote in
news:#mJyTi$(E-Mail Removed):

> The MFT zone is not overhead. Its just the seperation between the
> initial MFT and where the filesystem starts allocating for files. It
> will be used for file data if the disk is filled. The reason the
> seperation is there, initially, is to allow the MFT to grow in a
> contiguous allocation (unfragmented).
>

thank you for correcting me, I hadn't thought of the difference. The reason
I called it overhead, was my urge to calculate the entire non-free part of
a volume. Is there some kind of formula? or am I completely daft?

--
Med Venlig Hilsen | Best Regards
Troels Ringsmose<ringsmose*AT*gmail*DOT*com>
I get so ****ed of sometimes that my caps lock key seems to get stuck.

In article <41f8972c$0$3957$(E-Mail Removed)>,
Troels Ringsmose <(E-Mail Removed)> wrote:
>Jerold Schulman <(E-Mail Removed)> wrote in
>news:(E-Mail Removed):
>
><SNIP>
>>
>>
>> See tip 697 in the 'Tips & Tricks' at http://www.jsiinc.com
>> See tip 5351
>> See tip 7891 for an example of scripting the extraction of the data
>> you want.
>>
><SNIP>
>
>well what I was really looking for was some kind of formula for
>calculating the overhead, but extremely useful site though, one for the
>bookmarks.
>
>--
>Med Venlig Hilsen | Best Regards
>Troels Ringsmose<ringsmose*AT*gmail*DOT*com>
>I get so ****ed of sometimes that my caps lock key seems to get stuck.


The 12% figure isn't really overhead (ie added to your data) because
files that are small onough to fit into an MFT slot are stored there,
eliminating the waste of a full cluster and a seek to get from the
index to the first block of the cluster. For someone with
lots and lots of small files it might be a wash.
--

a d y k e s @ p a n i x . c o m

Don't blame me. I voted for Gore.

If you're just asking what the overhead is on a volume you have in your
hand:

VolumeSize - SumOverAllFiles(filesize rounded up to cluster size)

Trying to go at it the other way, counting all of the bytes in this or that
stream of metadata (USN journal, MFT, directory index, security index, etc.)
will suffer from a lot of imprecision and just be a headache. File
fragmentation affects how many MFT file records are required to store the
allocation information for the file, you can't precisely predict the cutoff
for small files being embedded in their MFT record (as Al pointed out), and
so forth.

You can roughly, but reasonably, predict overhead at 1KB/file by just
accounting for the MFT record. Since all kinds of specific details factor
into this, it could just be easier for you to empirically derive the average
overhead given your volume usage pattern.

--
Dan Lovinger
Microsoft Corporation
Please do not send e-mail directly to this alias. This alias is for
newsgroup purposes only.

"Troels Ringsmose" <(E-Mail Removed)> wrote in message
news:41f89c0c$0$42041$(E-Mail Removed)...
> "Dan Lovinger [MSFT]" <(E-Mail Removed)> wrote in
> news:#mJyTi$(E-Mail Removed):
>
>> The MFT zone is not overhead. Its just the seperation between the
>> initial MFT and where the filesystem starts allocating for files. It
>> will be used for file data if the disk is filled. The reason the
>> seperation is there, initially, is to allow the MFT to grow in a
>> contiguous allocation (unfragmented).
>>
>
> thank you for correcting me, I hadn't thought of the difference. The
> reason
> I called it overhead, was my urge to calculate the entire non-free part of
> a volume. Is there some kind of formula? or am I completely daft?
>
> --
> Med Venlig Hilsen | Best Regards
> Troels Ringsmose<ringsmose*AT*gmail*DOT*com>
> I get so ****ed of sometimes that my caps lock key seems to get stuck.