Hi Gordon, Gordon Ross wrote:
> I'm pleased to see this improvement moving forward. > > Not sure if these are design or interface questions, but: > > Why is the mount time (vfs->vfs_mtime) not suitable for use > in place of the new "created time" you're adding? > > Also, is the "destroyed time" not needed because elements > will be removed from the list immediately upon unmount? > If so, how is the "snapshot behavior" retained for an > existing open performed before some mounts were removed? My implementation has deviated slightly from your original suggestion: rather than use nothing but the existing linked-list of mounted resources, I am creating a second data structure as and when required. This database reflects the state of the in-kernel mnttab that is seen by all currently-open vnodes. On each new open, the in-kernel mnttab and the database are scanned with the goal of updating the latter to reflect the current state of the former. The "destroyed time" is required so that a database element can be killed when the corresponding mounted resource is found to be absent. When updating the database it is necessary to be able either to find the vfs_t that corresponds to a given element or to determine that the vfs_t is no longer present. This requires something akin to a "serial number" that is unique to each vfs_t. The mount time is not suitable for this purpose because it can change over the lifetime of the vfs_t. In addition, a resource remains in place when remounted, and therefore one has to be able to determine not simply whether a particular entry in the mnttab is new but whether it obsoletes a previous one. I chose to use a separate database because the in-kernel mnttab is in some senses fragile. I think that the changes that would be required if one were to use the in-kernel mnttab alone would be considered too invasive. The existing proposal puts almost all of the complexity into mntfs with only a minimal intrusion into other subsystems. Regards, Robert
