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 _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
