/dev/raw support?

[Alan Shutko]

PhiloVivero <pvspam-dntrepl at hacklab.net> writes:

> Sure. I looked. There's a lot of misinformation out there, and either he's
> unaware of the subtleties or it's a lot simpler than I think.

He's the block layer maintainer, ditto the IDE/ATAPI/SCSI CDROM
drivers maintainer.  If he's unaware of the subtleties, someone should
probably let him know.  8^)

>      mknod /dev/fd0 b 2 0
>      (=make node, as root) Manually create a device file. This example
>      shows how to create a device file associated with your first floppy
>      drive and could be useful if you happened to accidentally erase it.
>      The options are: b=block mode device, c=character mode device,
>      p=FIFO device, u=unbuffered character mode device.
> 
> Notice this device fd0 could be UNBUFFERED without dealing with
> /dev/raw*.

How?  If you tried to make /dev/fd0 (or any other block device) as an
unbuffered character device, the device node wouldn't work.  (Try it.)

> I'm fairly certain there's a chmod switch that'll do this, too.

I don't know of any, but I'd be happy to be corrected.

> Asynch/Synch I/O: Unimportant for DVD playback, but of utmost importance for
> RDBMS packages.

Agreed.  
> I have no clue what buffer vs. page cache is.

Basically, AIUI, the buffer cache is used to cache metadata and
block device reads, and the page cache holds all fs data and swap.
Here's a bit of a recent discussion that goes into it... iirc, the
rest of the thread expanded it.

http://www.uwsg.indiana.edu/hypermail/linux/kernel/0105.0/0558.html

> Look particularly at the section mentioning "O_SYNC" because this is what the
> chmod command I keep alluding to tweaks.

AFAIK O_SYNC merely means write won't return until things have hit the
disk... I do not think it prevents input caching.

Let me sum up the situation as I see it:

* Currently, playing DVDs with vlc causes all the stuff read off
  /dev/dvd to grow the buffer cache, at the expense of the page cache
  and unused application memory, decreasing system performance for
  other applications.  This buffering is completely _useless_, because
  we're not going back to read that stuff, at least not before it gets
  replaced.  For a sample, check free in normal usage and check the
  RAM in buffers.  (For me, it's around 2088k right now.)  Then watch
  a DVD and check it again.  For me, it capped around 70MB... 70MB of
  RAM wasted and unavailable for other uses while the DVD was
  streaming.

* Jens Axboe has said the solution is to use /dev/raw*.

* Other Linux DVD projects use /dev/raw*, and claim that it should
  increase playback performance somewhat (which I don't care about)
  but also system performance (which I do).

Basically, I just want to find some way not to buffer the DVD reads.
If you know of a way other than /dev/raw (which I don't understand
yet), I'd be quite happy.

(More information on the raw device is at
http://linuxtoday.com/stories/10698.html.)


-- 
Alan Shutko <ats at acm.org> - In a variety of flavors!
My idea of roughing it turning the air conditioner too low.