OpenBCM V1.13 (Linux)

Packet Radio Mailbox

DB0FHN

[JN59NK Nuernberg]

 Login: GUEST





  
PA2AGA > TCPDIG   16.11.96 04:14l 117 Lines 4397 Bytes #-10820 (0) @ EU
BID : TCP_96_242
Read: GUEST
Subj: TCP-Group Digest 96/242
Path: DB0AAB<DB0PV<DB0MAK<OK0PKL<DB0TUD<DB0NDR<PI8AWT<PI8JYL<PI8WFL<PI8RYS<
      PI8MBQ<PI8VNW
Sent: 961114/1746 40697@PI8VNW.#ZH2.NLD.EU
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To  : TCPDIG@EU

Received: from pa2aga by pi1hvh with SMTP
	id AA20606 ; Thu, 14 Nov 96 17:36:58 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.62/7.1) with SMTP
	id AA00007989 ; Thu, 14 Nov 96 18:31:10 MET
Received: from pa2aga-1 by pa2aga with SMTP
	id AA00007986 ; Thu, 14 Nov 96 18:28:12 MET
Received: from pa2aga-1 by pa2aga-1 (NET/Mac 2.3.62/7.5.5) with SMTP
	id AA00008475 ; Thu, 14 Nov 96 18:28:10 MET
Date: Thu, 14 Nov 96 18:23:32 MET
Message-Id: <tcp_96_242>
From: pa2aga
To: tcp_broadcast@pa2aga-1
Subject: TCP-Group Digest 96/242
X-BBS-Msg-Type: B


TCP-Group Digest            Wed, 13 Nov 96       Volume 96 : Issue  242

Today's Topics:
                          File loss (2 msgs)

Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from ftp.UCSD.Edu in directory "mailarchives".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Mon, 11 Nov 1996 05:51:32 -0700
From: "Karl F. Larsen" <k5di@acca.nmsu.edu>
Subject: File loss

        At 08:54 AM 11/11/96 +0000, you wrote:
>> systems we are using keep files open in RAM. When a power loss or crash
>> happen those files in ram are lost. This looks like files were changed,
>> which they are, but not by you.
>
>Its a bit more complex than that as except for window 3.1x the other systems
>have the sense to check disks on boot and ensure data is in a consistent
>view. The unix like systems also bound the time before data from a file
>is commited to disk to under 60 seconds. When writing system critical files
>you can firstly write them to a new file then rename them over an existing
>one, or secondly use the O_SYNC flag on open to ensure they are committed
>immediately to disk (of course the disk itself has a cache so you dont
>always win - at best you make the window much much smaller).
>
>Opening/closing files has no bearing on this, a unixlike OS doesn't
>think internally in file handles.
>
>Alan
>
        Your right Alan. I speak from a user prospective. Linux has a
signoff batch file which I looked at and it appears to warn all applications
running at the time to get things in order. And takes enough time for the
disk cache to empty...:-)

        We had file loss with windows 3.1 but as you recall it was due to
disk cache problems. Your idea for assuring safe working on files is helped
a lot by unix. I always save what I'm working on with a cp to
filename.xxx.111196 so I have a copy to go back to if disaster strikes, or
El Paso Electric Inc. decides to teach us another lesson.

73, de Karl aka k5di

 Karl F. Larsen Box 74, Mesilla Park, NM 88047 (505) 524-3303
 k5di@k5di.cruces.nm.usa.noam k5di@acca.nmsu.edu k5di@juno.com

------------------------------

Date: Mon, 11 Nov 96 19:46:00 -0000
From: mikebw@BILOW.BILOW.UU.IDS.NET (Mike Bilow)
Subject: File loss

Alan Cox wrote in a message to Mike Bilow:

 AC> When writing system critical files
 AC> you can firstly write them to a new file then rename them
 AC> over an existing one, or secondly use the O_SYNC flag on
 AC> open to ensure they are committed immediately to disk (of
 AC> course the disk itself has a cache so you dont always win -
 AC> at best you make the window much much smaller). 

The disk on-board cache can also be bypassed with any modern disk technology.
For example, a SCSI "WRITE" command with the "FUA" ("Force Unit Access") bit
asserted should result in a write operation which will be committed to the
media as soon as possible.  It is the responsibility of the operating system
to
translate POSIX constructs such as O_SYNC into SCSI constructs such as FUA.
 
-- Mike

------------------------------

End of TCP-Group Digest V96 #242
******************************

You can send your message for this bulletin
to:     tcp-group@pa2aga           on .AMPR.ORG-net
or:     tcpaga@pi8vnw.#zh2.nld.eu  on BBS-net
        ------

NOT TO: pa2aga@pa2aga  or  pa2aga@pi8vnw.#zh2.nld.eu  PLEASE!!

It will get posted automatically within a few days





Read previous mail | Read next mail


 03.07.2026 03:24:18lGo back Go up