DragonFly BSD
DragonFly commits List (threaded) for 2005-08
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: cvs commit: src/sys/kern vfs_cache.c vfs_syscalls.c vfs_vnops.c vfs_vopops.c src/sys/sys namecache.h stat.h

From: Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>
Date: Fri, 26 Aug 2005 17:02:24 +0200
Mail-followup-to: commits@crater.dragonflybsd.org

On Fri, Aug 26, 2005 at 03:34:25PM +0100, Hiten Pandya wrote:
> Joerg, the kqueue interface is not only un-suitable but it is a lot higher 
> than FSMIDs (which are at namecache level) to be of any use.  Kqueue is 
> too generic and does not even come close to solving the journaling and 
> transactional requirements that FSMIDs are meant to solve.

I disagree with this completely. What I've tried to show so far was that
*vnode* operations can't be savely monitored with a *recursive* approach
like FSMIDs. The only practical approach which has been implemented so
far was an inode monitor. The exposure could at least be altered based
on device permissions or similiar means.

Please, keep also in mind that *vnode* operations in general are not
*namespace* operations. I still think that the concept of persistent
FSMIDs is simply wrong and anything else can solved by a daemon using
kqueue with recursive notification.

There is an important different in both approaches, notification of
changes can be implemented by different means and e.g. FAM provides a
server mode for remote filesystems. That's not something which can be
done easily with FSMIDs because those are not a concept but an
*implementation detail*.


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]