On Dec 15, 2011 7:05 PM, "David Boyes" <[email protected]> wrote:> > I guess I don't understand this comment. Mapping the label and running the FST to determine what blocks to map seems worthwhile, since you could use common code to mmap the blocks of files you want to read into a contiguous memory area for efficient access. I don't see why that couldn't be a contiguous struct in Linux space regardless of where the blocks actually are on the disk. For R/O access, you generally don't care about updates to the FST until the next access of the minidisk (standard CMS semantics), and for R/W, you have transactional control of the blocks updated, and you need to update the FST anyway, so you want to be able to run that chain efficiently to find the right places to update. >
As Jan points out the FST is fragmented. The purpose of mmap() is that you map all blocks in virtual mem and then simply access the blocks in memory. Linux does the I/O under the covers. Since your blocks can be anywhere on disk, you map the entire thing. To map just record 3-5 is no gain if you need to point still at the rest of the blocks. DIAG250 is a block driver, just like Linux can do. Extra work is to allocate memory to hold blocks while you work on them, make sure to flush the updated pages, etc. The approach to try map and take the long route as alternative is nice best of both, but double code. But maybe people will come up with real apps that take advantage of it. Rob ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
