Subject: Re: lseek() extension for spare files
To: Bill Studenmund <email@example.com>
From: Reinoud Zandijk <firstname.lastname@example.org>
Date: 09/21/2006 23:54:50
Content-Type: text/plain; charset=us-ascii
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...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v18.104.22.168 (NetBSD)
-----END PGP SIGNATURE-----