Thomas Schmitt wrote:
Hi,
me:
Is there any way how after umounting of the
filesystem the content is still not up to date
for subsequent reading of the file ?
The image file got opened by growisofs via
open64(O_DIRECT|O_RDONLY).
Jens Jorgensen:
Well there's a scary thought. I guess I would hope that opening with
O_DIRECT would maybe cause a flush of dirty pages for this file?
It is only a shot in the dark.
One would have to test whether e.g. command sync
or umounting and remounting the hosting
filesystem would prepare the image file for
flawless copying to media.
With other image types there was never such
an effect. But a mounted UDF random access
filesystem might have its own i/o peculiarities.
O_DIRECT itself is still quite obscure to me.
The opinion on LKML is mainly against using it.
We have people here on this list who oppose
that opinion.
The reason to use O_DIRECT is to avoid impact on the performance of
other processes in the system, rather than to improve speed. By doing
io directly to user buffers data in system buffers used by most
programs is no overwritten. On an empty system O_DIRECT is slightly
slower than buffered io, unless asyncronous multiple buffers are used.
That's too complex for most people, and the slowdown is in the <10%
range, so burner buffers stay full.
------------------------------------------------
I had to explore the i/o behavior of growisofs
because on some hampered busses on Linux it was
faster with writing than libburn.
Using O_DIRECT on reading had only a slightly
accelerating effect on writing.
But it turned out that the main advantage of
growisofs is in buffer allocation via mmap()
which seems necessary with using O_DIRECT.
You can manually allocate a large buffer and then use bit operators to
force the address to be page aligned. Again, most user would rather use
mmap() which does that for you.
Such side effects are ill, of course. The CPU
is mainly idle. So something in the Linux i/o
is stumbeling over its own feet. This happens
quite often with USB busses but there are also
SATA and IDE connections which do not transmit
full 16x or 20x DVD speed.
Again, there's a reason for that, the max USB packet size is set to 64
by default, performance can be improved by setting to the max allowed
in the kernel, which was 256 the last time I looked. This makes a big
difference with some disks and tapes as well.
/sys/bus/usb/devices/usbX/bMaxPacketSize0
The best trick with such busses is to write
64 KB chunks rather than the usual 32 KB.
This normally beats O_DIRECT reading
significantly.
So i decided to use mmap() buffer, to offer
64 KB chunks optionally at run time and
O_DIRECT optionally at compile time.
--
Bill Davidsen <davidsen@tmr.com>
"We can't solve today's problems by using the same thinking we
used in creating them." - Einstein
|