> > > - 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.

YAMAMOTO Takashi