Olaf van der Spek wrote:
On Sat, Jan 8, 2011 at 10:43 PM, Thomas Bellman <bell...@nsc.liu.se> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
