Subject: Re: removing VOPs
To: None <firstname.lastname@example.org>
From: YAMAMOTO Takashi <email@example.com>
Date: 10/20/2005 20:18:06
> > > - What is unsafe with VOP_BALLOC? A file system supporting files with holes
> > > should export a VOP to allocate these blocks.
> > lack of locking.
> Caller of fss_bmap (the function doing the VOP_BALLOC) locks the vnode.
locking the vnode is not enough, at least after ubc.
besides, fss_bmap seems to cheat softdep.
> > i agree about the necessity of the API.
> > however, the current form of VOP_BALLOC (and VOP_BMAP) is not
> > usable for the code outside of the filesystem itsself.
> Any ideas about the new API?
i personally prefer high-level API (eg. direct i/o) than the
direct export of block allocation/deallocation
because the latter is too filesystem specific IMO.
> I don't know if swapping
> may run it from an interrupt context.
it's always done in a thread context.
> dump/snapshot.c and fssconfig/fssconfig.c create a backing store and truncate
> it to the needed size. Without VOP_BALLOC support the backing store must be
> written up to the needed size.
i see. thanks for explanation.
please feel free to make changes on the branch
if you think it's appropriate.
i guess that an alternative would be just making fss do VOP_WRITE
when it needs to allocate blocks.