rayan@ai.toronto.edu (Rayan Zachariassen) (04/13/89)
[ anything in "'s are quotations from private responses, anything in >'s are quotations from the info-iris list. ] SGI will follow market pressures as to their OS base. [ Someone should consider this as market pressure... ] SGI does not track MIPS OSs, they do track MIPS compilers. SGI is working on Berkeley style sysadmin tools, per request from customers. [ :-) ] The lost packet problem should be fixed in the 3.2 release out this summer. Seemingly it has to do with DMA contention problems when the graphics subsystem and the ethernet butt heads. The fix involves both hardware and software. If the Gods are willing and the moon is in the right phase, Sun diskless client support is supposed to be released with the 4.0 OS (I assume this means the SVR4 base). However it is apparently quite possible (i.e. it has been done) to run a diskless client right now as long as it can get its boot information from a Sun somewhere on the network. The major stumbling block for SGI to provide this support are administration (i.e. handholding) and logistics (i.e. how the heck does one read a Sun tape onto an SGI box :-). (which, incidentally, is a good real question...) "We publish a demonstrated MTBF number for all machines. PowerSeries products are rated for at least 6000 hours." Fine-grained parallellism: "The lightweight process stuff was modelled after the work at several other companies, including Cray, Sequent, and work at Argonne. We haven't had any complaints about it. And the parallelizing Fortran compiler uses it easily. C programmers use it with great success, too." "Its better, of course! :-). The thread implementation has been published in USENIX proceedings, etc.. It provides a much more natural model for multi threaded applications than any other model I know of. We also support a layer of synchronization using spinlocks and semaphores that religiously avoids kernel interaction. Remember that syncrhonization latency is the chief problem in getting high performance from fine-grained parallelism. On top of this are some of our primitives, plus the Sequent m_* routines for simple parallel programming." "In the environment, we support a multi-process asynchronous debugger which works on normal and "threaded" processes (Sun, Mach don't!). The profiler handles a threaded process correctly. All this is integrated with the normal high-performance MIPS compilers." Filesystem: ... the barrage: "The filesystem is quite fast and quite reliable for us." "Why worry? The SGI ExtentFileSystem is >faster< than the BSD FFS." "Why do you care what the filesystem format is like, as long as it is fast and reliable?" "EFS may seem gratuitously NIH, but it beats FFS on comparable disk/controller combinations. Its reputation may be due in part to the lack of a good fsck. EFS's fsck is derived from SVR0's!" It is totally irrelevant to us that EFS may be faster better stronger. It is different. We care because we have tools that know about the (BSD) filesystem. We *HAVE TO* port some of those tools to any SGI box we would use for timesharing. Because the filesystem is *different*, the porting complexity goes way up. If EFS is better, wonderful, it is good to know its there if we need it and are willing to pay the price, but it shouldn't be foist (or forced) upon us. In response to that: "You might find that your tools will have difficulties poking around in super blocks and so forth on any machine except the original on which they were developed. Even in the most standard ... file system, ..., there are plenty of variations in the shape of things." Yes, this is true to a certain extent. However the differences will be at user-level and will be relatively easy to circumvent -- plus the knowledge base (in people) doesn't need to be updated. Miscellaneous: > 'tar' is not a backup program, no matter who thinks so. Nothing that goes through the filesystem (tar, cpio, bru) is an acceptable backup program in a large installation. > The filesystem does not appear to be BSD FFS, something which > becomes an issue real fast with a lot of users. Only if the not-FFS filesystem is the V7/SV filesystem. Our concern is not that it is slow (lots of people assert it isn't). > If you use Sun's yp, you're in for a lot of fun. Yah, which is why we refuse to use it on our Suns. "Higher ups at SGI do appreciate how competitive the 4D/220 and 240 are as computing engines. ... We regularly beat Alliant, Ardent, Convex, and Stellar." All these boxes are "computing engines", dedicated to a few people at a time who do their own maintenance and put the box beside their desk or in a closet nearby. SGI machines are getting interesting in another market, the one that used to embrace the VAX780, then the Sun3/280 and the Sun4/280 (gosh, I guess the next decade will see '90-suffix machines on top :-) for general purpose timesharing. The needs of this market are different. Software needs to fit into a pre-existing environment, hardware should fit into a rack (that's a hint...), decisions are made based on lots of factors that are irrelevant to the guy who wants fast graphics. It is a "professional" (in the positive sense of the word) systems environment, with competent technical support. Priorities are different when you have to provide a reliable and useful computing service to hundreds or thousands of people. My impression is still that SGI thinks of itself as a workstation company, and I really wish it would recognize this one of its opportunities (and if so, let us know). "I guess it's also the assumption that since we went standard we don't have any BSD compatibility. We have lots, except for the system administration end of things." Guess who makes the purchase recommendations ... (ex-)sysadmins. In every market. The more BSD environments you sell or can sell into, the more important it is that "administration" (booting, accounting, spooling, etc) looks like BSD, for that market segment at least. I replied to everyone who sent comments and thanked them privately. Here is a Thank You in public. I only lament that noone responded who was in a similar situation as us; are we really the pioneers? Most of the respondents were from SGI... the openness, responsiveness, and enthusiasm of the SGI people reading info-iris is one of the reasons we are interested in their products. My conclusion: if we (or someone in our situation) can hang on until SVR4/IRIX4.0 comes out, then it should be ok after that (not that we won't still yell for complete future 4.xBSD compatibility :-). Until then it will be a hard road if we decide to take it. SGI people seem convinced it will be a rewarding one in the long run (err, rewarding to both parties ;-). rayan
madd@adt.UUCP (jim frost) (04/13/89)
>> 'tar' is not a backup program, no matter who thinks so. > >Nothing that goes through the filesystem (tar, cpio, bru) is an acceptable >backup program in a large installation. That's not so. It is possible (even pretty easy) to build a very good, very reliable backup program which works through the filesystem. Most of the information which is saved by dump can be gotten through the filesystem; I personally believe that the information which cannot be gotten is also unnecessary. The programs you mentioned are not acceptable because they provide little (if any) redundancy or error-recovery; if anything goes wrong with any part of them, you probably lost the whole backup or you'll be bit-fiddling to get the information that remains. I'm a bit surprised that no one has built The Better Backup Program yet. I expect that what will happen is one of these days I'm going to get fed up with dump and just build one. It almost happened once. Anyone who has any comments or ideas on what a backup program must/should have is encouraged to send them to me at madd@bu-cs.bu.edu; if "one of these days" becomes a reality they will be very useful. jim frost madd@bu-it.bu.edu
lamy@AI.UTORONTO.CA (Jean-Francois Lamy) (04/15/89)
In article <8904131500.AA20088@adt.uucp> adt!madd@bu-it.bu.edu (jim frost) writes: >>Nothing that goes through the filesystem (tar, cpio, bru) is an acceptable >>backup program in a large installation. > >That's not so. It is possible (even pretty easy) to build a very >good, very reliable backup program which works through the filesystem. Restoring access times properly is needed (without an additional system call and losing the ctime information). Dealing with files with holes is also mildly tricky (you do want restores of a dumped fs to fit back :-). But most of all, I don't think incurring the overhead of going through the file system is justifiable once you have large amounts of disk space. We've had a very busy Sun 4 go down a couple of times a month, dragging with it half of its partitions each time (bug in SunOS, that appears to have been fixed now). So we care *a lot* about backups. On all our machines we run a home grown incremental backup program 3 times a day and an incremental dump to disk every night, in addition to full tape dumps at least once a week. And believe us, all that paranoia has not been wasted... Jean-Francois Lamy lamy@ai.utoronto.ca, uunet!ai.utoronto.ca!lamy AI Group, Department of Computer Science, University of Toronto, Canada M5S 1A4