> 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.
> 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.
> The container counter you introduce is only accessed when the big kernel
> lock is held, so it probably doesn't need to use atomic_inc/dec for
> updates.
True. I was just thinking ahead. Also these are not performace
sensitive things. But if you like it better with unlocked operations,
I can change those.
> 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.
Miklos
