----- Original Message -----
From: "Justin T. Gibbs"
I'm sure lots of folks have "some solution" to this. Here is an
old version of what we use at Spectra:
http://people.freebsd.org/~gibbs/zfs_patches/zfs_auto_ashift.diff
The above patch is missing some cleanup that was motivated by my
discussions with George Wilson about this change in April. I'll
dig that up later tonight. Even if you don't read the full diff,
please read the included checkin comment since it explains the
motivation behind this particular solution.
This is on my list of things to upstream in the next week or so after
I add logic to the userspace tools to report whether or not the
TLVs in a pool are using an optimal allocation size. This is only
possible if you actually make ZFS fully aware of logical, physical,
and the configured allocation size. All of the other patches I've seen
just treat physical as logical.
Reading through your patch it seems that your logical_ashift equates to
the current ashift values which for geom devices is based off sectorsize
and your physical_ashift is based stripesize.
This is almost identical to the approach I used adding a "desired ashift",
which equates to your physical_ashift, along side the standard ashift
i.e. required aka logical_ashift value :)
One issue I did spot in your patch is that you currently expose
zfs_max_auto_ashift as a sysctl but don't clamp its value which would
cause problems should a user configure values > 13.
If your interested in the reason for this its explained in the comments in
my version which does a very similar thing with validation.
Regards
Steve
================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.
In the event of misdirection, illegible or incomplete transmission please
telephone +44 845 868 1337
or return the E.mail to postmas...@multiplay.co.uk.
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
