Hi,
On Fri, Apr 27, 2012 at 08:08:40AM -0400, Rick Macklem wrote:
I'll commit it to head soon with a 1 month MFC, so that hopefully
Oliver will have a chance to try it on his production server before
the MFC.
I could only give it short exposure by now, but NAMEI stays stable. From
my side
Daniel Braniss wrote:
Daniel Braniss wrote:
Daniel Braniss wrote:
Security_Multipart(Fri_Apr_27_13_35_56_2012_748)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Rick Macklem rmack...@uoguelph.ca wrote
in
Daniel Braniss wrote:
Security_Multipart(Fri_Apr_27_13_35_56_2012_748)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Rick Macklem rmack...@uoguelph.ca wrote
in
1527622626.3418715.1335445225510.javamail.r...@erie.cs.uoguelph.ca:
rm
Daniel Braniss wrote:
Daniel Braniss wrote:
Security_Multipart(Fri_Apr_27_13_35_56_2012_748)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Rick Macklem rmack...@uoguelph.ca wrote
in
Daniel Braniss wrote:
Daniel Braniss wrote:
Security_Multipart(Fri_Apr_27_13_35_56_2012_748)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Rick Macklem rmack...@uoguelph.ca wrote
in
Daniel Braniss wrote:
Daniel Braniss wrote:
Daniel Braniss wrote:
Security_Multipart(Fri_Apr_27_13_35_56_2012_748)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Rick Macklem rmack...@uoguelph.ca wrote
in
Security_Multipart(Fri_Apr_27_13_35_56_2012_748)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Rick Macklem rmack...@uoguelph.ca wrote
in 1527622626.3418715.1335445225510.javamail.r...@erie.cs.uoguelph.ca:
rm Steven Hartland wrote:
rm Original
Daniel Braniss wrote:
Security_Multipart(Fri_Apr_27_13_35_56_2012_748)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Rick Macklem rmack...@uoguelph.ca wrote
in
1527622626.3418715.1335445225510.javamail.r...@erie.cs.uoguelph.ca:
rm Steven
- Original Message -
From: Rick Macklem rmack...@uoguelph.ca
To: Oliver Brandmueller o...@e-gitt.net
Cc: freebsd-stable@freebsd.org
Sent: Thursday, April 26, 2012 1:24 AM
Subject: Re: 9-STABLE, ZFS, NFS, ggatec - suspected memory leak
Oliver Brandmueller wrote:
Hi,
After figuring
Hi,
On Wed, Apr 25, 2012 at 05:34:05PM -0400, Rick Macklem wrote:
Good work isolating this!
Thank you!
I now see the problem. The new NFS server code assumed that VOP_LOOKUP()
calls would not set SAVENAME, so it expected the path buffer to be free'd
by the nfsvno_namei() when it hadn't set
Oliver Brandmueller wrote:
Hi,
On Wed, Apr 25, 2012 at 05:34:05PM -0400, Rick Macklem wrote:
Good work isolating this!
Thank you!
I now see the problem. The new NFS server code assumed that
VOP_LOOKUP()
calls would not set SAVENAME, so it expected the path buffer to be
free'd
Steven Hartland wrote:
- Original Message -
From: Rick Macklem rmack...@uoguelph.ca
To: Oliver Brandmueller o...@e-gitt.net
Cc: freebsd-stable@freebsd.org
Sent: Thursday, April 26, 2012 1:24 AM
Subject: Re: 9-STABLE, ZFS, NFS, ggatec - suspected memory leak
Oliver Brandmueller
Original Message -
From: Rick Macklem rmack...@uoguelph.ca
At a glance, it looks to me like 8.x is affected. Note that the
bug only affects the new NFS server (the experimental one for 8.x)
when exporting ZFS volumes. (UFS exported volumes don't leak)
If you are running a server that
Steven Hartland wrote:
Original Message -
From: Rick Macklem rmack...@uoguelph.ca
At a glance, it looks to me like 8.x is affected. Note that the
bug only affects the new NFS server (the experimental one for 8.x)
when exporting ZFS volumes. (UFS exported volumes don't leak)
If
Rick Macklem rmack...@uoguelph.ca wrote
in 1527622626.3418715.1335445225510.javamail.r...@erie.cs.uoguelph.ca:
rm Steven Hartland wrote:
rm Original Message -
rm From: Rick Macklem rmack...@uoguelph.ca
rm At a glance, it looks to me like 8.x is affected. Note that the
rm bug only
Oliver Brandmueller wrote:
Hi,
After figuring an easy way to repeat the behaviour and hunting it down
to the combination of ZFS+newNFS and removal of files or directories I
opened PR kern/167266
Good work isolating this!
I now see the problem. The new NFS server code assumed that
Oliver Brandmueller wrote:
Hi,
After figuring an easy way to repeat the behaviour and hunting it down
to the combination of ZFS+newNFS and removal of files or directories I
opened PR kern/167266
Oops, the patch for this is at:
http://people.freebsd.org/~rmacklem/namei-leak.patch
rick
Hi,
After figuring an easy way to repeat the behaviour and hunting it down
to the combination of ZFS+newNFS and removal of files or directories I
opened PR kern/167266
Greetings,
Oliver
--
| Oliver Brandmueller http://sysadm.in/ o...@sysadm.in |
|
Hi,
On Fri, Mar 30, 2012 at 09:02:03PM +, Philip M. Gollucci wrote:
http://lists.freebsd.org/pipermail/freebsd-questions/2012-March/239643.html
Same issue different thread. Different software.
Its not NFS, its ZFS.
I don't really have a place to try it on 8.2, but my hunch from
Hi,
On Fri, Mar 30, 2012 at 09:02:03PM +, Philip M. Gollucci wrote:
http://lists.freebsd.org/pipermail/freebsd-questions/2012-March/239643.html
Same issue different thread. Different software.
Its not NFS, its ZFS.
I don't really have a place to try it on 8.2, but my hunch from
Hi,
On Fri, Mar 30, 2012 at 09:02:03PM +, Philip M. Gollucci wrote:
http://lists.freebsd.org/pipermail/freebsd-questions/2012-March/239643.html
Same issue different thread. Different software.
Its not NFS, its ZFS.
I don't really have a place to try it on 8.2, but my hunch from
Hi all,
Setup:
I'm running 2 machines (amd64, 16GB) with FreeBSD 9-STABLE (Mar 14 so
far) acting as NFS servers. They each serve 3 zpools (holding a single
zfs, hourly snapshots). The zpools each are 3-way mirrors of ggate
devices, each 2 TB, so 2 TB per zpool. Compression is on (to save
http://lists.freebsd.org/pipermail/freebsd-questions/2012-March/239643.html
Same issue different thread. Different software.
Its not NFS, its ZFS.
I don't really have a place to try it on 8.2, but my hunch from things
I've done rather similarly which don't cause tell me its a new issue in
9.0,
23 matches
Mail list logo