These days disks are virtualized. I think the unit is the track. Two "adjacent" tracks from a data set perspective could be on different PC sized disks in the disk subsystem. The "disks" are usually irrelevant as the data is usually in cache!. These days a "defrag" equivalent might be to free unused space in an over allocated dataset.
On Mon, 7 Aug 2023 at 23:06, Jon Perryman <jperr...@pacbell.net> wrote: > > On Thu, 20 Jul 2023 at 09:01, Rob van der Heij <rvdh...@gmail.com> > wrote: > > It would be interesting to see your evidence of IBM Z not performing > well with Linux. > > Linux on z performs better than Linux on most other hardware. My point is > that Linux wastes much of z hardware. > > Since I haven't seen Linux on z, I have to make some assumptions. It's > probably fair to say the Linux filesystem still uses block allocation. > Let's say it's a 10 disk filesystem and 100 people are writing 1 block > repeatedly at the same time. After each writes 10 blocks, where are the 10 > blocks for a specific user. In z/OS you know exactly where those blocks > would be in the file. If you read that file are these blocks located > sequentially. While the filesystem can make a few decisions, it's nothing > close to the planning provided by SMS, HSM, SRM and other z/OS tools. Like > MS Windows disks, Linux filesystems can benefit from defrag. Also consider > when Linux needs more CPUs than available. Clustering must be implemented > on Linux to increase the number of CPU which does not share the filesystem. > In z/OS, a second box has full access to all files because of Sysplex. > > I'm sure IBM has made improvements but some design limitations will be > difficult to resolve without the correct tools. For instance, can DB2 for > Linux on z share a database across multiple z frames. It's been a while > since I last looked but DB2 for z/OS was used because it outperformed DB2 > for Linux on z. >
