On 08/19/16 08:57, Allan Jude wrote:
On 2016-08-19 10:13, Warner Losh wrote:
On Fri, Aug 19, 2016 at 12:51 AM, Dag-Erling Smørgrav <d...@des.no> wrote:
Warner Losh <i...@bsdimp.com> writes:
Allan Jude <allanj...@freebsd.org> writes:
Which makes more sense:
A) If stripesize == 0, use some sane value like 4096
I don't like this.
B) Some other combination that uses the reported stripe size, unless it
is 0, in which case it uses 4096 (or some other value controlled by a
different new sysctl)
Don't like this so much.
C) create kern.geom.min_stripe_size with a default of 512, but users can
set 4096 if they use only 4k devices. (doesn't really solve the problem
for the installer)
Default it to 4k, and allow users to set it to 512. If the drive
reports < this value
report this value instead.
I don't like either option. Option D (which I don't like either, but
which should at least work in most cases) is a sysctl that specifies a
minimum factor, and set the reported stripe size to the least common
multiple of that number and the actual stripe or sector size. This is
what my bsdinstall patch does. However, I think that pushing this down
to a layer where it will affect all applications is a terrible idea,
because we have no way of knowing what will break[*], and it can
seriously mislead users and hinder troubleshooting - especially if it is
enabled by default rather than only when necessary.
I took a look into the implications of doing a 4k stripesize 'automatically'
this morning. I found a few places in g_part where it would actively
hurt when coupled with gpart's insistence on aligning things. So I
now think it's a bad idea. This will make it harder for FreeBSD to
generate arbitrary disk layouts. And I'm not too sure about what
things like gstripe would report as a result and if this would actually
interfere if you had a large, but not power of two stripe size.
I don't think it's a good idea to enforce stripe alignment everywhere,
either. It works for partitions because they are very large relative to
the stripe size, and at worst we will waste a few millionths of the disk
on inter-partition gaps, which should only occur between the partition
table and the boot partition, and possibly, if the stripe size is very
large, between the boot partition and the swap partition. But forcing
filesystems to respect the stripe size will lead to no end of trouble,
because RAID volumes can have stripe sizes of 16 kB or more. I think it
is important to align partitions during installation because of the huge
performance impact of misaligned partitions on AF disks, but despite
what Nathan claims, I never advocated applying the same logic
everywhere.
Yea, having poked at it for just a little while, I agree. The installer is the
right place to make sure we don't cross-thread the 4k sectors. Stripe size
means too many other things to have it be useful in that context.
Warner
Maybe instead we just change gpart to default to 4k alignment, but users
can always override with -a 512 or some other value?
Then the installer behaves the same as a user typing 'gpart', but we
don't mess with the entire geom layer?
ZFS also looks at this, so we would need it there, and there might be a
few others. At the very least, gpart and the installer should have the
same behavior.
Warner, could you elaborate on what you mean by "cross-threading"? Are
you worried about nested partition tables in which the outer one is
misaligned? Having the disk drivers report a 4K stripesize seems to have
worked so far; I'm not sure how reporting it more often would cause
problems. You wouldn't want all drivers, or all GEOM layers, to do this,
of course. If the problem is that "stripe size" has an overloaded
meaning, we could easily add another GEOM property.
-Nathan
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
