Messages in this thread |  | | From | Matthias Urlichs <> | Subject | Re: "raw" block devices? | Date | 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
|  |