[Top] [All Lists]

Re: Transactional XFS?

To: Linux fs XFS <xfs@xxxxxxxxxxx>
Subject: Re: Transactional XFS?
From: pg_xf2@xxxxxxxxxxxxxxxxxx (Peter Grandi)
Date: Thu, 16 Feb 2012 22:10:19 +0000
In-reply-to: <20120216014338.GX14132@dastard>
References: <CAFLt3phWcaQ4K3OPSVUkyN0BXqh+jQgQbeA59Oav23aOPLYMYw@xxxxxxxxxxxxxx> <20120216002237.GW14132@dastard> <87k43nzj5e.fsf@xxxxxxxxxxxxxxxx> <20120216014338.GX14132@dastard>
[ ... ]

> Oh, so making some set of random user changes to random user data
> have ACID properties? That's what databases are for, isn't it?  :P

I am going to use this and in particular "That's what databases
are for, isn't it?" as a quote to throw at people who try to use
filesystems as database managers, usually with very many very
small files (also known as "records" to database people), but
not only.

>> I think it'd be possible to do.. you know, if you lock a
>> number of FS and VFS devs in a room with database people for
>> a month or so we may theoritically solve nearly all the
>> problems....

The DBMS people have given up long, long ago. At least since
the article by Stonebraker mentioned here:


Anyhow Oracle has sponsored two filesystem designs, one being
OCFS2, which is pretty decent, targeted at DBMS storage and does
not have ACID as such, and one being BTRFS which is not targeted
at DBMS storage and that has snapshots for rollback of failed

> Sure, Microsoft have been trying to make their filesystem a
> database for years. It's theoretically possible, but in
> practice they've fallen short in every attempt in the past 15
> years.

I think it would be easier to do the opposite, and there have
been indeed filesystems implemented on top of DBMSes (with the
DBMS storing their data directly on top of block devices).

<Prev in Thread] Current Thread [Next in Thread>