Re: The argument for fs assistance in handling archives

[John Stoffel]

Hans> For 30 years nothing much has happened in Unix filesystem
Hans> semantics because of sheer cowardice (excepting Clearcase, which
Hans> priced itself into a niche market).

Keeping a consistent namespace is cowardice?  And ClearCase is an
example of an application which sets up it's own namespace and grafts
it onto the standard Unix one.  Most standard Unix tools work just
fine inside clearcase Views, but to manage the metadata (xattrs, or
whatever you want to call them), you need to use the 'cleartool'
command.  Hmmm... sounds like 'runat' to me.

Hans> It is 25 years past time for someone to change things.  That
Hans> someone will have first mover advantage, and the more little
Hans> semantic features possessed the more lure there will be to use
Hans> it which will increase market share which will lure more apps
Hans> into depending on it and in a few years the other filesystems
Hans> will (deservedly) have only a small market share because the
Hans> apps won't all work on them.

This is all pure marketing speak and economic theory.  Show us the
*technical* advantages, not just wishful thinking.  

Hans> Besides, there are enhancements which are simply compelling.
Hans> You can write a dramatically better performance version control
Hans> system with a much simpler design if the FS is atomic. 

Define atomic please, with state diagrams and clear examples.  

Hans> We have the performance lead.  By next year we will be stable
Hans> enough for mission critical servers, and then we start the
Hans> serious semantic enhancements.

I think you've got it backwards.  Make your serious semantic
enhancements first, then make it stable, then make it fast.  Because
when you change the semantics, you break all kinds of things and then
it doesn't matter how fast you are.

Hans> If you don't embrace progress, then you doom Linux to following
Hans> behind, because the guys at Apple are pretty aggressive now that
Hans> Jobs is back, and they WILL change the semantics, and they will
Hans> do so in compelling ways, and Linux will be reduced to aping
Hans> them when it should be leading them.

Monkey see, Monkey do then.  


I'd like to point out another successful company which has extended
the standard Unix namespace and that's 'Network Appliance' with it's
.snapshot directory structure.  It's a great idea and allows my users
to restore files from snapshots without me having to think about it.  

But it still causes problems since when I use rsync to move data, I
need to put in stuff like:

  rsync -az --exclude ".snapshot" --delete --delete-excluded <src> <dest>

to make sure it doesn't descend into that directory of previous
versions and try to copy them over as well.  And of course now now
other apps can use the .snapshot name.  But what if other vendors aped
(ook ook) this decided to use their own names?  Who decides which gets
priority?  

I think you need to go back and re-read Pike's paper on namespaces
that you pointed to before and mull it over.  And look at how
simplicity is inherently powerful.  If the design is too complicated,
you're probably doing it wrong.

John
-
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/