![]() Tuxera Extended Lifetime Support Program.Consumer electronics storage & connectivity.Microsoft NTFS by Tuxera Enterprise Edition.USB connectivity for storage, networking, & audio Predictable flash operations, safety-critical systems Industry-standard embedded file systems.(The hardware has no way to read or write a partial sector.) The C RTL will be going through the file cache too, so in addition to any buffering the library is doing, the first read() will slurp 64Kbytes into the file cache and subsequent read()'s will just copy data out of that buffer until it's been used up. The C RTL has its own buffering - after all you can read() just one byte, while the disk drive and its driver can only handle 512-byte chunks. If you tell the disk driver 'read 2K bytes, and here is the buffer to put it in', and it decides to do you a favor by reading 62K more, where would the driver put any additional data? Now read() is very far removed from the disk driver. Certainly this is true if it's using read() !Nor is the disk driver in a position to allocate extra memory that could be used for readahead buffers. The application for its part is probably doing blocking IO, so it'll never send another request anyway until it's been told the first one is done. Since most apps doing a series of simple read()'s tend to use the same buffer over and over again anyway, the latter is pretty much a showstopper for this idea. To do any aggregation, the second request would have to both a) address the next logical blocks on the disk following the first request, and b) specify a buffer in memory that immediately follows the first request's. The driver has no business delaying starting a request on the off chance that another request might show up soon. An I/O request to the disk driver is a direct command to the hard drive and the driver will start it immediately. I didn't say "nothing" would, I said the disk driver wouldn't. If it isn't, then it's up to Sybase, again regardless of the cluster size - EXCEPT that Sybase might be looking at the cluster size and adjusting its readahead sizes (if any) accordingly. Any ideas? If the OS file cache is involved, yes, regardless of the cluster size. > We are wondering if the 2k read from Sybase is turning out to be a > 64k read, with the rest (62k)cached in case the next read is for > the next 2k block. Databases generally bypass the OS's cache, preferring to do their own cacheing, so anything said about what the file cache does probably doesn't apply to Sybase. If you ask for 64 KB and none of it is in the cache, the cache will read 64 KB. This does NOT mean that if you read, say, 4 KB the OS will read 64 KB in addition - the OS will read 60 KB in addition. 192 KB if the app has opened the file with the sequential access flag. The cache tries to use buffers of up to 64 KB, regardless of cluster size, unless the current extent of the file ends too soon to allow that. ![]() There is both readahead and write-behind. Lots of "writes" and "reads" to the disk might just be copies to or from the cache buffers. > this probably applies to all NTFS MS OSs, no?Yes, and to all other file systems in the NT family too, and to the 9x family as well.> I'm 99% sure the I/Os will be as large as the driver can merge > together that the device supports, At the disk driver level requests can be up to 1 MB in length on most disk controllers, but there is no "merging" of requests. Does anybody know? If you read or write less than 64k, does the OS > read/write the whole 64k block, or is that just allocation size, > and I/O's are 512 byte (sector) I/Os? The latter.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |