Calculating NTFS overhead

Archived from groups: microsoft.public.win2000.file_system (More info?)

Are there a way to calculate the overhead in NTFS? I understand that the
MFT zone gets 12.5% initially(cf. <utckuqhj0q5p61@corp.supernews.com>), 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 pissed of sometimes that my caps lock key seems to get stuck.
6 answers Last reply
More about calculating ntfs overhead
  1. Archived from groups: microsoft.public.win2000.file_system (More info?)

    On 26 Jan 2005 10:23:42 GMT, Troels Ringsmose <please.reply@in.the.group.goat.cx> wrote:

    >Are there a way to calculate the overhead in NTFS? I understand that the
    >MFT zone gets 12.5% initially(cf. <utckuqhj0q5p61@corp.supernews.com>), 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
  2. Archived from groups: microsoft.public.win2000.file_system (More info?)

    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" <please.reply@in.the.group.goat.cx> wrote in message
    news:41f76fae$0$33779$c3e8da3@news.astraweb.com...
    > Are there a way to calculate the overhead in NTFS? I understand that the
    > MFT zone gets 12.5% initially(cf. <utckuqhj0q5p61@corp.supernews.com>),
    > 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 pissed of sometimes that my caps lock key seems to get stuck.
  3. Archived from groups: microsoft.public.win2000.file_system (More info?)

    Jerold Schulman <Jerry@jsiinc.com> wrote in
    news:1jffv0p7eb4gf2mabnb07g5973s353uipv@4ax.com:

    <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 pissed of sometimes that my caps lock key seems to get stuck.
  4. Archived from groups: microsoft.public.win2000.file_system (More info?)

    "Dan Lovinger [MSFT]" <danlo@online.microsoft.com> wrote in
    news:#mJyTi$AFHA.3596@TK2MSFTNGP12.phx.gbl:

    > 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 pissed of sometimes that my caps lock key seems to get stuck.
  5. Archived from groups: microsoft.public.win2000.file_system (More info?)

    In article <41f8972c$0$3957$c3e8da3@news.astraweb.com>,
    Troels Ringsmose <please.reply@in.the.group.goat.cx> wrote:
    >Jerold Schulman <Jerry@jsiinc.com> wrote in
    >news:1jffv0p7eb4gf2mabnb07g5973s353uipv@4ax.com:
    >
    ><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 pissed 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.
  6. Archived from groups: microsoft.public.win2000.file_system (More info?)

    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" <please.reply@in.the.group.goat.cx> wrote in message
    news:41f89c0c$0$42041$c3e8da3@news.astraweb.com...
    > "Dan Lovinger [MSFT]" <danlo@online.microsoft.com> wrote in
    > news:#mJyTi$AFHA.3596@TK2MSFTNGP12.phx.gbl:
    >
    >> 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 pissed of sometimes that my caps lock key seems to get stuck.
Ask a new question

Read More

File System NTFS Microsoft Windows