On Wed, Aug 02, 2000 at 04:03:30PM +0200, Miklos Szeredi wrote:
>
> > If you care about the disk usage, why don't you simply truncate the
> > container to 0 bytes before unlinking it from userspace?
>
> Good point, that is probably a workable userspace solution.
And useful solution for older kernels that don't have this change.
> > I'm wondering how much this would affect performance when the userspace
> > manager does not intend to throw the file away as soon as possible.
>
> Well, performance is not really affected, since coda_open() calls down
> to venus (which is slow), even if the container indode is already
> set. iput() and iget() on the container is I think not too expensive.
Right, and as long as the container is not unlinked, the dentry through
which venus uses to access the container will still keep the inode and
associated memory mappings around until memory pressure kicks in.
> > Also, could dentry->d_count be used instead of adding a new
> > counter in coda_inode_info, or is that asking for races between open and
> > release?
>
> Using d_count is not too good, since more then one dentry can contain
> the same inode, and the dentry could be referenced by other things,
> then open files (cwd for example). So even adding up the counts of all
> dentries belonging to the inode would not always yield the same value
> as the simple open reference count.
And that would involve crawling d_alias lists and stuff, combined with
the fact that the dcache is not under the bkl. Yuck, keeping track of
the refcount is definitely a lot simpler.
Well, I don't see a problem with the patch. I'll also include it in the
bundle of Coda fixes that I'm going to submit for inclusion in 2.2.17.
Jan
