Re: CLOSE SESSION failed with SK=5h/INVALID FIELD IN CDB: not harmless?

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 <[email protected]>
  "We can't solve today's problems by using the same thinking we
   used in creating them." - Einstein