Re: "raw" block devices?

Matthias Urlichs (smurf@mail.noris.net)
Thu, 17 Oct 1996 19:27:17 +0100


In linux.dev.kernel, article <ML-2.3.845567872.3978.davidm@fuzzbox.psrg.cs.usyd.edu.au>,
David Monro <davidm@fuzzbox.psrg.cs.usyd.edu.au> writes:
>
> Also this allows eg database systems to be given a slice of disk which they
> are in complete control of, and can maybe manage better than the normal
> buffering (known access patterns etc).
>
That's possible even with a "cooked" partition.

> 2) Because of the above, it should be possible to get data straight from the
> device into user memory without any copying.

You can always mmap things. Linus also saif that in the future, if you read
a page-sized and aligned chunk Linux is likely to just remap the page
instead of copying.

> Actually I guess what is needed is not necessarily a new device, but possibly
> an extra (non-portable, but hey) flag for open (and maybe mmap?) to say `don't
> cache this, I'm not going to see it again'. The device is just a way of
> saying this without having to code it in the program.
>
That might actually be a good idea.

> Am I missing something really obvious here? (Note - even if mmap didn't trash
> cache, which I am certain it does (page cache?) it doesn't work for this - try
> mmapping something >4Gb :-( )
>
Of course mmap works for data sets > 4 GBytes. You just need a 64-bit CPU...
...I expect Digital will happily sell you one. ;-)

Besides, llseek() also exists, and you can keep the control structures and
indices mmap()ed in the lower Gbyte and read() the actual data.

-- 
Set the cart before the horse.
               --John Heywood
-- 
Matthias Urlichs         \  noris network GmbH  /  Xlink-POP Nürnberg 
Schleiermacherstraße 12   \   Linux+Internet   /   EMail: urlichs@noris.de
90491 Nürnberg (Germany)   \    Consulting+Programming+Networking+etc'ing
   PGP: 1024/4F578875   1B 89 E2 1C 43 EA 80 44  15 D2 29 CF C6 C7 E0 DE
       Click <A HREF="http://info.noris.de/~smurf/finger">here</A>.    42