Hi,
05.04.2018 20:15, Eugene M. Zheganin wrote:
You can indeed tune things here are the relevant sysctls:
sysctl -a | grep trim |grep -v kstat
vfs.zfs.trim.max_interval: 1
vfs.zfs.trim.timeout: 30
vfs.zfs.trim.txg_delay: 32
vfs.zfs.trim.enabled: 1
vfs.zfs.vdev.trim_max_pending: 1
vfs.zfs.v
On Fri, Apr 6, 2018 at 2:56 AM, Borja Marcos wrote:
>
>
> On 6 Apr 2018, at 10:41, Steven Hartland wrote:
>
> That is very hw and use case dependent.
>
> The reason we originally sponsored the project to add TRIM to ZFS was that
> in our case without TRIM the performance got so bad that we had t
On Fri, Apr 6, 2018 at 1:58 AM, Borja Marcos wrote:
>
> > On 5 Apr 2018, at 17:00, Warner Losh wrote:
> >
> > I'm working on trim shaping in -current right now. It's focused on NVMe,
> > but since I'm doing the bulk of it in cam_iosched.c, it will eventually
> be
> > available for ada and da. Th
> On 6 Apr 2018, at 10:56, Borja Marcos wrote:
>
> P.S: Attaching the graphs that were lost.
And, silly me, repeating the same mistakes over and over.
http://frobula.crabdance.com:8001/publicfiles/OneBonnie.png
http://frobula.crabdance.com:8001/publicfiles/TwoBonniesTimes.png
http://frobula.c
> On 6 Apr 2018, at 10:41, Steven Hartland wrote:
>
> That is very hw and use case dependent.
>
> The reason we originally sponsored the project to add TRIM to ZFS was that in
> our case without TRIM the performance got so bad that we had to secure erase
> disks every couple of weeks as they
That is very hw and use case dependent.
The reason we originally sponsored the project to add TRIM to ZFS was that
in our case without TRIM the performance got so bad that we had to secure
erase disks every couple of weeks as they simply became so slow they where
unusable.
Now admittedly that was
> On 5 Apr 2018, at 17:00, Warner Losh wrote:
>
> I'm working on trim shaping in -current right now. It's focused on NVMe,
> but since I'm doing the bulk of it in cam_iosched.c, it will eventually be
> available for ada and da. The notion is to measure how long the TRIMs take,
> and only send th
Hello,
On 05.04.2018 20:00, Warner Losh wrote:
I'm also having a couple of iSCSI issues that I'm dealing through
bounty with, so may be this is related somehow. Or may be not. Due
to some issues in iSCSI stack my system sometimes reboots, and
then these "waves" are stopped for s
Hello,
On 05.04.2018 19:57, Steven Hartland wrote:
You can indeed tune things here are the relevant sysctls:
sysctl -a | grep trim |grep -v kstat
vfs.zfs.trim.max_interval: 1
vfs.zfs.trim.timeout: 30
vfs.zfs.trim.txg_delay: 32
vfs.zfs.trim.enabled: 1
vfs.zfs.vdev.trim_max_pending: 1
vfs.zfs.
On Thu, Apr 5, 2018 at 8:08 AM, Eugene M. Zheganin wrote:
> Hi,
>
> I have a production iSCSI system (on zfs of course) with 15 ssd disks and
> it's often suffering from TRIMs.
>
> Well, I know what TRIM is for, and I know it's a good thing, but sometimes
> (actually often) I'm seeing my disks in
You can indeed tune things here are the relevant sysctls:
sysctl -a | grep trim |grep -v kstat
vfs.zfs.trim.max_interval: 1
vfs.zfs.trim.timeout: 30
vfs.zfs.trim.txg_delay: 32
vfs.zfs.trim.enabled: 1
vfs.zfs.vdev.trim_max_pending: 1
vfs.zfs.vdev.trim_max_active: 64
vfs.zfs.vdev.trim_min_active
Hi,
I have a production iSCSI system (on zfs of course) with 15 ssd disks
and it's often suffering from TRIMs.
Well, I know what TRIM is for, and I know it's a good thing, but
sometimes (actually often) I'm seeing my disks in gstat are overwhelmed
by the TRIM waves, this looks like a "wave"
12 matches
Mail list logo