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. ------------------------------------------------ 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. 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. 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. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org