× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I wouldn't blame QNTC, but rather I'd blame the way DOS/Windows looks at
disks.

Though, I should qualify that I'm not familiar with how NTFS works...  I'm
only familiar with FAT and FAT32.

In a FAT filesystem, cluster size gets to be a big issue very quickly.
Back in the Win95 FAT16 days I wrote a program to calculate how much of my
disk space was being wasted by the 32k cluster size (which I needed to use my
1.6 gb drive) and found that I was wasting more than 20% of the disk space
due to the large cluster size.

When FAT32 came out it was a big improvement, because it could address
more clusters, and therefore you didn't need as large of a cluster size.
But again, we were working with 1.6 - 2 gig drives.  In today world, it
has again (IMHO) become a problem with drives getting up in the 80+ gig
range.

My guess is that the 68k cluster size you're seeing is just what Windows
is using, and is not QNTC's fault...


On Fri, 11 Oct 2002, Tom Liotta wrote:
>
> Your explanation matches with what I came up with as a working
> assumption, so I'll go with it.
>
> Two items come to mind: (1) A process that attempts to find how much
> space is being used overall should use st_allocsize rather than st_size.
> And (2) writes through /QNTC to a Win2K Server can result in very
> inefficient use of Win2K disk space.
>
> I ran various tests to Win2K and continually saw st_allocsize rapidly
> exceeding st_size as the file grew. Just from the single example I
> provided, you can see st_allocsize is almost seven times st_size. When I
> was trying closes and re-opens with O_APPEND, the size difference was
> worse. Wish I had time for a decent benchmark series.
>



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.