NTFS in XP

[Guest]

Archived from groups: microsoft.public.windowsxp.general,microsoft.public.windowsxp.help_and_support (More info?)

Hi Ken,

You are right. That is the reason I asked how do I convert the FAT32
Partitions (D:, E: etc. As My C: - The XP Partition is already 4K NTFS) to
4K NTFS without loosing Data.
Please suggest.

Thanks
Prabhat


"Ken Blake" <kblake@this.is.an.invalid.domain> wrote in message
news:OervRFLgFHA.2700@TK2MSFTNGP15.phx.gbl...
> In news:75237028-FADF-49DA-854B-28BBED68129C@microsoft.com,
> Manny Borges <MannyBorges@discussions.microsoft.com> typed:
>
> > About that4 k and 512byte cluster size reported.
> >
> > I am going to make an assumption that is the only one that
> > makes
> > sense. Either A: you did a convert of C: and a straight format
> > of the
> > others, or you used a third party utility to do theother three
> > partitions.
> >
> > 512B is a better cluster size than 4K. It is smaller and more
> > efficient.
>
>
> More efficient with regard to wasting less space to cluster
> overhang (or "slack"), but it requires extra I/O and can result
> in considerably poorer performance. Especially in these days of
> very inexpensive hard drives, worrying about a small difference
> in waste due to the amount of slack is counterproductive.
>
> The total amount of slack on your drive is roughly half the
> cluster size times the number of files. Even if one has as many
> as 500,000 files, that's 128,000,00 bytes of slack for 256byte
> clusters, and 1GB for 4K clusters. So the savings with 512-byte
> clusters is 7/8 of a GB (probably less, because most people won't
> have as many as 500,000 files).
>
> These days hard drives sell for $1 US per GB, or less. I saw an
> ad just this morning for a 160GB drive on sale for $40, or $.25 a
> GB. The savings by using the smaller clusters is well under $1's
> worth of disk space. For almost everyone, that's insignificant;
> far better to worry about the performance implications of smaller
> clusters. 4K is a much better cluster size than 512 bytes.
>
>
> > It can lead to more fragmentation if you have large files,
> > but it gives you the ability to use all the space on your
> > drive.
>
>
> No it doesn't. No cluster size lets you use "all the space on
> your drive." Smaller cluster sizes let you use more of it, but
> "all" isn't possible.
>
> --
> Ken Blake - Microsoft MVP Windows: Shell/User
> Please reply to the newsgroup
>
>

 

[Guest]

Archived from groups: microsoft.public.windowsxp.general,microsoft.public.windowsxp.help_and_support (More info?)

In news:eIU28OTgFHA.2880@TK2MSFTNGP14.phx.gbl,
Prabhat <not_a_mail@hotmail.com> typed:

> Hi Ken,
>
> You are right. That is the reason I asked how do I convert the
> FAT32
> Partitions (D:, E: etc. As My C: - The XP Partition is already
> 4K
> NTFS) to 4K NTFS without loosing Data.
> Please suggest.


Read http://www.aumha.org/a/ntfscvt.htm which talks about the
issue regarding cluster size.



Also note that conversion is a big step, affecting everything on
your drive. When you take such a big step, no matter how
unlikely, it is always possible that something could go wrong.
For that reason, it's prudent to make sure you have a backup of
anything you can't afford to lose before beginning.


--
Ken Blake - Microsoft MVP Windows: Shell/User
Please reply to the newsgroup


> "Ken Blake" <kblake@this.is.an.invalid.domain> wrote in message
> news:OervRFLgFHA.2700@TK2MSFTNGP15.phx.gbl...
>> In news:75237028-FADF-49DA-854B-28BBED68129C@microsoft.com,
>> Manny Borges <MannyBorges@discussions.microsoft.com> typed:
>>
>>> About that4 k and 512byte cluster size reported.
>>>
>>> I am going to make an assumption that is the only one that
>>> makes
>>> sense. Either A: you did a convert of C: and a straight
>>> format
>>> of the
>>> others, or you used a third party utility to do theother
>>> three
>>> partitions.
>>>
>>> 512B is a better cluster size than 4K. It is smaller and more
>>> efficient.
>>
>>
>> More efficient with regard to wasting less space to cluster
>> overhang (or "slack"), but it requires extra I/O and can
>> result
>> in considerably poorer performance. Especially in these days
>> of
>> very inexpensive hard drives, worrying about a small
>> difference
>> in waste due to the amount of slack is counterproductive.
>>
>> The total amount of slack on your drive is roughly half the
>> cluster size times the number of files. Even if one has as
>> many
>> as 500,000 files, that's 128,000,00 bytes of slack for 256byte
>> clusters, and 1GB for 4K clusters. So the savings with
>> 512-byte
>> clusters is 7/8 of a GB (probably less, because most people
>> won't
>> have as many as 500,000 files).
>>
>> These days hard drives sell for $1 US per GB, or less. I saw
>> an
>> ad just this morning for a 160GB drive on sale for $40, or
>> $.25 a
>> GB. The savings by using the smaller clusters is well under
>> $1's
>> worth of disk space. For almost everyone, that's
>> insignificant;
>> far better to worry about the performance implications of
>> smaller
>> clusters. 4K is a much better cluster size than 512 bytes.
>>
>>
>>> It can lead to more fragmentation if you have large files,
>>> but it gives you the ability to use all the space on your
>>> drive.
>>
>>
>> No it doesn't. No cluster size lets you use "all the space on
>> your drive." Smaller cluster sizes let you use more of it, but
>> "all" isn't possible.
>>
>> --
>> Ken Blake - Microsoft MVP Windows: Shell/User
>> Please reply to the newsgroup

 

[Guest]

Archived from groups: microsoft.public.windowsxp.help_and_support,microsoft.public.windowsxp.general (More info?)

Hi, I will also try to get details about the NTFS Compression - Its
Advantages and Disadvantages etc etc.
Thanks for the Info.Prabhat

> If your files are compressible compression gives you fwere fragments,
> also. Think about it. Life's full of tradeoffs. You could experiment
> and benchmark but I doubt you'd see any performance difference.
>
> I had an application reading GB-sized files containing only numbers
> that was bottlenecked on I-O. NTFS compression reduced the file size
> by a factor of 10 and sped the application significantly. YMMV
>

 

[Guest]

Archived from groups: microsoft.public.windowsxp.help_and_support,microsoft.public.windowsxp.general (More info?)

So glad someone else has seen this also.

I have been saying for a long time that the CPU compressing and
decompressing a smaller file is speedier than the hard drive reading/writing
the original larger file. The hard drive is the slowest peripheral in the
data chain. RAM, CPU, FSB - they all are many times faster that a hard
drive. And they run at their specified speeds constantly. A hard drive has
"moments" of greater speed in bursts.

--
Regards,

Richard Urban

If you knew as much as you thought you know,
You would realize that you don't know what you thought you knew!


"Al Dykes" <adykes@panix.com> wrote in message
news:dadrq7$22b$1@panix5.panix.com...
> In article <ODhBvLTgFHA.2372@TK2MSFTNGP14.phx.gbl>,
> Prabhat <not_a_mail@hotmail.com> wrote:
>>> Higher fragmentation if 512K clusters are used, but it will be more
>>> space
>>> efficient.
>>>
>>> And NTFS compression does not work on drives with less than 4K cluster
>>size.
>>>
>>
>>Thanks for the Info.
>>I wanted to go for Good Performance (Not spece efficient - because now
>>storage media is becomming less price) and Of course LESS Fragements. So I
>>sould go for 4K instead of 512bytes.
>>
>>Thanks
>>Prabhat
>>
>>
>
>
> If your files are compressible compression gives you fwere fragments,
> also. Think about it. Life's full of tradeoffs. You could experiment
> and benchmark but I doubt you'd see any performance difference.
>
> I had an application reading GB-sized files containing only numbers
> that was bottlenecked on I-O. NTFS compression reduced the file size
> by a factor of 10 and sped the application significantly. YMMV
>
>
> --
> a d y k e s @ p a n i x . c o m
>
> Don't blame me. I voted for Gore.

 

[Guest]

Archived from groups: microsoft.public.windowsxp.help_and_support,microsoft.public.windowsxp.general (More info?)

In news:OmL$ZqagFHA.3316@TK2MSFTNGP14.phx.gbl,
Richard Urban <richardurbanREMOVETHIS@hotmail.com> typed:

> So glad someone else has seen this also.
>
> I have been saying for a long time that the CPU compressing and
> decompressing a smaller file is speedier than the hard drive
> reading/writing the original larger file.


My usual answer is "it depends." Here's some text I've posted on
this subject:

"There's a tradeoff involved. It takes time to compress and
uncompress a file each time you use it, and that slows you down.
But a compressed file is smaller and can be read and written
faster, and that speeds you up.

Which factor is more significant depends on the relative speeds
of your CPU and disk drive, but on most modern computers, it's
probably a near wash."


--
Ken Blake - Microsoft MVP Windows: Shell/User
Please reply to the newsgroup




> The hard drive is the
> slowest peripheral in the data chain. RAM, CPU, FSB - they all
> are
> many times faster that a hard drive. And they run at their
> specified
> speeds constantly. A hard drive has "moments" of greater speed
> in
> bursts.
>
> "Al Dykes" <adykes@panix.com> wrote in message
> news:dadrq7$22b$1@panix5.panix.com...
>> In article <ODhBvLTgFHA.2372@TK2MSFTNGP14.phx.gbl>,
>> Prabhat <not_a_mail@hotmail.com> wrote:
>>>> Higher fragmentation if 512K clusters are used, but it will
>>>> be more
>>>> space
>>>> efficient.
>>>>
>>>> And NTFS compression does not work on drives with less than
>>>> 4K
>>>> cluster size.
>>>
>>> Thanks for the Info.
>>> I wanted to go for Good Performance (Not spece efficient -
>>> because
>>> now storage media is becomming less price) and Of course LESS
>>> Fragements. So I sould go for 4K instead of 512bytes.
>>>
>>> Thanks
>>> Prabhat
>>>
>>>
>>
>>
>> If your files are compressible compression gives you fwere
>> fragments,
>> also. Think about it. Life's full of tradeoffs. You could
>> experiment
>> and benchmark but I doubt you'd see any performance
>> difference.
>>
>> I had an application reading GB-sized files containing only
>> numbers
>> that was bottlenecked on I-O. NTFS compression reduced the
>> file size
>> by a factor of 10 and sped the application significantly. YMMV
>>
>>
>> --
>> a d y k e s @ p a n i x . c o m
>>
>> Don't blame me. I voted for Gore.

 

[Guest]

Archived from groups: microsoft.public.windowsxp.general,microsoft.public.windowsxp.help_and_support (More info?)

Hi, Thanks for the suggestion. Prabhat

>
> Read http://www.aumha.org/a/ntfscvt.htm which talks about the
> issue regarding cluster size.
>
>
>
> Also note that conversion is a big step, affecting everything on
> your drive. When you take such a big step, no matter how
> unlikely, it is always possible that something could go wrong.
> For that reason, it's prudent to make sure you have a backup of
> anything you can't afford to lose before beginning.
>
>
> --
> Ken Blake - Microsoft MVP Windows: Shell/User
> Please reply to the newsgroup

 

[Guest]

Archived from groups: microsoft.public.windowsxp.general,microsoft.public.windowsxp.help_and_support (More info?)

In news:OQ$u0ofgFHA.1444@TK2MSFTNGP10.phx.gbl,
Prabhat <not_a_mail@hotmail.com> typed:

> Hi, Thanks for the suggestion. Prabhat


You're welcome. Glad to help.

--
Ken Blake - Microsoft MVP Windows: Shell/User
Please reply to the newsgroup


>> Read http://www.aumha.org/a/ntfscvt.htm which talks about the
>> issue regarding cluster size.
>>
>>
>>
>> Also note that conversion is a big step, affecting everything
>> on
>> your drive. When you take such a big step, no matter how
>> unlikely, it is always possible that something could go wrong.
>> For that reason, it's prudent to make sure you have a backup
>> of
>> anything you can't afford to lose before beginning.
>>
>>
>> --
>> Ken Blake - Microsoft MVP Windows: Shell/User
>> Please reply to the newsgroup