RE: stat(), st_size and st_allocsize

[Vernon Hamberg <vhamberg@xxxxxxxxx>]

NTFS uses space much more efficiently than FAT(32). The latter, esp., uses
large clusters (?) to handle large disks. So a 1-byte file could take 64k
of disk.

I wonder what file system is in use on Tom's Win2K box.

BTW, there is a function that returns all the file system characteristics.
It might be assuming a FAT-type file system. At any rate, I'm not sure
anything can be relied on through QNTC. Even CCSIDs don't get properly
registered, usually, and I don't know what it takes for that registration
(my term) to happen - I think something should happen at IPL, but ???

The 400 will try to use up to 128k blocks in I/O requests. But that will be
rare. It is desirable to minimize physical I/O, but only if all the data
can be used.  I.e., for really sequential access. I'd expect that SETOBJACC
uses this large block size for transfer of data.

At 03:51 PM 10/11/02 -0500, you wrote:

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