[Btrfs-devel] transaction ioctls

[Chris Mason]

On Wednesday 23 April 2008, Evgeniy Polyakov wrote:
> On Wed, Apr 23, 2008 at 09:23:03AM -0400, Chris Mason 
(chris.mason at oracle.com) wrote:
> > The kind of logging this requires is outside the scope of Btrfs ;)  It is
> > possible if both procs are running in different tree roots, but how
> > about:
> >
> > proc A: mkdir dir1
> > proc A: create dir1/file1
> > proc B: add data to dir1/file1
> > proc B: fsync dir1/file1
> > proc A: rollback
>
> Depending on where transaction was started and where it was stopped. If
> there are exactly two transactions started and stopped at the start and
> the end of the 'trace', then rollback of transaction A means rollback of
> the inner transactions too.

Right, these are things that real databases solve that posix doesn't expect or 
understand.  The rollback will make the file disappear, but some other 
process could have the file open, without a transaction running.  So, the 
rollback needs to provide the same semantics you get today with unlink on an 
open file.

Definitely not impossible, but really outside the scope of btrfs.

>
> > Filesystems can be databases, but not with the current APIs.  Userland
> > simply isn't built around these semantics today.
>
> This is a philosiphical disput, I always believed that there is no
> difference between database and filesystem, but only access method
> changes.

We agree there, except that filesystems are able to include a number of 
optimizations that databases can't because they don't have to do rollback or 
private views of the data.

> And having proper API is just a matter of taste: one can create 
> ioctl based one to be private feature of the new filesystem. No one
> argues that XFS operation system should be transformed into XFS
> filesystem and generic VFS helpers (although that could be a good idea).

It isn't just the API, it is the rules surrounding how and when files or 
directories can disappear.  Please, prove me wrong...patches always welcome.

-chris