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 s
Hi DES, unfortunately you need a quite bit more than this to work compatibly.
I've had a patch here that does just this for quite some time but there's been
some
discussion on how we want additional control over this so its not been commited.
If others are interested I've attached this as it ac
On 3 July 2013 01:45, Wojciech Puchar wrote:
>> AMD Features2=0x1
>> TSC: P-state invariant, performance statistics
>> real memory = 34359738368 (32768 MB)
>> avail memory = 32191340544 (30700 MB)
>
>
> 2GB memory "disappears" too even when you don't set anything.
>
> i asked such a question fo
"Steven Hartland" 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
http://lists.freebsd.org/mailman/
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 t
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.
Reg
-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 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 (logical sector
- 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 secto
-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
I'm going through all the internal changes my current employer has made,
categorizing them
into "proprietary" and "can feed back to FreeBSD".
I will probably send out emails like this several times seeking feedback on
whether a particular patch is considered useful or not..
these are verse 8.0
- 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
discu
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:
>> http://people.freebsd.org/~gibbs/zfs_patches/zfs_auto_ashift.diff
>> The a
- 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:
http://people.freebsd.org/~gi
On Jul 10, 2013, at 1:42 PM, "Steven Hartland" 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 an
On Jul 10, 2013, at 11:16 AM, Julian Elischer wrote:
> My first candidates are:
Those sound useful. Just out of curiosity, however, since we're on the topic
of kernel dumps: Has anyone even looked into the notion of an emergency
fall-back network stack to enable remote kernel panic (or sy
On 07/10/2013 13:16, Julian Elischer wrote:
> I'm going through all the internal changes my current employer has made,
> categorizing them
> into "proprietary" and "can feed back to FreeBSD".
>
> I will probably send out emails like this several times seeking feedback on
> whether a particular p
- 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 inse
On Jul 10, 2013, at 1:04 PM, asom...@gmail.com wrote:
> I don't doubt that it would be useful to have an emergency network
> stack. But have you ever looked into debugging over firewire?
Absolutely. In fact, before the advent of remote network debugging, FW was
totally the debugging method of
On Wed, Jul 10, 2013 at 12:57 PM, Jordan Hubbard
wrote:
>
> On Jul 10, 2013, at 11:16 AM, Julian Elischer wrote:
>
>> My first candidates are:
>
> Those sound useful. Just out of curiosity, however, since we're on the
> topic of kernel dumps: Has anyone even looked into the notion of an
>
>
>
> Those sound useful. Just out of curiosity, however, since we're on the
> topic of kernel dumps: Has anyone even looked into the notion of an
> emergency fall-back network stack to enable remote kernel panic (or system
> hang) debugging, the way OS X lets you do? I can't tell you the
On Wed, Jul 10, 2013 at 3:50 PM, Jordan Hubbard wrote:
> Absolutely. In fact, before the advent of remote network debugging, FW was
> totally the debugging method of choice since firewire target DMA lets you do
> all kinds of useful things (as well as a few things that simply scare the
> secur
On Wed, 10 Jul 2013 14:50:19 PDT Jordan Hubbard wrote:
>
> On Jul 10, 2013, at 1:04 PM, asom...@gmail.com wrote:
>
> > I don't doubt that it would be useful to have an emergency network
> > stack. But have you ever looked into debugging over firewire?
>
> My point was more that actually being
On 10/07/2013 23:09, Kevin Day wrote:
>>
>> Those sound useful. Just out of curiosity, however, since we're on the
>> topic of kernel dumps: Has anyone even looked into the notion of an
>> emergency fall-back network stack to enable remote kernel panic (or system
>> hang) debugging, the way O
24 matches
Mail list logo
