dave@westmark.UUCP (Dave Levenson) (09/20/87)
UNIX files may sit in kernel buffers long after the process who last
touched the file has terminated. The sync command flushes the
buffers, but unless you're planning to shut down, who uses it?
MS-DOS, also, buffers files, but flushes the buffers associated with
any given file when the file is closed. If you shutdown without
exiting the application, MS-DOS files get trashed, too. The apparent
robustness of MS-DOS files comes, I think, from the user's tendency
to exit the application, even if he doesn't shut down the system,
before powering down. MS-DOS has no shutdown command, so no need to
learn to use it.
Some versions of UNIX run a daemon which syncs the filesystem
periodically.
--
Dave Levenson
Westmark, Inc. A node for news.
Warren, NJ USA
{rutgers | clyde | mtune | ihnp4}!westmark!davesmvorkoetter@watmum.UUCP (09/21/87)
In article <174@westmark.UUCP-> dave@westmark.UUCP (Dave Levenson) writes:
-> UNIX files may sit in kernel buffers long after the process who last
-> touched the file has terminated. The sync command flushes the
-> buffers, but unless you're planning to shut down, who uses it?
In the UNIX course I took, I was taught that the buffers get flushed
every 30 seconds or so. I guess this is by the daemon you mention
below.
-> MS-DOS, also, buffers files, but flushes the buffers associated with
-> any given file when the file is closed. If you shutdown without
MS-DOS uses write through buffers. When you read a sector, it will check
if the sector is in a buffer, and read it from there if it is. When you
write a sector, it writes straight to the disk (AND the buffer). The file
will only be trashed if a crash occurs during the write.
-> exiting the application, MS-DOS files get trashed, too. The apparent
-> robustness of MS-DOS files comes, I think, from the user's tendency
-> to exit the application, even if he doesn't shut down the system,
-> before powering down. MS-DOS has no shutdown command, so no need to
-> learn to use it.
->
-> Some versions of UNIX run a daemon which syncs the filesystem
-> periodically.
-> --
-> Dave Levenson
-> Westmark, Inc. A node for news.
-> Warren, NJ USA
-> {rutgers | clyde | mtune | ihnp4}!westmark!dave
Stefan Vorkoetter
University of Waterloodave@micropen (David F. Carlson) (09/21/87)
In article <174@westmark.UUCP>, dave@westmark.UUCP (Dave Levenson) writes: > UNIX files may sit in kernel buffers long after the process who last > touched the file has terminated. The sync command flushes the > buffers, but unless you're planning to shut down, who uses it? > > Some versions of UNIX run a daemon which syncs the filesystem > periodically. > -- > Dave Levenson DOS keeps in in-core copy of the FAT, which is absolutely analogous to the in-core copy of the inode table and free list that UNIX maintains. The question is was means is used to flush them out and how much redundancy is built in. Note that FFS (Berkeleys fast file system) has multiple copies of the superblock information for some fault protection. Note also that Microport has "hardened" their filesystem by periodically syncing (I believe maximum sync time is ten seconds), thus your hard crash can only undo currently open files and those closed less than 10 seconds before the crash. The sync routine is also called using the <cntl><alt><del> sequence so you reboot with clean volumes. I have crashed our Microport systems and have experienced period power failures and I have found that their file system is not perfect but I claim better than normal system5 and Berkeley systems I have used before. I certainly have had DOS go "byebye" for some unknown reason and lost files. At least protected mode OS's don't go "byebye" with such frequency as a DOS system. -- David F. Carlson, Micropen, Inc. ...!{seismo}!rochester!ur-valhalla!micropen!dave "The faster I go, the behinder I get." --Lewis Carroll
iverson@cory.Berkeley.EDU (Tim Iverson) (09/22/87)
In article <1822@watcgl.waterloo.edu> smvorkoetter@watmum.waterloo.edu (Stefan M. Vorkoetter) writes: >MS-DOS uses write through buffers. When you read a sector, it will check >if the sector is in a buffer, and read it from there if it is. When you >write a sector, it writes straight to the disk (AND the buffer). The file >will only be trashed if a crash occurs during the write. Almost, but not quite. If you reboot with files open, the directory entry doesn't get updated (this happens when the file is closed, and since it wasn't closed, it doesn't get updated). All of the file is still on disk, its just that DOS no longer knows where it all is. Of, course, similar problems will occur on UNIX systems if you just randomly reboot - its just that there's rarely ever a need to do so on a protected system. - Tim Iverson iverson@cory.Berkeley.EDU ucbvax!cory!iverson
davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (09/22/87)
In article <174@westmark.UUCP> dave@westmark.UUCP (Dave Levenson) writes: |UNIX files may sit in kernel buffers long after the process who last |touched the file has terminated. The sync command flushes the |buffers, but unless you're planning to shut down, who uses it? | |MS-DOS, also, buffers files, but flushes the buffers associated with |any given file when the file is closed. If you shutdown without [ I don't *think* there is any write buffering in MS-DOS. There is buffering in most programs which write to files, but I see nothing to indicate that the data is not physicaly written when DOS is called. I suspect that mean the FAT, which gets updates when the file is closed. After the write, the data is available for rereading in the beffers defined by "BUFFERS=" ] |exiting the application, MS-DOS files get trashed, too. The apparent |robustness of MS-DOS files comes, I think, from the user's tendency |to exit the application, even if he doesn't shut down the system, |before powering down. MS-DOS has no shutdown command, so no need to [ I completely agree. ] |learn to use it. | |Some versions of UNIX run a daemon which syncs the filesystem |periodically. [ Other than in special maintenance modes, virtually all versions do this, and have for about ten years. ] |-- |Dave Levenson |Westmark, Inc. A node for news. |Warren, NJ USA |{rutgers | clyde | mtune | ihnp4}!westmark!dave -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
kimcm@ambush.UUCP (09/29/87)
In article <1822@watcgl.waterloo.edu> smvorkoetter@watmum.waterloo.edu (Stefan M. Vorkoetter) writes: >In the UNIX course I took, I was taught that the buffers get flushed >every 30 seconds or so. I guess this is by the daemon you mention >below. Actually it's not a daemon in the normal sense its part of the kernel's job to flush the buffers. Normally the time between the flushing is tuneable, which means that sites without source license can modify the time interval. In UNIX System V Release 3 the parameter to the kernel is called NAUTOUP. NAUTOUP The NAUTOUP entry specifies the buffer age in seconds for automatic file system updates. A system buffer is written to the hard disk when it has been memory resident for the interval specified by the NAUTOUP parameter. Specifying a smaller limit increases system reliability by writing buffers to disk more frequently and decreases performance. Specifying a larger limit increases system performance at the expence of reliability. BDFLUSHR Specifies the rate in seconds for checking the need to write the file system buffers to disk. The default is 1 second. [AT&T 3B2 Computer UNIX System V Release 3 System Administrator's Guide] The default time for updating buffers on the 3B2/600 is 10 seconds. Kim Chr. Madsen