Re: Removal of miscfs/syncfs

[J. Hannken-Illjes <hannken%eis.cs.tu-bs.de@localhost>]

On 01 May 2015, at 14:16, Christos Zoulas <christos%astron.com@localhost> wrote:

> In article <F40DE9D8-F529-4411-9695-2D347E4DE862%eis.cs.tu-bs.de@localhost>,
> J. Hannken-Illjes <hannken%eis.cs.tu-bs.de@localhost> wrote:
>> Our miscfs/syncfs originating from the softdep import is a pseudo
>> file system with one VOP.  Its vnodes get used as a kind of marker
>> on the syncer worklist so the syncer may run lazy VFS_SYNC for
>> all mounted file systems.
>> 
>> For this to work, it creates a vnode attached to the mount point
>> with a special (syncfs) operations vector.  This concept breaks
>> some rules making it nearly is impossible to implement it with
>> the new vcache operations.
>> 
>> I propose to completely remove miscfs/syncfs and
>> 
>> - move the syncer sched_sync into kern/vfs_subr.c
>> - change the syncer to process the mountlist and VFS_SYNC as appropriate.
>> - use an API for mount points similiar to the API for vnodes.
>> 
>> Diff at http://www.netbsd.org/~hannken/rm-miscfs-syncfs-1.diff
>> 
>> Comments or objections anyone?
> 
> Have you tested its performance?

With ten mounts I got no problems.  All it adds is once per second:

  mutex_enter(&mountlist_lock);
  for (mp = TAILQ_FIRST(&mountlist); mp != NULL; mp = nmp) {
    if (NOTHING_TO_DO(mp)) {
        nmp = TAILQ_NEXT(mp, mnt_list);
        continue;
      }
  }
  mutex_exit(&mountlist_lock);


> Out of the 4 time_t tunables, two are not being used;

All tunables are used:

kern/vfs_subr.c:461:    delayx = dirdelay;
kern/vfs_subr.c:465:    delayx = metadelay;
kern/vfs_subr.c:470:    delayx = filedelay;
kern/vfs_subr.c:622:    return mp->mnt_wapbl != NULL ? metadelay : syncdelay;
kern/vfs_subr.c:847:    synced ? syncdelay : lockdelay);
miscfs/genfs/genfs_io.c:95:     vn_syncer_add_to_worklist(vp, filedelay);

> The other two are truncated to int's, why use time_t then?

Because I didn't change anything here.  As these tunables are sysctl
nodes we had to change their size breaking backwards compatibility.

--
J. Hannken-Illjes - hannken%eis.cs.tu-bs.de@localhost - TU Braunschweig (Germany)