seifert@sun1.ruf.uni-freiburg.de (Ulrich Seifert) (09/15/90)
*** CORRECTED VERSION *** *** SORRY, LOOKS LIKE MY EDITOR DIDN'T LIKE TO SAVE THIS STUFF *** gordonl@microsoft.UUCP (Gordon LETWIN) writes: >This HPFS can be configured to do write behinds; I think that may be the >default. This delays writes until the disk goes idle for a couple of >seconds or until the data gets too old (risky to leave unwritten for >too long a period of time) or until the cache gets too dirty. The >performance effect of this is threefold: ... Gordon, thank you very much for your explanations. Although I haven't seen benchmark results for the performance of the cache system yet the technical part sounds very good. Maybe this is the right place to post a related question. Let us assume we have a power failure. Well, probably everybody thinks the damage arising from programs dieing unknowingly in the machine will b much bigger than everything what happens in the cache. Maybe, but if we are dng transaction processing we should be sure that the data safely arrive on the disk after a commit. I do *NOT* want to say that all caching with write behinds is nonsense. But maybe it is not really enough. I think there are many possible situations where an application should be notified that there is a problem with the power supply. Of course, I assume that the computer is equipped with an UPS (otherwise one shouldn't complain). Most of the UPSs give a kind of warning signal if anything is wrong. I think it would be a great idea for OS/2 to set up a watchdog kind of interface to the UPS and broadcast a *standard* message or warning to every active application (for example to the PM applications to begin with). The file subsystem could immediately save the cache and switch to a no-write-behind mode until the UPS signals that everything is o.k. again. (And OS/2 could send another standard message to the applications) The applications could write a kind of restart file for the case that the power doesn't stabelizes any more or ignore the message. The user could go and check the status of his coffee machine instead of hurrying from one machine to the next and shutting everything down in the correct order. Wouldn't that be fantastic (and maybe one argument more to give OS/2 a try?). What do you think out there, maybe we can convince IBM/Microsoft that such a thing is a must-have for a modern operating system. Ulf
mshiels@tmsoft.uucp (Michael A. Shiels) (09/16/90)
Lan Manager 2.0 does hava a UPS interface driver which shuts down the system upon loss of power.
gordonl@microsoft.UUCP (Gordon LETWIN) (09/18/90)
In article <1990Sep15.161438.15123@sun1.ruf.uni-freiburg.de>, seifert@sun1.ruf.uni-freiburg.de (Ulrich Seifert) writes: > > Maybe this is the right place to post a related question. > Let us assume we have a power failure. First, I should point out that HPFS addresses this concern in several ways. OS/2 allows you to specify that a file is "write through". This means that a write call won't return until the data is safely on the disk. This also includes updating the directory entry fields so that said data could be re-read if the power were to fail at that point. An app can set write through on a per handle basis or on a per application basis (i.e., "make any I/O I do be write through"). Finally, the user can specify that he doesn't want any write behinds. "No write behinds" isn't quite the same as "write through" in that it doesn't cause us to update the directory with every write operation and it won't cause us to write a sector if the program does just a 20 byte write, the way that write through would. Write through is used for critical data and it's also used to guarantee write ordering for folks who update, say, a database and then it's index. Write through can be turned on and off, but when you turn it on after being off it doesn't apply retroactively to writes made when it was off; you need to issue a per-file flush for that. Secondly, the HPFS disk structure uses signatures and double links so that CHKDSK can do a very good job of repairing the disk in case of any damage or in case of a power failure. For example, the first N characters of a file name are stored in a backup spot away from the directory so that if you had a directory sector go bad we can not only recover the data, as CHKDSK for FAT sometimes can, but we'll also recover the first N (13?) characters of the file name. If you wipe the superblock we can still reconstruct. If you wipe the root directory we can still reconstruct. The other suggestion was to have a UPS interface to notify applications that power is failing. This is an interesting idea. UPSs are currently rare enough, on individual machines, that few people would use this. UPSs are a lot more common on network servers, and it's my vague recollection (not at all sure) that our LanMan product does have some support interfrace for UPS power fail signals. If it doesn't then this is in the works. Individual users can easily write programs to monitor the UPS signal and to send a power fail pending notification to their apps for shutdown; all that we're missing here is that the OS doesn't provide the monitor app (it's pretty trivial) and we don't define the convention for what a power failing signal looks like... gordon letwin
ulnie@sun1.ruf.uni-freiburg.de (Ulf Niesar) (09/23/90)
15123@sun1.ruf.uni-freiburg.de> <57468@microsoft.UUCP> gordonl@microsoft.UUCP (Gordon LETWIN) writes: >Individual users can easily write programs to monitor the UPS signal and >to send a power fail pending notification to their apps for shutdown; >all that we're missing here is that the OS doesn't provide the monitor >app (it's pretty trivial) and we don't define the convention for what >a power failing signal looks like... In my original contribution I probably didn't make my point clear enough. (sorry, I had to use the ID ulrich.seifert since I didn't have access to the newsgroup myself at that time) The situation that I had in mind was the following. Let us assume we have a power fault. Well, everything is O.K. if the user sits in front of the machine and can shutdown everything before the batteries are going low. But the price you have to pay is quite high. First of all you have to assume that there is a user around (for example in my case the computer is running quite often numerical intensive computations in the background while I am busy with something else). Secondly, you have to get a quite powerful UPS since you have to keep the whole computer (including monitor) running for some time. Why is this? Well, if we put a power monitor into the system, the only message it can send to a (commercially bought) app is a WM_QUIT message. And I bet that most of the programs will come up with a dialog window asking you if you are really sure that you want to quit. This is the point now. You really have to sit in front of the computer otherwise the machine is likely to die with the question on the screen if you are really sure to leave the program. (Probably a nice fealing if you see that happening!) On the other hand if we have a kind of shutdown_message a program could really clean up everything and maybe write a restart file or whatever is a useful thing to do. If such a message is standardized probably all programs will use it in some way and the user is sure that his machine performs a shutdown without any loss of data. In fact, this can have an effect on the cost for an UPS. Now we don't have to connect the monitor with the UPS and it might be sufficient to put one of these new UPS cards into an empty slot and if the power really fails you have the battery for a very short period of time (which makes it unexpensive and small) but you are still sure that the system powers down nicely. All this can always be done with an application where you have the source available with a home made monitor for the power supply. But I think there is no chance with a commercial product. (And I really don't want to code everything myself) In my opinion it is really a good idea to install such a service inside the operating system. It would be even better if the OS would write a restart kind of file itself in case of a power fault and restart the active applications when the power is back. This could be done with a kind of standard option in order to indicate that the application is requested to read it's restart informations and to perform all the necessary operations to come back to the point where it was when the fault happened. By the way this could also be used for users who like to see the computer coming up at the point where they switched it off. Right now I think that such a protocol of sending an extra shutdown message to an application is a better idea than having OS freeze the state of the computer. Probably it is much easier for an application to handle some broken communications or other unpleasent things than for an OS. What about that? Stupid or not? Ulf
chapman@acf3.NYU.EDU (Gary Chapman) (04/04/91)
How can I do the following? I have a PS/2 model 80 with two 300 meg hard drives; the first is set up for dual boot for DOS and OS/2 1.3. The second drive has only been low-level formatted. When I installed 1.3, I did NOT install HPFS. I now wish to set up the second drive as an HPFS volume. Is the following the procedure I should follow: (1) run installation again, and choose to install HPFS (2) put IFS... line in config.os2 (3) run FDISKPM (or what?) Where will I get the HPFS option? Thanks for any info. - Gary Chapman, NYU
kevinj@unicorn.cc.wwu.edu (Kevin Johnson) (04/04/91)
chapman@acf3.NYU.EDU (Gary Chapman) writes: >How can I do the following? >I have a PS/2 model 80 with two 300 meg hard drives; the first is set up >for dual boot for DOS and OS/2 1.3. The second drive has only been >low-level formatted. When I installed 1.3, I did NOT install HPFS. >I now wish to set up the second drive as an HPFS volume. >Is the following the procedure I should follow: >(1) run installation again, and choose to install HPFS >(2) put IFS... line in config.os2 >(3) run FDISKPM (or what?) Where will I get the HPFS option? When you say it is low-level formatted I'm assuming that fdisk has *not* been run on it. If not, run it to get the partition(s) you eventually want. Once that is done, you can do the following: format x: /fs:hpfs (I'm sure that if I'm wrong about the fs option someone will let you know what it is really supposed to be). And as you noted earlier, you will also need the IFS line: IFS=C:\OS2\HPFS.IFS /AUTOCHECK:[drive letter(s)] In addition, you may want a cache specified (/CACHE:[number of kilobytes]) (goes on the IFS line above). --Kevin
efeustel@prime.com (Ed Feustel) (04/04/91)
Use the format command with /FS:HPFS. Ed
colin@la.excelan.com (Colin Goldstein) (04/06/91)
The News Manager) Nntp-Posting-Host: la Reply-To: colin@la.excelan.com (Colin Goldstein) Organization: Novell, Inc., San Jose, Ca References: <8650002@acf3.NYU.EDU> Date: Thu, 4 Apr 1991 16:22:58 GMT In article <8650002@acf3.NYU.EDU> chapman@acf3.NYU.EDU (Gary Chapman) writes: >How can I do the following? > >Is the following the procedure I should follow: > >(1) run installation again, and choose to install HPFS >(2) put IFS... line in config.os2 >(3) run FDISKPM (or what?) Where will I get the HPFS option? > NO. Simply format the second drive as HPFS. [C:\] format e: /FS:HPFS Colin -- /-------------------------------------------------------------------\ | The views expressed here are my own. | Norm, what are you | | They do not necessarily represent | up too??? | | the views expressed by my employer. | | | ---------------| My ideal weight if I | | colin@novell.com | Novell Inc., | were 11 feet tall. | | uunet!novell!colin | San Jose | - Cheers | \-------------------------------------------------------------------/