On Thu, 25 Mar 1999, Ted Lemon wrote:

> > One, the big one, is that we're now building something close to the
> > resource manager into the fs.
> 
> You're building something that knows how to insert and delete tagged
> hunks of data from a buffer.   This is not complicated.

No, because it would also have to compact space on closure, among other
things.

> Right, and there's no need to do this.   Store the data in network
> byte order, and the problem goes away.   Even if you don't do this for
> the inode data itself, there's no reason not to do it for the magic
> number.   It's certainly not a reason not to implement a more general
> solution than the one you've proposed.

The reason for keeping the magic number in host order is so that the
overlay fs can tell if it needs to byteswap the payload.

> > It's not easy to do though, and easier to get wrong. :-)
> 
> I am assuming you're kidding about this, right?  Implementing what
> I've proposed, in the grand scheme of kernel hacks, is right up there
> with implementing strcpy.   It's a lot less difficult than the system
> you're building on top of this small change we're arguing about.

No, I disagree. Sticking a database in the inode sounds like a mess to me.
And that is what you're proposing.

> > Note also that if you're REALLY using overlay fs's in a production
> > environment, you have to shield users from the underlying layers, and
> > you'll really have to think about things before you set them up. So we
> > don't have to make a everything-and-kitchen-sink solution. :-)
> 
> The fcntl call is going to descend through the filesystem stack.  If
> your filesystem layer doesn't want userland mucking with its data, it
> can simply return ENOENT when asked for the data associated with its
> magic number.  Adding something to a filesystem everybody uses for an
> application only you use is going to suck for everybody else, and
> that's why I'm proposing making it more general.  IMHO, you really
> have a choice between making it general, or not doing it at all.
> Doing things the way you currently propose doesn't seem like a viable
> choice to me.

And just what, exactly, are other people going to want to stick in here?
It's storage for overlay fs's. I really don't forsee having two overlay
fs's running on top of each other at the same time, each needing per-inode
storage. We can leave hooks in the design so it could be supported, but it
really strikes me as rare.

What exactly are you wanting it to store?

Take care,

Bill