Hi, > > And for the ISO formatter it makes few > > sense to read O_DIRECT as it has a random access > > pattern on eventually small files. > It's not about size of individual files, but *sum* of their sizes.
The cache usage depends on the size, indeed. But won't reading lots of small files without memory cache be slow and disk clogging ? > if you generate image file (as opposite to > immediately burning it out), you double the > pressure on block cache as kernel would like to cache both files > you've read and recently generated portion of the image. Yes. I put load on the cache. But that's what it exists for. It shall smoothen random access disk reading at the expense of memory. > Meaning that O_DIRECT is not worse (modulo specific > and rare situations like one in originating report), > so why the fear?-) Because it is non-standard and a new idea. I am sneaking around it and sniff whether it might be edible. On the write side i rather use fsync() to avoid clogged buffers. Once per MB. On the read side it did not come to me to circumvent the cache. > As implied low memory condition on interactively used system. One can never have enough RAM :)) I will implement an O_DIRECT option on the read side and look whether i can see advantages on my system. On the write side with disk file objects, i will probably compare O_DIRECT with my periodic fsync(). (No fsync() and no O_DIRECT is bad if the disk is slow. The write buffer size becomes very obtrusive.) > there might be and are platform-specific > limitations on O_DIRECT usage, That's why i still poke the idea whether it could bite. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]