RE: stat(), st_size and st_allocsize

[Scott Klement <klemscot@xxxxxxxxxxxx>]

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.
>