[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Growisofs input cache (get away from dd?)


> >   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 :)


Reply to: