> While I would not like to introduce something that costs factor of 10 I think > CMS EDF is not a high-performance file system and neither is cmsfs-fuse for > various reasons.
Natively EDF is pretty good as single user OSes go. CMS VSAM... well, there's a tale for others to tell. > That would not be possible since files (and also FST's and the allocation map) > could consist of (nearly) any block on the disk so they are not contiguous. > And mmap'ing single blocks would not be worth the effort. 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. Look at how DIAG 250 works in the CP Programming Services manual to get an idea of a way to approach this with minimum memory usage. The way DIAG 250 handles it (essentially assemble a list of block operations (read AND write) and a memory buffer to populate, then execute the I/O to fill the buffer, then hand it back to the application logic to parse the memory buffer) is extremely efficient on memory and CPU, works nicely on LPAR and VM, and would work equally well for the minidisk access routines and file access (both read-only and read-write). The FST gives you sufficient information to determine the size of the buffer needed to mmap the file you're accessing (in Mark's example case of a large disk with lots of small files on it -- probably the most common use case IMHO -- you probably want one or maybe two files off that disk). Note: I'm talking about only the I/O list logic in the DIAG 250 description -- I am explicitly *not* asking you to do a clone of DIAG 250.. 8-) That gives you a use-only-what-you need approach and then the size of the minidisk doesn't ever matter. -- db
