On Tue, Feb 18, 2014 at 12:59:49AM -0800, Alex Elsayed wrote:
> Dave Chinner wrote:
>
> (My apologies for snipping, but I only wanted to address a very small part
> of what you said)
> > Similarly, things like ordered writes are great until you consider
> > how they interact with journalling and cause priority inversion
> > issues. The only way to make use of ordered writes is to design the
> > filesystem around ordered writes from the ground up. i.e. the
> > soft updates complexity problem. Unlike atomic writes, this can't
> > easily be retrofitted to an exising filesystem, and once you have
> > soft updates in place you are effectively fixing the format and
> > features of the filesystem in stone because if you need to change a
> > single operation or on disk structure you have to work out the
> > dependency graph for the entire filesystem from the ground up again.
>
> One thing that keeps coming to mind whenever ordering guarantees in
> filesystems come up is Featherstitch[1], which is (to quote the article) "a
> generalization of the soft updates system of write dependencies and rollback
> data" (since "not enough file systems geniuses exist in the world to write
> and maintain more than one instance of soft updates").
Generalising a complex concept by abstracting it doesn't mean the
result is easier to understand. Indeed, when I first looked at
featherstitch back when that article was published (as a follow to
Val's article on soft updates where she characterised them as "an
evolutionary dead end") I couldn't find anything in the source code
that generalised the process of determining the dependencies in a
filesystem and verifying that the featherstitch core handled them
correctly.
i.e. the complexity problem is still there - all it provides is a
generalised method of tracking changes and resolving dependencies
that have been defined. Determining whether a filesystem has a
dependency that the featherstitch resolver doesn't handle requires
exactly the same understanding of the dependencies in the filesystem
that implementing soft updates requires.
> Aside from its relevance to your observations on soft updates, it had a
> userspace API that provided similar guarantees to Howard Chu's suggestion.
Which requires featherstich to be implemented in all filesystems
so that the dependencies that the userspace API introduces can be
resolved correctly. It's an all or nothing solution, and requires
deep, dark surgery to every single filesystem that you want to
support that API.
Worse: I've actually looked at the featherstitch code and it's
pretty nasty. All the filesystem modules it has are built into the
featherstitch kernel module, and called through a VFS shim layer
that re-implements much of the generic paths to add callouts to the
filesystem modules to track metadata updates in a featherstitch
aware fashion.
This is not helped by a lack of documentation and a distinct lack of
useful comments in the code. Not to mention that it's full of TODO
and FIXME items and it's error handling:
r = patch_create_empty_list(NULL, &top, top_keep, NULL);
if(r < 0)
kpanic("Can't recover from failure!");
took lessons from btrfs and topped the class.
Quite frankly, featherstitch *was* a research project and it shows.
I say *was*, because it hasn't been updated since 2.6.20 and so from
that point of view it is a dead project. Maybe some of the ideas
can be used in some way, but IMO the complexity of algorithms and
implementation just kills these ordered dependency graph solutions
stone dead.
Besides that, it needs a a complete rearchitecting and
re-implementation, as would all the filesystems that use it. Hence
I just don't see it as a viable path to solving the issues at hand.
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
