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 :)