From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Cross Message-Id: <200102082149.QAA07290@augusta.math.psu.edu> To: 9fans@cse.psu.edu Subject: Re: [9fans] 9p2k, fsync In-Reply-To: Cc: Date: Thu, 8 Feb 2001 16:49:19 -0500 Topicbox-Message-UUID: 5eac06ea-eac9-11e9-9e20-41e7f4b1d025 In article you write: >Tsync: This way there be dragons. >The next thing you'll be asking for is byte range locks and then >locks that can survive crashes and then something to coordinate >updates to multiple files and then away to back it up . . . . . . ``My God, will it ever cease?! Make the bad man stop!'' :-) >If you want ACID let's look at away of providing for it within the context >of the a simple file protocol. > >Ideas for sync: >1. Battery backed static RAM for the more resent requests like NetApp. >2. A volume that does write through or flush on close. > >I agree that databases have gotten way out of hand but is there away >within the spirit of Plan 9 to provide ACID? Sync does not meet the >requirement. Yeah, that seems to be the issue. I'm going to go out on a limb and say that Nemo was refering not to acid, though, but to an analogue of the Unix sync(2) system call, initiated over the network. My guess is that could be implemented via a filesystem with a control message that accepted commands like, ``sync.'' Maybe something similar could be used to initiate syncs on FID's. - Dan C.