On Thursday, 03/02/2006 at 08:42 CET, Rob van der Heij <[EMAIL PROTECTED]> wrote: > No, it's not a trick question. I meant to show that Alan's "you do not > need to know how it works because it is good like this" approach is > not valid and you asking for a "formula" is natural. When we know how > it works, we can predict the outcome of a change. > This is why people bother to predict how many blocks a file of n > records will take on disk, so that you can predict whether it will > fit. Writing until it fills and bail out is not always an option. > > When the curves have jumps, it becomes almost impossible to aim right. > In this case, you would be tempted to think 60+5 = 65 (plus a little > bit) but crossing the 64M boundary makes you switch gears with some of > the reservations.
Mine heart is pierce'd by thine arrow, Sir. :-) A looooong time ago I learned "why ask why? but go ahead and ask anyway as you might learn something". I was actually curious and immediately struck by the opposite condition we had on CMS and thought it'd be good for a laugh. Indeed, I should have inserted a smiley face. ;-) A *typical* Linux application could not really use "real memory size" in a meaningful way. It is indeed like your disk example. Being able to find out how many cylinders are on a disk doesn't tell you how much data you can actually store on it unless you have an initimate understanding of the file system du jour's internals and the disk geometry. That makes me wonder how a Linux application might compute available disk space on a directory that is, in fact, an NFS-mounted CMS disk. Anyway.... That said, these factoids are *very* useful when you want to handle the disk, memory, or CPU as containers rather than as a usable resources (files, data structures, and threads). The app might say, "I don't care how big it is, I just want another one the same size." or "20% more, please", yet be required to express those requests in absolute values. In this particular case I would expect that platforms that don't have a bios-like interface would be very happy if Linux took stock of its physical surroundings (peripherals, CPUs, and memory configuration). Not everyone has "hcp" or "vmcp" as a Plan B, and there certainly isn't an architected bios for virtualization. (Not yet, anyway. It seems obvious to me that Linux needs a generic "talk to hypervisor" function to handle all the things that architects forget when they're designing the Next Great Utopia. :-) ) Alan Altmark z/VM Development IBM Endicott ---------------------------------------------------------------------- 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
