Re: RFC: SEEK_DATA/SEEK_HOLE implementation version 2

[Reinoud Zandijk <reinoud%NetBSD.org@localhost>]

Hi!

On Mon, Oct 03, 2011 at 04:54:29AM +0000, YAMAMOTO Takashi wrote:
> > The new implementation presents the default one-blob for file systems that
> > don't implement it. For NetBSD its currently implemented for UFS and is
> > tested for FFS with/without WAPBL, ext2fs and lfs. It is present in our
> > ZFS import but aparently disabled still and i dont have a ZFS partition to
> > play with. I might be tempted to try it later on my scratch machine :) UDF
> > is next but shouldn't be that difficult.
> 
> why is the VOP_FSYNC call necessary?

The sparse region search code depends on the indirect blocks being correctly
written out as it traverses them. If the file is still `dirty' all the
indirect blocks are present as negative indices so the normal FFS code works
but their indirect blocks, when addressed with their disc addresses, are not
up-to-date.

The FFS sparse region search code depends on the indirect blocks to see where
actual data is recorded and needs the indirect blocks to be up-to-date. A
range sync with only the negative range might also suffice but since most if
not all of the applications of this code is dealing with backup/processing the
VOP_FSYNC() is normally a NOP.

I hope this explanation helps :)

With regards,
Reinoud