From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Bellman Subject: Re: Atomic file data replace API Date: Sun, 09 Jan 2011 19:56:20 +0100 Message-ID: <4D2A04D4.8020503@nsc.liu.se> References: <1294412141-sup-1734@think> <1294412553-sup-9058@think> <1294412980-sup-1924@think> <4D274022.5070507@mmmm.it> <4D2769A7.8000803@nsc.liu.se> <4D28DA67.6060404@nsc.liu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Cc: Massimo Maggi , linux-btrfs To: Olaf van der Spek Return-path: In-Reply-To: List-ID: Olaf van der Spek wrote: > On Sat, Jan 8, 2011 at 10:43 PM, Thomas Bellman wrote: >> So, basically database transactions with an isolation level of >> "committed read", for file operations. That's something I have >> wanted for a long time, especially if I also get a rollback() >> operation, but have never heard of any Unix that implemented it. > > True, that's why this feature request is here. > Note that it's (ATM) only about single file data replace. That particular problem was solved with the introduction of the rename(2) system call in 4.2BSD a bit more than a quarter of a century ago. There is no need to introduce another, less flexible, API for doing the same thing. >> A separate commit() operation would be better than conflating it >> with close(). And as I said, we want a rollback() as well. And >> a process that terminates without committing the transaction that >> it is performing, should have the transaction automatically rolled >> back. > > What could you do between commit and close? More write() operations, of course. Just like you can continue with more transactions after a COMMIT WORK call without having to close and re-open the database in SQL. /Bellman