Re: silent semantic changes with reiser4

[Helge Hafting]

Timothy Miller wrote:

> I'm probably not the first to suggest this idea, and it's probably not 
> a very good idea, but here's my idea anyhow:
>
> You have a file "/usr/bin/emacs"
> with a metadata property in the overlaid namespace 
> "/usr/bin/emacs/[[..]metas/]icon"
>
> According to some, this could cause some confusion.  Howabout instead:
>
> You have a file "/usr/bin/emacs"
> with a metadata property in a slightly separated namespace 
> "/metas/usr/bin/emacs/icon"
And the problem with such a "solution" is
mv /usr/bin/emacs /usr/bin/old-emacs
Do this with an ordinary fs, and the /metas/usr/bin/emacs/icon
won't move with it.  Now metas might might not be an ordinary fs,
so perhaps the move happens automatically there, but if so
it will be unexpected. 

> This has the advantage of still having the metadata in the filesystem 
> namespace but without the confusion of having files-as-directories, 
> ambiguity of filename, backup issues, etc.  This is the reverse of 
> having the namespaces overlaid with a "/nometas" view which is separate.
>
> Furthermore, you can split things further like this:
>
> You have a file "/usr/bin/emacs"
> with an automatically-generated metadata property that you don't want 
> to back up in "/autometas/usr/bin/emacs/modification_date"
> and a manually generated metadata property that you MAY want to backup 
> in "/staticmetas/usr/bin/emacs/icon".
>
> This is inelegant, I know.  But if we do this, we can add the extra 
> features of reiser4 without confusing existing apps or having to 
> modify them to support the new functionality.
>
> Furthermore, you can easily hide the extra features by not mounting 
> the meta top-level directories (assuming they're mounted like separate 
> filesystems, rather than just magically appearing there, which is okay 
> too).

Having to go up to root and then down a similar but different path to 
reach a
file's metadata seems very counterintuitive to me.  And you have to 
update all
tools to do this automatically, or it'll be hopeless to actually use.

Helge Hafting

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/