svn commit: r196777 - head/sys/dev/ahci

[Ivan Voras]

2009/9/3 Scott Long <scottl at samsco.org>:
> On Thu, 3 Sep 2009, Alexander Motin wrote:

>> It would be nice if every level would do it's own job.
>
> It's the job of the driver to handle the limitations of the hardware, yes.
> Again, if you want to experiment with pushing this functionality into GEOM,
> be my guest.  But until then, consider following my advice.

Speaking as an user who goes "huh, well" every time he sees a RAID
card with a GB of cache talking to the OS in 64 kB chunks, eventually
removing this limitation seems a Nice Thing to Have.

I don't know how things look at the driver side, but GEOM by itself
has no problems passing around requests of at least "long" in length.
Specifically, it cares about struct bio, where bio_bcount is a "long"
and bio_length and bio_completed are off_t. So, ssize_t looks ok as a
high boundary.

There was a time (apparently much of it was a bug in reporting and is
now fixed :( ) when MAXPHYS could be manually redefined to be 256K or
more and iostat would nicely state the higher value. I think the
concern raised at the topic was that it doesn't play nice with
bufcache, and I think the specific problem was possible out-of-memory
situations. Now that kernel limits on AMD64 are much increased (to
values not longer fitting in uint32_t) I wonder if the problem is so
serious?

I also remember BSDCan 2008: http://wiki.freebsd.org/Buf0x :)

-- 
f+rEnSIBITAhITAhLR1nM9F4cIs5KJrhbcsVtUIt7K1MhWJy1A==