On the 27.12.2010 11:21, Olaf van der Spek wrote:
On Sun, Dec 26, 2010 at 11:10 PM, Ted Ts'o<tytso@xxxxxxx> wrote:
On Sun, Dec 26, 2010 at 07:51:23PM +0100, Olaf van der Spek wrote:
f = open(..., O_ATOMIC, O_CREAT, O_TRUNC);
Great, let's rename O_ATOMIC to O_PONIES. :-)
If that makes you happy.
abort/rollback(...); // optional
As I said earlier, "file systems are not databases", and "databases
are not file systems". Oracle tried to foist their database as a file
system during the dot.com boom, and everyone laughed at them; the
performance was a nightmare. If Oracle wasn't able to make a
transaction engine that supports transactions and rollbacks
performant, you really expect that you'll be able to do it?
Like I've said dozens of times, this is not about full DB functionality.
Why do you keep making false analogies?
The analogy is not so wrong. The concepts atomicity and abort/rollback
your are talking about are also concepts of the field of database
management systems (DBMSs). And once you have established the Atomicity,
which is the A of the principle ACID of DBMSs, you have the basis for
establishing the rest, the CID.
And you even went further into this DBMS direction by letting down the
requirement of non-durability.
<snip>
Providing transaction semantics for multiple files is a far broader
proposal and not necessary for implement this proposal.
But providing magic transaction semantics for a single file in the
rename is not at all clearly useful. You need to justify all of this
hard effort, and performance loss. (Well, or if you're so smart you
can implement your own file system that does all of this work, and we
can benchmark it against a file system that doesn't do all of this
work....)
Still waiting on any hint for why that performance loss would happen.
From my point of view, the loss of performance depends on what is
benchmarked in which way.
<snip>
Olaf
--
Christian Stroetmann
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
