[Top] [All Lists]

Re: Transactional XFS?

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: Transactional XFS?
From: Stewart Smith <stewart@xxxxxxxxxxxxxxxx>
Date: Fri, 17 Feb 2012 15:40:21 +1100
Cc: Grozdan <neutrino8@xxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <20120216064230.GZ14132@dastard>
References: <CAFLt3phWcaQ4K3OPSVUkyN0BXqh+jQgQbeA59Oav23aOPLYMYw@xxxxxxxxxxxxxx> <20120216002237.GW14132@dastard> <87k43nzj5e.fsf@xxxxxxxxxxxxxxxx> <20120216014338.GX14132@dastard> <87ehtvz6bp.fsf@xxxxxxxxxxxxxxxx> <20120216064230.GZ14132@dastard>
User-agent: Notmuch/0.11+72~g8ea8292 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu)
On Thu, 16 Feb 2012 17:42:30 +1100, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
> > The worst part is working out the semantics as to not break existing apps
> > (without completely sacrificing concurrency).
> That doesn't seem like a show stopper to me.
> The part that I see is that it is basically impossible to do
> arbitrarily large transactions in a filesystem - they are limited by
> the size of the log. e.g. you can't have a user transaction that
> writes more data or modifies more data than the log allows in a
> single checkpoint/transaction. e.g. you can't just overwrite a 100MB
> file in a transaction and expect it to work. It might work if you've
> got a 2GB log, but if you've only got a 10MB log, then that
> overwrite transaction is full of fail.

We have this problem too. none of the solutions are particularly pretty,
and certainly do have a performance impact.

> It's issues that like that that doom the generic usefulness of
> userspace controlled filesystem transactions as part of the normal
> filesystem operation. If you need this sort of functionality, it has
> to be layered over the top of the filesystem to avoid filesystem
> atomicity limitations. i.e. another layer of tracking and
> journalling. And at that point you're talking about implementing a
> database on top of the filesystem in the filesystem....

As I said... it's tricky to solve all the problems :)
Stewart Smith

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