Re: [PATCH] tmpfs: now working

[Thomas Bushnell, BSG]

Roland McGrath <roland@frob.com> writes:

> Despite what Thomas has said, I believe that it is reasonable for
> diskfs_truncate to return with allocsize arbitrarily higher than what was
> asked for.  (It's up to the filesystem how it does allocation, and if its
> method overallocates a truncated node--for whatever reason--allocsize
> should reflect that.)

I suppose that's true.  However, I kind of dislike it.  But I hadn't
thought about it in those terms; it might be the right approach.  What
I dislike is that here is the one place where diskfs really does have
something to say: "deallocate disk now".  But I suppose it might be
good enough to just treat it as "this is the one time you should
deallocate disk".

> > Diskfs_drop_node is called only when there are no outstanding
> > references to the file: including memory objects.  If there is a
> > memory object reference of any kind, and diskfs_drop_node is being
> > called, you have a serious bug.  
> 
> I think Neal is aware of the meaning.  You seem to be overlooking the
> discussion we've had here already about tmpfs.  As we have discussed, it
> does some things we know not to be kosher, but we are trying to get it
> working as close as possible to right within the constraints of the current
> implementation that uses the unmodified defualt_pager_object interface.

I don't have the previous messages, but I did grasp this much from the
code.  It might be that this is ultimately just a short-term hack for
a tmpfs, however, and we have to hobble together what kludges work
with it.  I have some ideas about what the Right Thing would be; they
all require interaction between the default pager and the tmpfs
server.

It is perfectly kosher to go ahead and add such interfaces, as long as
you don't hose the privileged threads of the default pager with them.

> It is certainly a dubious situation that users of the memory object for the
> file are not tracked as references by diskfs.  However, I don't think that
> needs to be considered a first-class assumption of diskfs, but rather a
> secondary consequent assumption of how things must usually interact to get
> the filesystem semantics right.  

Granted.

> I see no reason to make such a requirement in this interface, and I know of
> no place before this here email of yours that ever said that was a
> requirement of the interface.  It does indeed seem a proper requirement
> that on a successful return from diskfs_truncate, st_size is set to exactly
> the value requested.

As above, your arguments are good here, and you may well be right.
I'm uncomfortable (that is, not certain), but indeed the only thing
that is really the rule is about st_size, not allocsize.

> As we have previously discussed here, I think that POSIX.1 may require that
> they do get faults.  It is certainly a desireable behavior.

Faults are, well, ok.  We'll never be able to give them on a
default-pager based interface, of course.  Can you cite the Posix that
you think is relevant?