Re: RFC: SEEK_DATA/SEEK_HOLE implementation version 2

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

On Mon, Oct 03, 2011 at 06:18:42PM +0000, David Holland wrote:
>  > the normal FFS code works but their indirect blocks, when addressed
>  > with their disc addresses, are not up-to-date.
> 
> ...so read them out of the cache.

easier to say than to do. Calculating and referring to the negative block
numbers is not so trivial as it seems. I can create `traces' of indirect block
numbers when i look up one file block number, but it would still be a hassle
and when you are also allowing writing while seeking for empty pieces its also
very dependent on how UBC works.

>  > 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.
> 
> This shouldn't need to be there for what is purely a read operation on
> metadata.

It could be enhanced maybe but if its hindering operations in real-life it
could be done in a later phase.

With regards,
Reinoud