The attached patch causes ZFS to base the minimum transfer size for a
new vdev on the GEOM provider's stripesize (physical sector size) rather
than sectorsize (logical sector size), provided that stripesize is a
power of two larger than sectorsize and smaller than or equal to
VDEV_PAD_SIZE. This
for everyone.
Regards
Steve
- Original Message -
From: Dag-Erling Smørgrav d...@des.no
To: freebsd...@freebsd.org; freebsd-hackers@freebsd.org
Cc: ivo...@freebsd.org
Sent: Wednesday, July 10, 2013 10:02 AM
Subject: Make ZFS use the physical sector size when computing initial ashift
Steven Hartland kill...@multiplay.co.uk writes:
Hi DES, unfortunately you need a quite bit more than this to work
compatibly.
*chirp* *chirp* *chirp*
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
On Jul 10, 2013, at 11:25 AM, Steven Hartland wrote:
If others are interested I've attached this as it achieves what we needed
here so
may also be of use for others too.
There's also a big discussion on illumos about this very subject ATM so I'm
monitoring that too.
Hopefully there
There's lots more to consider when considering a way foward not least of all
ashift isn't a zpool configuration option is per top level vdev, space
consideration of moving from 512b to 4k, see previous and current discussions
on zfs-de...@freebsd.org and z...@lists.illumos.org for details.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 07/10/13 02:02, Dag-Erling Smrgrav wrote:
The attached patch causes ZFS to base the minimum transfer size for
a new vdev on the GEOM provider's stripesize (physical sector size)
rather than sectorsize (logical sector size), provided that
On Jul 10, 2013, at 11:21 AM, Xin Li delp...@delphij.net wrote:
Signed PGP part
On 07/10/13 02:02, Dag-Erling Smrgrav wrote:
The attached patch causes ZFS to base the minimum transfer size for
a new vdev on the GEOM provider's stripesize (physical sector size)
rather than sectorsize
- Original Message -
From: Xin Li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 07/10/13 02:02, Dag-Erling Sm?rgrav wrote:
The attached patch causes ZFS to base the minimum transfer size for
a new vdev on the GEOM provider's stripesize (physical sector size)
rather than
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 07/10/13 10:38, Justin T. Gibbs wrote:
[snip]
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
- 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
On Jul 10, 2013, at 1:06 PM, Steven Hartland kill...@multiplay.co.uk wrote:
- 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:
- Original Message -
From: Justin T. Gibbs
On Jul 10, 2013, at 1:06 PM, Steven Hartland wrote:
- 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:
On Jul 10, 2013, at 1:42 PM, Steven Hartland kill...@multiplay.co.uk wrote:
- Original Message - From: Justin T. Gibbs
On Jul 10, 2013, at 1:06 PM, Steven Hartland wrote:
- Original Message - From: Justin T. Gibbs
I'm sure lots of folks have some solution to this. Here is
- Original Message -
From: Justin T. Gibbs
...
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.
I would expect the zio pipeline to simply insert an
14 matches
Mail list logo
