On Mon, 7 Jan 2002 15:12, Hans Reiser wrote: > >I'm quite familiar with the hardware that Russell talks about (I've > >had to debug more than one borked CCW chain in my life ;). Although > >*conceptually* an indexed file is a directory, the IBM mainframe > >channel does some things that take the performance to another level. > >For starters, the disk is in 'count key data' (CKD) form - each disk > >block can be different lengths, and part of the block be a 'key' > >field. > > Is this really significant to performance? The cost of a seek is so > large compared to a partial block transfer....
However if you have a limited number of channels to transfer data (even mainframes have limits - usually imposed by the budget at purchase time) then you will not want to needlessly saturate them and require new hardware purchases. Currently with most PC-class systems (including rack-mount servers and almost all Linux machines) things are different, you can buy plenty of storage cheaply (even Ultra2 SCSI is cheap compared to mainframe attachments), but then again you get limited by motherboard IO bandwidth. The fact that most users of PC-type systems (myself included) never see enough system load to make this a problem is not relevant when you are considering what to do to get really serious performance. Currently if you want really serious FS performance on PC-type systems then you just give up and get a NetApp device or similar. ReiserFS is only one part of the solution to this problem, and the other parts aren't really there yet. > >3) For added fun, IBM systems like to keep track of 'cylinder track > >block' information for the data, since a file may have different-sized > >physical blocks, often formatted to fit exactly 3 to the track or > >similar. This became an issue for some places for Y2K conversions - if > >your data file fit exactly 3 to the track, and you had to find 6 more > >bytes, you had to overflow, fitting only 2 to the track with a lot of > >wasted space, and needing 50% more disk space. And if you used a hash > >function to compute the cyl/track/block of a file entry, you were in > >trouble.... > > disk geometry is usually not worth knowing and lied about by the hard > drive. I suspect that this is usually the case on mainframes too. Valdis? -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page
