ZFS patches

[Chuck Silvers]

On Thu, May 31, 2012 at 11:11:58AM +0200, Pawel Jakub Dawidek wrote:
> On Wed, May 30, 2012 at 05:32:34PM -0700, Chuck Silvers wrote:
> > we only have a few changes to ZFS itself, and now that I look I see that
> > you've found one of them independently (r230256).
> > 
> > the other ones are:
> > 
> >  - improve performance of booting from a ZFS root under ESXi.
> >    previously this would sit there for about 5 minutes before even
> >    starting to load the kernel.  the problem is that the ZFS pool-discovery
> >    code opens every possible GPT partition looking for pools, and it rereads
> >    the GPT each time, one sector at a time.  we changed the GPT code to
> >    read the whole GPT in one shot, which reduced the delay to almost nothing.
> >    I remember seeing some discussion about a PR on this topic some time back
> >    but I don't know if any fix was ever applied and I don't see the PR now.
> >    as I recall, the proposal in that discussion was to improve the boot code
> >    caching so that it wouldn't reread the GPT at all, which I imagine would
> >    work just as well as what we did.
> >    (hmm, this isn't actually a change to ZFS either.)
> 
> The problem I remember with this code was that it checked 128 partitions
> for every single disk in a brute-force fasion in hope that maybe there
> are no p3-p110 partitions, but maybe there is p111 one.
> 
> Easy (but not ideal) solution to this was to stop scanning partitions
> when 3 in a row don't exist. Ideal solution was to teach the code to
> actually look into partition table and trying only those partitions that
> really exist.

yea, reading the GPT once and iterating over the valid partitions would be
good too.  but if there are multiple valid partitions, there's no need
to go back and re-read the GPT again for each one.  and even when you read
the GPT the first time, it would best to read it all at once instead of
1 sector at a time.  so really all of these are addressing different aspects
of this issue.  in practice, fixing any one of these aspects is probably
enough to make this not be a problem.


> I haven't looked closely at your patch yet, though.

did you get a chance to look at it yet?
or do you think people are going to want to hold out for
a different subset of the complete set of potential changes above?


> >  - make zfs_resilver_delay and zfs_resilver_min_time_ms tunable via sysctl.
> 
> I have a bigger patch for this too:
> 
> 	http://people.freebsd.org/~pjd/patches/dsl_scan.c.patch
> 
> The reason I didn't commit this patch yet is that some of those values
> can be safely modified after boot can could be made CTLFLAG_RW like
> maybe the two you convered.
> 
> If you would like to analyse them and see which are safe to be made RW
> that would be great.

I looked through these and all of them looked safe to me to be changed
on the fly.  the values just don't seem to used in any kind of persistent fashion.

-Chuck