User: Password:
|
|
Subscribe / Log in / New account

Supporting transactions in btrfs

Supporting transactions in btrfs

Posted Nov 24, 2009 7:11 UTC (Tue) by gadnio (guest, #30187)
In reply to: Supporting transactions in btrfs by magnus
Parent article: Supporting transactions in btrfs

Usually modern DBs have solved this issue with per-record locking mechanism.

Consider the following situation:
* We have files f1, and f2 somewhere in the system.

A)
1. Transaction T1 opens f1 for writing, locking it.
2. Transaction T2 opens f1 for writing. Since it's already locked, T2 waits for T1 to finish and then tries again (mutex).

In case this scenario is not welcome, an explicit lock mechanism exists (SQL SELECT FOR UPDATE), which can be told to throw errors when the locking fails. The same situation, replayed, will look like this:
1. Transaction T1 opens f1 for writing, locking it.
2. Transaction T2 tries to lock f1. The lock fails. T2 handles the error gracefully.

B)
This is more dangerous:
1. Transaction T1 opens f1 for writing.
2. Transaction T2 opens f2 for writing.
3. Transaction T2 opens f1 for writing.
4. Transaction T1 opens f2 for writing.

This leads to deadlock since each transaction's holding the lock of the other's data, preventing both itself and the other transaction to finish. To solve this, a transaction arbiter's needed, which fires a 'deadlock' error in both transactions, rolling them both back.

For a file system to implement just that, well... we'll have to maintain a huge subset of the ACID database support -- the rollback segments, etc... which, to be done properly, for a filesystem holding tons of files of different sizes, will be a very huge pain. Just consider the case when both f1 and f2 are of sizes like 300Gb, which is not uncommon these days. And what about fsck?

Moreover, I think the concept of an in-kernel ACID database to be something ill-minded -- whenever one wants ACID, one does store one's data in ACID database and that's all. For all of us suffering the downsizes of it, I think it's not worth it.

BR,
Hristo


(Log in to post comments)


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds