Re: [PATCH] GOP_ALLOC and fallocate for PUFFS

[Emmanuel Dreyfus <manu%netbsd.org@localhost>]

On Tue, Sep 30, 2014 at 03:30:05PM +0000, Antti Kantee wrote:
> Is it really better to sync fallocate, put stuff in the page cache and flush
> the page cache some day instead of just having a write-through (or
> write-first) page cache on the write() path?  You also get rid of the
> fallocate-not-implemented problem that way.

GOP_ALLOC calls puffs_gop_alloc for chunks bigger than pages 
(I observed 1 MB for now).  If we have fallocate implemented in the
filesystem, this is really efficient, since fallocate saves us from
sending any data to write. Hence IMO fallocate should be the preferred
way if available.

But if it is not there, indeed, doing a write on first attemps should
do the trick.

> Writing zeroes might be a bad emulation for distributed file systems, though
> I guess you're the expert in that field and can evaluate the risks better
> than me.

I understand that areas fallocate'd should return zeroes, so it should be
fine. The real problem is performances. I am not sure what approach is best.

I first though about a puffs_gop_alloc like below, but that will not work, 
as VOP_PUTPAGES goes to genfs_putpages, which calls 
GOP_WRITE (genfs_gop_write), which calls VOP_STRATEGY without checking
for failure. Should I directly call VOP_STRATEGY?

int
puffs_gop_alloc(struct vnode *vp, off_t off, off_t len,
                int flags, kauth_cred_t cred)
{      
	int error;
	
	if (EXISTSOP(pmp, FALLOCATE))
		return _puffs_vnop_fallocate(vp, off, len);
	else
		return VOP_PUTPAGES(vp, off, off + len,
				    PGO_CLEANIT|PGO_SYNCIO);
}     

-- 
Emmanuel Dreyfus
manu%netbsd.org@localhost