The [E]CKD model does not lend itself to this. I am not completely sure why (because the overhead of applying and then peeling off track and record boundaries doesn't seem to be THAT intrusive to cause so much pain).
Whether [E]CKD or FBA (eg: SAN), the main point is that you need larger volumes on the PV side of LVM. The quanta we're seeing for SAN is 9G or 18G at a minimum now, typically 36G for starters and upward. So help me out. I've said for years that we should dispose of count-key semantics (records, tracks, all the non-data stuff) when it's not needed. Have we actually now found a scalability issue related to that? If not that, then what is it causing the larger 3390 slices to slow down? SAN slices of that size don't slow down. Is it the channel? Is it the channel protocol? Is it in fact related to the non-data support? -- R; ---------------------------------------------------------------------- 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
