The FreeBSD new unionfs implementation: New API request for FreeBSD VFS

Daichi GOTO (daichi@freebsd.org)
First edition Tue Oct 10 21:17:46 2006
Last modified Tue Oct 10 22:14:04 2006

1 Introduction

We have always tried to keep changes just in unionfs segment only. But by accomplish nothing, we need change the other segment.

2 Problem Description

Until now we have did many improvements for unionfs, but now we feel the limication arount the process of unionfs's "copied-up file". Additional thinking of future support for MAC extention, ADVLOCK lock infomation and somethinkg like those, all the more reason to be careful.

3 Impact

It leads the confution of unionfs implementation and some problem around lock mechanism. We cannot solve those problem by just only changes in unionfs segument.

4 Solution Request

We need new 2 APIs(functions) for VFS. Please some developer do implement new APIs like as follow:

リスト4.1 We need two new functions like these
int VOP_GETALLATTR(struct vnode *vp, struct vnode_xxx *data, struct thread *td)
{
        set the all attr to data from vp;
        ...;
}
int VOP_SETALLATTR(struct vnode *vp, struct vnode_xxx *data, struct thread *td)
{
        set the all attr to vp from data;
        ...;
}

Above funtions can set/get vnode information(now those are attr, extattr and ADVLOCK) together if its type is VREG.

We cannot do implement it caused by lack of vfs arcana. Please raise your hands and do it, please.

5 References

http://people.freebsd.org/~daichi/unionfs/

http://people.freebsd.org/~daichi/unionfs/index-ja.html

http://people.freebsd.org/~daichi/unionfs/reason-for-sys-uio-file.html