Re: RFC: SEEK_DATA/SEEK_HOLE implementation version 2

[yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi)]

> 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 :)

what's wrong with just reporting dirty regions as non-hole?

YAMAMOTO Takashi

> 
> With regards,
> Reinoud