Subject: Re: lseek() extension for spare files
To: Bill Studenmund <>
From: Reinoud Zandijk <>
List: tech-kern
Date: 09/21/2006 23:54:50
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Thu, Sep 21, 2006 at 02:12:19PM -0700, Bill Studenmund wrote:
> I'm not sure you have the SEEK_DATA case right:
> +               if (ap->a_offset != 0)
> +                       return ENXIO;
> My read of the manpage is that if you're on top of data, there is a data 
> range starting at your offset. Note the use of "greater or equal" in the 
> Sun man page.
> I think that should be that as long as the offset is not at or past the
> end of the file, there's data, so no error.

you are right! thanks for the bugreport!

> No. We should not implement this as a seek for zeros. Either you look at 
> your allocation tables to find holes, or you don't find holes.

thats reasonable yes.

> > If i understand FFS enough, it could be that the file's allocation tree can 
> > be searched and the relevant region extracted at allmost no cost; esp. if 
> > you count the reading and movement of all that dummy data to userland.
> It won't be "at almost no cost," however it will be MUCH cheaper than
> reading data. It will be expensive as indirect blocks will have to be read
> into the kernel, and that usually means seeks.

well normally one would have to seek those indirect blocks too to see if 
something is recorded anyway...


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.4.2.1 (NetBSD)