From owner-freebsd-fs@freebsd.org Sun Jan 17 03:59:04 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E847AA6A952 for ; Sun, 17 Jan 2016 03:59:04 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6402C13A4 for ; Sun, 17 Jan 2016 03:59:04 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u0H3wx5G001360 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 17 Jan 2016 05:58:59 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u0H3wx5G001360 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u0H3wwXe001359; Sun, 17 Jan 2016 05:58:58 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 17 Jan 2016 05:58:58 +0200 From: Konstantin Belousov To: Rick Macklem Cc: FreeBSD Filesystems , Kirk McKusick Subject: Re: panic ffs_truncate3 (maybe fuse being evil) Message-ID: <20160117035858.GO3942@kib.kiev.ua> References: <1696608910.154845456.1452438117036.JavaMail.zimbra@uoguelph.ca> <1773157955.158922767.1452698181137.JavaMail.zimbra@uoguelph.ca> <1351730674.159022044.1452699617235.JavaMail.zimbra@uoguelph.ca> <20160114092934.GL72455@kib.kiev.ua> <964333498.161527381.1452827658163.JavaMail.zimbra@uoguelph.ca> <20160115095749.GC3942@kib.kiev.ua> <1817287612.162823118.1452909605928.JavaMail.zimbra@uoguelph.ca> <20160116191116.GI3942@kib.kiev.ua> <853868666.163292727.1452986431921.JavaMail.zimbra@uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <853868666.163292727.1452986431921.JavaMail.zimbra@uoguelph.ca> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2016 03:59:05 -0000 On Sat, Jan 16, 2016 at 06:20:31PM -0500, Rick Macklem wrote: > Kostik wrote: > > Was IO_EXT flag passed to the ffs_truncate() invocation where the > > assert ffs_truncate3 fired ? > > > Yes. The only call to UFS_TRUNCATE() in ufs_inactive() specified both > IO_EXT | IO_NORMAL. Please try this. diff --git a/sys/ufs/ffs/ffs_vnops.c b/sys/ufs/ffs/ffs_vnops.c index 381f6f8..ecc3f9b 100644 --- a/sys/ufs/ffs/ffs_vnops.c +++ b/sys/ufs/ffs/ffs_vnops.c @@ -1313,7 +1313,8 @@ ffs_close_ea(struct vnode *vp, int commit, struct ucred *cred, struct thread *td /* XXX: I'm not happy about truncating to zero size */ if (ip->i_ea_len < dp->di_extsize) error = ffs_truncate(vp, 0, IO_EXT, cred); - error = ffs_extwrite(vp, &luio, IO_EXT | IO_SYNC, cred); + error = ffs_extwrite(vp, &luio, IO_EXT | IO_SYNC | IO_UNIT, + cred); } if (--ip->i_ea_refs == 0) { free(ip->i_ea_area, M_TEMP); From owner-freebsd-fs@freebsd.org Sun Jan 17 07:35:56 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 39ECAA85747 for ; Sun, 17 Jan 2016 07:35:56 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail105.syd.optusnet.com.au (mail105.syd.optusnet.com.au [211.29.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id DC14B1E59 for ; Sun, 17 Jan 2016 07:35:55 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-166-197.carlnfd1.nsw.optusnet.com.au (c211-30-166-197.carlnfd1.nsw.optusnet.com.au [211.30.166.197]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id 95D3F1043BBB; Sun, 17 Jan 2016 18:35:44 +1100 (AEDT) Date: Sun, 17 Jan 2016 18:35:43 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov cc: Rick Macklem , FreeBSD Filesystems , Kirk McKusick Subject: Re: panic ffs_truncate3 (maybe fuse being evil) In-Reply-To: <20160117035858.GO3942@kib.kiev.ua> Message-ID: <20160117172549.C11309@besplex.bde.org> References: <1696608910.154845456.1452438117036.JavaMail.zimbra@uoguelph.ca> <1773157955.158922767.1452698181137.JavaMail.zimbra@uoguelph.ca> <1351730674.159022044.1452699617235.JavaMail.zimbra@uoguelph.ca> <20160114092934.GL72455@kib.kiev.ua> <964333498.161527381.1452827658163.JavaMail.zimbra@uoguelph.ca> <20160115095749.GC3942@kib.kiev.ua> <1817287612.162823118.1452909605928.JavaMail.zimbra@uoguelph.ca> <20160116191116.GI3942@kib.kiev.ua> <853868666.163292727.1452986431921.JavaMail.zimbra@uoguelph.ca> <20160117035858.GO3942@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=R4L+YolX c=1 sm=1 tr=0 a=KA6XNC2GZCFrdESI5ZmdjQ==:117 a=PO7r1zJSAAAA:8 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=JzwRw_2MAAAA:8 a=kj9zAlcOel0A:10 a=RQzWn0Zg5Lz1cNM0FkkA:9 a=CjuIK1q_8ugA:10 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2016 07:35:56 -0000 On Sun, 17 Jan 2016, Konstantin Belousov wrote: > On Sat, Jan 16, 2016 at 06:20:31PM -0500, Rick Macklem wrote: >> Kostik wrote: >>> Was IO_EXT flag passed to the ffs_truncate() invocation where the >>> assert ffs_truncate3 fired ? >>> >> Yes. The only call to UFS_TRUNCATE() in ufs_inactive() specified both >> IO_EXT | IO_NORMAL. > > Please try this. > > diff --git a/sys/ufs/ffs/ffs_vnops.c b/sys/ufs/ffs/ffs_vnops.c > index 381f6f8..ecc3f9b 100644 > --- a/sys/ufs/ffs/ffs_vnops.c > +++ b/sys/ufs/ffs/ffs_vnops.c > @@ -1313,7 +1313,8 @@ ffs_close_ea(struct vnode *vp, int commit, struct ucred *cred, struct thread *td > /* XXX: I'm not happy about truncating to zero size */ > if (ip->i_ea_len < dp->di_extsize) > error = ffs_truncate(vp, 0, IO_EXT, cred); > - error = ffs_extwrite(vp, &luio, IO_EXT | IO_SYNC, cred); > + error = ffs_extwrite(vp, &luio, IO_EXT | IO_SYNC | IO_UNIT, > + cred); > } IO_UNIT shouldn't exist. Its only use is to create bugs by omitting it in callers or not supporting it in callees. These bugs are rare because since vn_write() always sets it. Hopefully callees that ignore it are rare. fuse ignores it but says that it always does it since it is not worth optimizing rare cases. fuse probably doesn't understand that rare means never for normal writes. zfs also checks it for reads, but it is never passed for reads AFAIK (vn_read() never sets it). ffs does some backing out even if IO_UNIT is not set. IO_UNIT seems to have last been much more than a no-op in Feb 1997 in FreeBSD and in 1993 in 4.4BSD. Then it was used to create bugs in most callers by not setting it in the main vn_write() caller. This bug was in 4.4BSD-Lite1 in 1993 but was fixed in 4.4BSD-Lite2 in 1995. FreeBSD imported the 1-line fix in 1997. This fix had some style bugs (initialization in declaration) which were fixed in 1999. The larger style bug of not removing the flag is still there. Grepping for VOP_WRITE in kern shows just 1 caller that is missing the flag, and that caller is broken: vop_stdallocate() passes ioflag 0, and then has the usual buggy error handling for non-atomic and/or short writes. IO_UNIT is needed more for avoiding short writes than for giving atomicity, since most callers have the usual sloppy error handling and sys_generic.c still has its old bugs for short i/o's. Non-buggy error handling might be as simple as backing out of the whole i/o, just like IO_UNIT would do for disk files. The actual handling in vop_stdallocate() is to abort. When combined with uio, this should result in a short write or a successful short write. But upper layers can't be trusted to handle short writes correctly. VOP_ALLOCATE()'s caller kern_posix_fallocate() seems to understand this stuff even less than old write calls in sys_generic.c. The old have the necessary handling for ERESTART, EINTR and EWOULDBLOCK although not for other errors. kern_posix_fallocate() just aborts. This results in short writes being returned as errors with no sign that the write is partially complete. The easiest to exercise error is EFAULT. IO_UNIT avoids the bugs in sys_generic.c by backing out of the whole write, so that EFAULT becomes the correct error. posix_fallocate() needs IO_UNIT even more than write() since it doesn't support partial successes. Setting IO_UNIT for all file types in vn_write() is not so good. Too many file types that can't support it go through vn_write(). It should be an error for them, but is just ignored. Some file types like pipes could reasonably try to support it if it is set. E.g., {PIPE_BUF} gives the normal limit of for atomic writes on pipes, bug it would be reasonable to use IO_UNIT to specify trying to do larger atomic writes and failing if this is not possible. Layering makes it a bit hard to see if IO_UNIT is set. E.g., it must be set in callers of vn_rdwr_inchunks(). core_write() does this for imgact_elf.c. core_write() also passes IO_DIRECT, which I think is a pessimization. I think IO_UNIT is not very important for security here. It is just that the error handling in the caller is so sloppy that the callee should do it, and backing out of all of even a huge write is the best error handling for core dumps. ENOSPACE is quite a likely error for a core dump and discarding a few TB to recover from it is no worse than wasting time writing that much. vn_rdwr_inchunks() is easy to analyze since it has no other callers. It used to be used for aout core dumps but those are broken (unsupported) now. Bruce From owner-freebsd-fs@freebsd.org Sun Jan 17 08:01:27 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E5E68A85F89 for ; Sun, 17 Jan 2016 08:01:27 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail105.syd.optusnet.com.au (mail105.syd.optusnet.com.au [211.29.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id A9F6515E3 for ; Sun, 17 Jan 2016 08:01:27 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-166-197.carlnfd1.nsw.optusnet.com.au (c211-30-166-197.carlnfd1.nsw.optusnet.com.au [211.30.166.197]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id 28066104370D; Sun, 17 Jan 2016 19:01:24 +1100 (AEDT) Date: Sun, 17 Jan 2016 19:01:23 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Bruce Evans cc: Konstantin Belousov , Rick Macklem , FreeBSD Filesystems , Kirk McKusick Subject: Re: panic ffs_truncate3 (maybe fuse being evil) In-Reply-To: <20160117172549.C11309@besplex.bde.org> Message-ID: <20160117184105.B11529@besplex.bde.org> References: <1696608910.154845456.1452438117036.JavaMail.zimbra@uoguelph.ca> <1773157955.158922767.1452698181137.JavaMail.zimbra@uoguelph.ca> <1351730674.159022044.1452699617235.JavaMail.zimbra@uoguelph.ca> <20160114092934.GL72455@kib.kiev.ua> <964333498.161527381.1452827658163.JavaMail.zimbra@uoguelph.ca> <20160115095749.GC3942@kib.kiev.ua> <1817287612.162823118.1452909605928.JavaMail.zimbra@uoguelph.ca> <20160116191116.GI3942@kib.kiev.ua> <853868666.163292727.1452986431921.JavaMail.zimbra@uoguelph.ca> <20160117035858.GO3942@kib.kiev.ua> <20160117172549.C11309@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=cK4dyQqN c=1 sm=1 tr=0 a=KA6XNC2GZCFrdESI5ZmdjQ==:117 a=PO7r1zJSAAAA:8 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=JzwRw_2MAAAA:8 a=kj9zAlcOel0A:10 a=-ugR41hp6K_lOZtdyDYA:9 a=CjuIK1q_8ugA:10 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2016 08:01:28 -0000 On Sun, 17 Jan 2016, Bruce Evans wrote: > IO_UNIT shouldn't exist. Its only use is to create bugs by omitting it > in callers or not supporting it in callees. These bugs are rare because > ... > Layering makes it a bit hard to see if IO_UNIT is set. E.g., it must > be set in callers of vn_rdwr_inchunks(). core_write() does this > for imgact_elf.c. core_write() also passes IO_DIRECT, which I think > ... > vn_rdwr_inchunks() is easy to analyze since it has no other callers. > It used to be used for aout core dumps but those are broken > (unsupported) now. vn_rdwr_inchunks() has additional design and implementation errors: - it can't possibly be atomic (except sort of, using an exclusive lock). Only each chunk can be written atomically. - it could honor IO_UNIT to the extent of backing out of the whole write, but it doesn't just passes this flag on - callers make multiple calls to it (once per segment for elf), so backing out in it alone is neither necessary nor sufficient. So IO_UNIT for each chunk is even less necessary and less sufficient. The core_write() caller has sloppy error handling and doesn't back out. Its normal error handling for ENOSPACE caused by itself is to print a message and leave a huge truncated file and ENOSPACE for everything. Bruce From owner-freebsd-fs@freebsd.org Sun Jan 17 08:08:58 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EF2A1A6A2D3 for ; Sun, 17 Jan 2016 08:08:58 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6D2571AF7 for ; Sun, 17 Jan 2016 08:08:58 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u0H88rX0060683 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 17 Jan 2016 10:08:53 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u0H88rX0060683 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u0H88rB7060682; Sun, 17 Jan 2016 10:08:53 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 17 Jan 2016 10:08:53 +0200 From: Konstantin Belousov To: Bruce Evans Cc: Rick Macklem , FreeBSD Filesystems , Kirk McKusick Subject: Re: panic ffs_truncate3 (maybe fuse being evil) Message-ID: <20160117080853.GP3942@kib.kiev.ua> References: <1773157955.158922767.1452698181137.JavaMail.zimbra@uoguelph.ca> <1351730674.159022044.1452699617235.JavaMail.zimbra@uoguelph.ca> <20160114092934.GL72455@kib.kiev.ua> <964333498.161527381.1452827658163.JavaMail.zimbra@uoguelph.ca> <20160115095749.GC3942@kib.kiev.ua> <1817287612.162823118.1452909605928.JavaMail.zimbra@uoguelph.ca> <20160116191116.GI3942@kib.kiev.ua> <853868666.163292727.1452986431921.JavaMail.zimbra@uoguelph.ca> <20160117035858.GO3942@kib.kiev.ua> <20160117172549.C11309@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160117172549.C11309@besplex.bde.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2016 08:08:59 -0000 On Sun, Jan 17, 2016 at 06:35:43PM +1100, Bruce Evans wrote: > Setting IO_UNIT for all file types in vn_write() is not so good. Too > many file types that can't support it go through vn_write(). It should > be an error for them, but is just ignored. Some file types like pipes > could reasonably try to support it if it is set. E.g., {PIPE_BUF} > gives the normal limit of for atomic writes on pipes, bug it would > be reasonable to use IO_UNIT to specify trying to do larger atomic > writes and failing if this is not possible. Pipes and most other special things, and even cdevs, do not perform io throught {vn,VOP}_{read,write}. The vnode bypass is common and usually that things io is routed through the file ops. From owner-freebsd-fs@freebsd.org Sun Jan 17 17:34:05 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 04339A86C23 for ; Sun, 17 Jan 2016 17:34:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E95F91F3C for ; Sun, 17 Jan 2016 17:34:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0HHY4Rc064197 for ; Sun, 17 Jan 2016 17:34:04 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 203201] on zfs extattr behaviour broken after unlink Date: Sun, 17 Jan 2016 17:34:04 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: op@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: avg@FreeBSD.org X-Bugzilla-Flags: mfc-stable10? X-Bugzilla-Changed-Fields: flagtypes.name cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2016 17:34:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D203201 Oliver Pinter changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |mfc-stable10? CC| |op@freebsd.org --- Comment #10 from Oliver Pinter --- MFC after: 17 days Do you still want to MFC this change to 10-STABLE? --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-fs@freebsd.org Sun Jan 17 18:02:47 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A1017A864FA for ; Sun, 17 Jan 2016 18:02:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 91F3A1C83 for ; Sun, 17 Jan 2016 18:02:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0HI2ljO051924 for ; Sun, 17 Jan 2016 18:02:47 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 206328] Crash on shutdown with swap on NFS file (with patch) Date: Sun, 17 Jan 2016 18:02:47 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: keywords assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2016 18:02:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206328 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sun Jan 17 20:02:42 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EB100A86CB9 for ; Sun, 17 Jan 2016 20:02:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DB1AE1AA6 for ; Sun, 17 Jan 2016 20:02:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0HK2eEB082257 for ; Sun, 17 Jan 2016 20:02:41 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 204484] ZFS caches on 4K GELI devices accumulate inordinate write errors Date: Sun, 17 Jan 2016 20:02:40 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: matthew@dresdencraft.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2016 20:02:42 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D204484 Matthew Dresden changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |matthew@dresdencraft.com --- Comment #2 from Matthew Dresden --- I have not tried to reproduce this with 512 alignment, but it is still an current issue affecting the stable release of 10.2. Is this bug getting any priority currently. Using mfsbsd boot and installing from ftp.freebsd.org with the script below, these errors appear on ever cache immediately. Example was a machine with: ada0 - 120GB ssd ada1 - 2tb ada2 - 2tb ada3 - 2tb ada4 - 2tb add5 - 2tb ada6 - 127GB ssd This occurs for me on virtual and physical machines: Here is a semi automated install script to reproduce my scenario. Instructions to use: Boot from mfsbsd usb imaged. cd /tmp fetch http:// sh install-script.sh Enter encryption password. Install completes take zpool status reboot take zpool status Script Follows: #!/bin/sh=20 cd /tmp read -p "Enter a disk encryption password: " password passfile.txt PASSFILE=3D"/tmp/passfile.txt" fetch http://ftp.freebsd.org/pub/FreeBSD/releases/amd64/10.2-RELEASE/kernel= .txz tar xvfz kernel.txz sysctl kern.geom.debugflags=3D0x10 dd bs=3D512 if=3D/dev/zero of=3D/dev/ada0 count=3D10 dd bs=3D512 if=3D/dev/zero of=3D/dev/ada1 count=3D10 dd bs=3D512 if=3D/dev/zero of=3D/dev/ada2 count=3D10 dd bs=3D512 if=3D/dev/zero of=3D/dev/ada3 count=3D10 dd bs=3D512 if=3D/dev/zero of=3D/dev/ada4 count=3D10 dd bs=3D512 if=3D/dev/zero of=3D/dev/ada5 count=3D10 dd bs=3D512 if=3D/dev/zero of=3D/dev/ada6 count=3D10 dd bs=3D1m if=3D/dev/zero of=3D/dev/ada0 & pid0=3D$(echo $!) dd bs=3D1m if=3D/dev/zero of=3D/dev/ada1 & pid1=3D$(echo $!) dd bs=3D1m if=3D/dev/zero of=3D/dev/ada2 & pid2=3D$(echo $!) dd bs=3D1m if=3D/dev/zero of=3D/dev/ada3 & pid3=3D$(echo $!) dd bs=3D1m if=3D/dev/zero of=3D/dev/ada4 & pid4=3D$(echo $!) dd bs=3D1m if=3D/dev/zero of=3D/dev/ada5 & pid5=3D$(echo $!) dd bs=3D1m if=3D/dev/zero of=3D/dev/ada6 & pid6=3D$(echo $!) printf "\nLetting dd do some work!\n" printf "\n6 minutes to go" sleep 60 printf "\n5 minutes to go" sleep 60 printf "\n4 minutes to go" sleep 60 printf "\n3 minutes to go" sleep 60 printf "\n2 minutes to go" sleep 60 printf "\n1 minutes to go" sleep 60 for i in "$pid0" "$pid1" "$pid2" "$pid3" "$pid4" "$pid5" "$pid6"=20 do printf "\nWe don't need to wait any longer -- Killing pid ${i}\n" kill "$i" done kern_mod=3D"/tmp/boot/kernel" kldload ${kern_mod}/aesni.ko kldload ${kern_mod}/geom_eli.ko kldload ${kern_mod}/zfs.ko rm -Rf "/tmp/boot" gpart create -s gpt ada0 gpart create -s gpt ada1 gpart create -s gpt ada2 gpart create -s gpt ada3 gpart create -s gpt ada4 gpart create -s gpt ada5 gpart create -s gpt ada6 # Add p1 - non encrpyted gpart add -s 64K -a 4k -t freebsd-boot ada1 #p1 gpart add -s 64K -a 4k -t freebsd-boot ada2 #p1 gpart add -s 64K -a 4k -t freebsd-boot ada3 #p1 gpart add -s 64K -a 4k -t freebsd-boot ada4 #p1 gpart add -s 64K -a 4k -t freebsd-boot ada5 #p1 # Add p2 - non encrypted boot gpart add -s 4g -a 4k -t freebsd-zfs -l boot-zfs1 ada1 #p2 gpart add -s 4g -a 4k -t freebsd-zfs -l boot-zfs2 ada2 #p2 gpart add -s 4g -a 4k -t freebsd-zfs -l boot-zfs3 ada3 #p2 gpart add -s 4g -a 4k -t freebsd-zfs -l boot-zfs4 ada4 #p2 gpart add -s 4g -a 4k -t freebsd-zfs -l boot-zfs5 ada5 #p2 # Add p1 - encrypted swap gpart add -s 20g -a 4k -t freebsd-swap -l swap1 ada0 #p1 gpart add -s 13g -a 4k -t freebsd-swap -l swap2 ada6 #p1 # Add p3 - encrypted zroot gpart add -s 16g -a 4k -t freebsd-zfs -l zroot-zfs1 ada1 #p3 gpart add -s 16g -a 4k -t freebsd-zfs -l zroot-zfs2 ada2 #p3 gpart add -s 16g -a 4k -t freebsd-zfs -l zroot-zfs3 ada3 #p3 gpart add -s 16g -a 4k -t freebsd-zfs -l zroot-zfs4 ada4 #p3 gpart add -s 16g -a 4k -t freebsd-zfs -l zroot-zfs5 ada5 #p3 # Add p2 - encrypted zroot logzil gpart add -s 8g -a 4k -t freebsd-zfs -l zroot-log1 ada0 #p2 gpart add -s 8g -a 4k -t freebsd-zfs -l zroot-log2 ada6 #p2 # Add p3 - encrypted zroot cache gpart add -s 8g -a 4k -t freebsd-zfs -l zroot-cache1 ada0 #p3 gpart add -s 8g -a 4k -t freebsd-zfs -l zroot-cache2 ada6 #p3 # Add p4 - encrypted datastore gpart add -a 4k -t freebsd-zfs -l datastore-zfs1 ada1 #p4 gpart add -a 4k -t freebsd-zfs -l datastore-zfs2 ada2 #p4 gpart add -a 4k -t freebsd-zfs -l datastore-zfs3 ada3 #p4 gpart add -a 4k -t freebsd-zfs -l datastore-zfs4 ada4 #p4 gpart add -a 4k -t freebsd-zfs -l datastore-zfs5 ada5 #p4 # Add p4 - encrypted datastore logzil gpart add -s 8g -a 4k -t freebsd-zfs -l datastore-log1 ada0 #p4 gpart add -s 8g -a 4k -t freebsd-zfs -l datastore-log2 ada6 #p4 # Add p5 - encrypted datastore cache gpart add -a 4k -t freebsd-zfs -l datastore-cache1 ada0 #p5 gpart add -a 4k -t freebsd-zfs -l datastore-cache2 ada6 #p5 gpart set -a bootme -i 2 ada1 gpart set -a bootme -i 2 ada2 gpart set -a bootme -i 2 ada3 gpart set -a bootme -i 2 ada4 gpart set -a bootme -i 2 ada5 gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada1 gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada2 gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada3 gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada4 gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada5 mkdir /root/keys dd if=3D/dev/random of=3D/root/keys/boot.key bs=3D128k count=3D1 geli init -J $PASSFILE -b -K /root/keys/boot.key -s 4096 -l 256 /dev/gpt/sw= ap1 geli init -J $PASSFILE -b -K /root/keys/boot.key -s 4096 -l 256 /dev/gpt/sw= ap2 geli init -J $PASSFILE -b -K /root/keys/boot.key -s 4096 -l 256 /dev/gpt/zroot-zfs1 geli init -J $PASSFILE -b -K /root/keys/boot.key -s 4096 -l 256 /dev/gpt/zroot-zfs2 geli init -J $PASSFILE -b -K /root/keys/boot.key -s 4096 -l 256 /dev/gpt/zroot-zfs3 geli init -J $PASSFILE -b -K /root/keys/boot.key -s 4096 -l 256 /dev/gpt/zroot-zfs4 geli init -J $PASSFILE -b -K /root/keys/boot.key -s 4096 -l 256 /dev/gpt/zroot-zfs5 geli init -J $PASSFILE -b -K /root/keys/boot.key -s 4096 -l 256 /dev/gpt/zroot-log1 geli init -J $PASSFILE -b -K /root/keys/boot.key -s 4096 -l 256 /dev/gpt/zroot-log2 geli init -J $PASSFILE -b -K /root/keys/boot.key -s 4096 -l 256 /dev/gpt/zroot-cache1 geli init -J $PASSFILE -b -K /root/keys/boot.key -s 4096 -l 256 /dev/gpt/zroot-cache2 geli init -J $PASSFILE -b -K /root/keys/boot.key -s 4096 -l 256 /dev/gpt/datastore-zfs1 geli init -J $PASSFILE -b -K /root/keys/boot.key -s 4096 -l 256 /dev/gpt/datastore-zfs2 geli init -J $PASSFILE -b -K /root/keys/boot.key -s 4096 -l 256 /dev/gpt/datastore-zfs3 geli init -J $PASSFILE -b -K /root/keys/boot.key -s 4096 -l 256 /dev/gpt/datastore-zfs4 geli init -J $PASSFILE -b -K /root/keys/boot.key -s 4096 -l 256 /dev/gpt/datastore-zfs5 geli init -J $PASSFILE -b -K /root/keys/boot.key -s 4096 -l 256 /dev/gpt/datastore-log1 geli init -J $PASSFILE -b -K /root/keys/boot.key -s 4096 -l 256 /dev/gpt/datastore-log2 geli init -J $PASSFILE -b -K /root/keys/boot.key -s 4096 -l 256 /dev/gpt/datastore-cache1 geli init -J $PASSFILE -b -K /root/keys/boot.key -s 4096 -l 256 /dev/gpt/datastore-cache2 geli attach -j $PASSFILE -k /root/keys/boot.key /dev/gpt/swap1 geli attach -j $PASSFILE -k /root/keys/boot.key /dev/gpt/swap2 geli attach -j $PASSFILE -k /root/keys/boot.key /dev/gpt/zroot-zfs1 geli attach -j $PASSFILE -k /root/keys/boot.key /dev/gpt/zroot-zfs2 geli attach -j $PASSFILE -k /root/keys/boot.key /dev/gpt/zroot-zfs3 geli attach -j $PASSFILE -k /root/keys/boot.key /dev/gpt/zroot-zfs4 geli attach -j $PASSFILE -k /root/keys/boot.key /dev/gpt/zroot-zfs5 geli attach -j $PASSFILE -k /root/keys/boot.key /dev/gpt/zroot-log1 geli attach -j $PASSFILE -k /root/keys/boot.key /dev/gpt/zroot-log2 geli attach -j $PASSFILE -k /root/keys/boot.key /dev/gpt/zroot-cache1 geli attach -j $PASSFILE -k /root/keys/boot.key /dev/gpt/zroot-cache2 geli attach -j $PASSFILE -k /root/keys/boot.key /dev/gpt/datastore-zfs1 geli attach -j $PASSFILE -k /root/keys/boot.key /dev/gpt/datastore-zfs2 geli attach -j $PASSFILE -k /root/keys/boot.key /dev/gpt/datastore-zfs3 geli attach -j $PASSFILE -k /root/keys/boot.key /dev/gpt/datastore-zfs4 geli attach -j $PASSFILE -k /root/keys/boot.key /dev/gpt/datastore-zfs5 geli attach -j $PASSFILE -k /root/keys/boot.key /dev/gpt/datastore-log1 geli attach -j $PASSFILE -k /root/keys/boot.key /dev/gpt/datastore-log2 geli attach -j $PASSFILE -k /root/keys/boot.key /dev/gpt/datastore-cache1 geli attach -j $PASSFILE -k /root/keys/boot.key /dev/gpt/datastore-cache2 zpool create zboot raidz1 gpt/boot-zfs1 gpt/boot-zfs2 gpt/boot-zfs3 gpt/boot-zfs4 gpt/boot-zfs5 zfs set checksum=3Dfletcher4 zboot zfs set atime=3Doff zboot zpool create -f \ -o altroot=3D/mnt \ -O canmount=3Doff \ -m none \ zroot raidz1 \ /dev/gpt/zroot-zfs1.eli \ /dev/gpt/zroot-zfs2.eli \ /dev/gpt/zroot-zfs3.eli \ /dev/gpt/zroot-zfs4.eli \ /dev/gpt/zroot-zfs5.eli zpool add zroot log mirror gpt/zroot-log1.eli gpt/zroot-log2.eli zpool add zroot cache gpt/zroot-cache1.eli gpt/zroot-cache2.eli zfs set checksum=3Dfletcher4 zroot zfs set atime=3Doff zroot zfs create -o mountpoint=3Dnone zroot/ROOT zfs create -o mountpoint=3D/ zroot/ROOT/default zfs create -o mountpoint=3D/tmp -o compression=3Dlzjb -o setuid=3Doff zroot= /tmp chmod 1777 /mnt/tmp zfs create -o mountpoint=3D/usr zroot/usr zfs create zroot/usr/local zfs create -o compression=3Dlzjb -o setuid=3Doff zroot/usr/ports zfs create -o compression=3Doff -o exec=3Doff -o setuid=3Doff zroot/usr/ports/distfiles zfs create -o compression=3Doff -o exec=3Doff -o setuid=3Doff zroot/usr/ports/packages zfs create -o compression=3Dlzjb -o exec=3Doff -o setuid=3Doff zroot/usr/src zfs create zroot/usr/obj zfs create -o mountpoint=3D/var zroot/var zfs create -o compression=3Dlzjb -o exec=3Doff -o setuid=3Doff zroot/var/cr= ash zfs create -o exec=3Doff -o setuid=3Doff zroot/var/db zfs create -o compression=3Dlzjb -o exec=3Don -o setuid=3Doff zroot/var/db/= pkg zfs create -o exec=3Doff -o setuid=3Doff zroot/var/empty zfs create -o compression=3Dlzjb -o exec=3Doff -o setuid=3Doff zroot/var/log zfs create -o compression=3Dgzip -o exec=3Doff -o setuid=3Doff zroot/var/ma= il zfs create -o exec=3Doff -o setuid=3Doff zroot/var/run zfs create -o compression=3Dlzjb -o exec=3Don -o setuid=3Doff zroot/var/tmp chmod 1777 /mnt/var/tmp zpool create -m /mnt/datastore datastore raidz1 gpt/datastore-zfs1.eli gpt/datastore-zfs2.eli gpt/datastore-zfs3.eli gpt/datastore-zfs4.eli gpt/datastore-zfs5.eli zpool add datastore log mirror gpt/datastore-log1.eli gpt/datastore-log2.eli zpool add datastore cache gpt/datastore-cache1.eli gpt/datastore-cache2.eli zfs set checksum=3Dfletcher4 datastore zfs set atime=3Doff datastore zfs set compression=3Dlz4 zfs create -o mountpoint=3D/home -o setuid=3Doff datastore/home cd /tmp fetch http://ftp.freebsd.org/pub/FreeBSD/releases/amd64/10.2-RELEASE/base.t= xz fetch http://ftp.freebsd.org/pub/FreeBSD/releases/amd64/10.2-RELEASE/doc.txz fetch http://ftp.freebsd.org/pub/FreeBSD/releases/amd64/10.2-RELEASE/lib32.= txz fetch http://ftp.freebsd.org/pub/FreeBSD/releases/amd64/10.2-RELEASE/ports.= txz fetch http://ftp.freebsd.org/pub/FreeBSD/releases/amd64/10.2-RELEASE/src.txz for i in base doc kernel lib32 ports src; do \ xz -d -c $i.txz | tar -C /mnt/ -xf - ; \ done cat << EOF > /mnt/etc/fstab /dev/ada0p1.eli none swap sw 0 0 /dev/ada6p1.eli none swap sw 0 0 EOF cat << EOF > /boot/loader.conf # enable AHCI driver ahci_load=3D"YES" # fs modules zfs_load=3D"YES" fdescfs_load=3D"YES" nullfs_load=3D"YES" # CTL ISCSI ctl_load=3D"YES" # Lagg support if_lagg_load=3D"YES" # Crypto stuff geom_eli_load=3D"YES" crypto_load=3D"YES" aesni_load=3D"YES" cryptodev_load=3D"YES" # pf stuff pf_load=3D"YES" pflog_load=3D"YES" # zfs tuning vm.kmem_size=3D"8192M" vm.kmem_size_max=3D"8192M" vfs.zfs.arc_max=3D"8192M" vfs.zfs.prefetch_disable=3D"1" vfs.zfs.zio.use_uma=3D"0" vfs.zfs.txg.timeout=3D"5" vfs.zfs.txg.write_limit_override=3D1073741824 # disk encryption key load geli_ada0p1_keyfile0_load=3D"YES" geli_ada0p1_keyfile0_type=3D"ada0p1:geli_keyfile0" geli_ada0p1_keyfile0_name=3D"/boot/keys/boot.key" geli_ada0p2_keyfile0_load=3D"YES" geli_ada0p2_keyfile0_type=3D"ada0p2:geli_keyfile0" geli_ada0p2_keyfile0_name=3D"/boot/keys/boot.key" geli_ada0p3_keyfile0_load=3D"YES" geli_ada0p3_keyfile0_type=3D"ada0p3:geli_keyfile0" geli_ada0p3_keyfile0_name=3D"/boot/keys/boot.key" geli_ada0p4_keyfile0_load=3D"YES" geli_ada0p4_keyfile0_type=3D"ada0p4:geli_keyfile0" geli_ada0p4_keyfile0_name=3D"/boot/keys/boot.key" geli_ada0p5_keyfile0_load=3D"YES" geli_ada0p5_keyfile0_type=3D"ada0p5:geli_keyfile0" geli_ada0p5_keyfile0_name=3D"/boot/keys/boot.key" geli_ada6p1_keyfile0_load=3D"YES" geli_ada6p1_keyfile0_type=3D"ada6p1:geli_keyfile0" geli_ada6p1_keyfile0_name=3D"/boot/keys/boot.key" geli_ada6p2_keyfile0_load=3D"YES" geli_ada6p2_keyfile0_type=3D"ada6p2:geli_keyfile0" geli_ada6p2_keyfile0_name=3D"/boot/keys/boot.key" geli_ada6p3_keyfile0_load=3D"YES" geli_ada6p3_keyfile0_type=3D"ada6p3:geli_keyfile0" geli_ada6p3_keyfile0_name=3D"/boot/keys/boot.key" geli_ada6p4_keyfile0_load=3D"YES" geli_ada6p4_keyfile0_type=3D"ada6p4:geli_keyfile0" geli_ada6p4_keyfile0_name=3D"/boot/keys/boot.key" geli_ada6p5_keyfile0_load=3D"YES" geli_ada6p5_keyfile0_type=3D"ada6p5:geli_keyfile0" geli_ada6p5_keyfile0_name=3D"/boot/keys/boot.key" geli_ada1p2_keyfile0_load=3D"YES" geli_ada1p2_keyfile0_type=3D"ada1p2:geli_keyfile0" geli_ada1p2_keyfile0_name=3D"/boot/keys/boot.key" geli_ada1p3_keyfile0_load=3D"YES" geli_ada1p3_keyfile0_type=3D"ada1p3:geli_keyfile0" geli_ada1p3_keyfile0_name=3D"/boot/keys/boot.key" geli_ada1p4_keyfile0_load=3D"YES" geli_ada1p4_keyfile0_type=3D"ada1p4:geli_keyfile0" geli_ada1p4_keyfile0_name=3D"/boot/keys/boot.key" geli_ada2p2_keyfile0_load=3D"YES" geli_ada2p2_keyfile0_type=3D"ada2p2:geli_keyfile0" geli_ada2p2_keyfile0_name=3D"/boot/keys/boot.key" geli_ada2p3_keyfile0_load=3D"YES" geli_ada2p3_keyfile0_type=3D"ada2p3:geli_keyfile0" geli_ada2p3_keyfile0_name=3D"/boot/keys/boot.key" geli_ada2p4_keyfile0_load=3D"YES" geli_ada2p4_keyfile0_type=3D"ada2p4:geli_keyfile0" geli_ada2p4_keyfile0_name=3D"/boot/keys/boot.key" geli_ada3p2_keyfile0_load=3D"YES" geli_ada3p2_keyfile0_type=3D"ada3p2:geli_keyfile0" geli_ada3p2_keyfile0_name=3D"/boot/keys/boot.key" geli_ada3p3_keyfile0_load=3D"YES" geli_ada3p3_keyfile0_type=3D"ada3p3:geli_keyfile0" geli_ada3p3_keyfile0_name=3D"/boot/keys/boot.key" geli_ada3p4_keyfile0_load=3D"YES" geli_ada3p4_keyfile0_type=3D"ada3p4:geli_keyfile0" geli_ada3p4_keyfile0_name=3D"/boot/keys/boot.key" geli_ada4p2_keyfile0_load=3D"YES" geli_ada4p2_keyfile0_type=3D"ada4p2:geli_keyfile0" geli_ada4p2_keyfile0_name=3D"/boot/keys/boot.key" geli_ada4p3_keyfile0_load=3D"YES" geli_ada4p3_keyfile0_type=3D"ada4p3:geli_keyfile0" geli_ada4p3_keyfile0_name=3D"/boot/keys/boot.key" geli_ada4p4_keyfile0_load=3D"YES" geli_ada4p4_keyfile0_type=3D"ada4p4:geli_keyfile0" geli_ada4p4_keyfile0_name=3D"/boot/keys/boot.key" geli_ada5p2_keyfile0_load=3D"YES" geli_ada5p2_keyfile0_type=3D"ada5p2:geli_keyfile0" geli_ada5p2_keyfile0_name=3D"/boot/keys/boot.key" geli_ada5p3_keyfile0_load=3D"YES" geli_ada5p3_keyfile0_type=3D"ada5p3:geli_keyfile0" geli_ada5p3_keyfile0_name=3D"/boot/keys/boot.key" geli_ada5p4_keyfile0_load=3D"YES" geli_ada5p4_keyfile0_type=3D"ada5p4:geli_keyfile0" geli_ada5p4_keyfile0_name=3D"/boot/keys/boot.key" # Mount root vfs.root.mountfrom=3D"zfs:zroot/ROOT/default" EOF cat << EOF > /mnt/etc/rc.conf # Network hostname=3D"example.example.com" ifconfig_em0=3D"DHCP" # zfs zfs_enable=3D"YES" # ssh server sshd_enable=3D"YES" # ntp client ntpd_enable=3D"YES" ntpd_sync_on_start=3D"YES" # NFS Server rpcbind_enable=3D"YES" rpc_lockd_enable=3D"YES" rpc_statd_enable=3D"YES" nfs_server_enable=3D"YES" # the number of nfsds to run [-n] should be: (Number-of-clients + 1) * 4 nfs_server_flags=3D"-u -t -n 100" mountd_enable=3D"YES" mountd_flags=3D"-r -p 100" #ISCSI Target Native Service ctld_enable=3D"YES" # disable Sendmail sendmail_enable=3D"NO" sendmail_submit_enable=3D"NO" sendmail_outbound_enable=3D"NO" sendmail_msp_queue_enable=3D"NO" # Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable dumpdev=3D"AUTO" # powerd #powerd_enable=3D"YES" # motd motd_enable=3D"yes" EOF cat << EOF >> /mnt/etc/sysctl.conf kern.maxvnodes=3D260000 EOF touch /mnt/etc/ctl.conf touch /mnt/etc/exports # Final work cp /boot/zfs/zpool.cache /mnt/boot/zfs/ cp -pR /root/keys /mnt/boot/ mkdir -p /zboot/boot cp -pR /mnt/boot/* /zboot/boot/ cp /boot/loader.conf /zboot/boot/ # Command to run following an freebsd update # rsync -alv --human-readable --delete -c -i /boot/ /zboot/boot/ --exclude loader.conf --exclude keys --exclude boot.key --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sun Jan 17 21:00:34 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 79CB6A86E98 for ; Sun, 17 Jan 2016 21:00:34 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 57144137C for ; Sun, 17 Jan 2016 21:00:34 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0HL01bM084776 for ; Sun, 17 Jan 2016 21:00:34 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201601172100.u0HL01bM084776@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-fs@FreeBSD.org Subject: Problem reports for freebsd-fs@FreeBSD.org that need special attention Date: Sun, 17 Jan 2016 21:00:34 +0000 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2016 21:00:34 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- New | 203492 | mount_unionfs -o below causes panic Open | 136470 | [nfs] Cannot mount / in read-only, over NFS Open | 139651 | [nfs] mount(8): read-only remount of NFS volume d Open | 144447 | [zfs] sharenfs fsunshare() & fsshare_main() non f 4 problems total for which you should take action. From owner-freebsd-fs@freebsd.org Mon Jan 18 06:45:06 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 44A5EA86099 for ; Mon, 18 Jan 2016 06:45:06 +0000 (UTC) (envelope-from wanpengqian@gmail.com) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 01D161B60 for ; Mon, 18 Jan 2016 06:45:06 +0000 (UTC) (envelope-from wanpengqian@gmail.com) Received: by mail-vk0-x233.google.com with SMTP id i129so188416012vkb.0 for ; Sun, 17 Jan 2016 22:45:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=PQ2VIWWMb0TVGSg4Zv/j+amv0fTHb94kmutP/fLg9p8=; b=bJggwlTVer/stNgGD4Aza5F0xc6FTMMmJCZ/oEtIQS6hkErFht6f4OEJnXL5hhF006 OTStcuNZTclM87XawPdXKEw+j4LTEGN7/TwEnnkCW51xRz4ilE2jkvTI36kIs5pUb/6A GksgOS7OqmakyLu87qb79OyfHZv1vB8Rmx7IR4rSw8fN8CeEFFxOLk+/Y8s+bX5MkgTv fieoqI5A0UWV/aRfZteGNNO1D3OgPL0nj7w6ZLlVb7DmadU+XLogjZSvVh8OBcuCdfqc ThSSnuLka4tedxCGstd62YHVeZ66xh0yC46orCfXc8wv64fvjQVrn6uNOEZrkhtTibdm Bctw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=PQ2VIWWMb0TVGSg4Zv/j+amv0fTHb94kmutP/fLg9p8=; b=GOmDTrhLj1igBZ4KbKQwyeWHh9RrmQ97rFHyUNBAwlUCaLvj1K/V0S1ISQuJE3w79o dQy1uPFPM1cIYol7owrnbiIWB2RAQ1OHH4P1Os0k5hlV7WSUNG2CMTxVmIRAIdjyIgV2 uzwfjJKlUIkhlGDtusvOSIr36EVxCSriWld6aEkYX+S06qLSpgUaWrql5OL/lBxmqQHQ gDmHw+e4KY7g18LygWlnhYo0wIoR8yfwzFFq4pIu8ZlMn5ocB0z9US/5h2zn75rajIfJ 7LJvz//oorT1DZYfiG58Si2ilVXz3phwAM1eAobQXGduZ+CG4Iy2jizagp06y8ijbx5J Z+0w== X-Gm-Message-State: ALoCoQlJ6FkGS+38maIBflacnO31UgoFu0qrsUNtYknT9kwticHaOyG3EiQXymGamcKPFG1HvF11fxoeTZ3zkpgkVNy3k+j1BQ== MIME-Version: 1.0 X-Received: by 10.31.179.80 with SMTP id c77mr14187628vkf.50.1453099504595; Sun, 17 Jan 2016 22:45:04 -0800 (PST) Received: by 10.31.87.1 with HTTP; Sun, 17 Jan 2016 22:45:04 -0800 (PST) Date: Mon, 18 Jan 2016 15:45:04 +0900 Message-ID: Subject: ZFS WARNING: Unable to create ZVOL (error=17). From: Qian Wanpeng To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 06:45:06 -0000 Hello. I am running bhyve with 11 Current. SVN version is r291495 and I have problem about zfs recv -F basicly. I backup the vm machine by zfs send -R /zones/vm/win7pro@20160117 | lz4 - win7pro_20161117.lz4 and then transfer win7pro_20161117.lz4 to other machine, and then using lz4cat win7pro_20161117.lz4 | zfs recv -F zones/vm/win7pro to have a copy. I do this several times with other vms, it runs fine. today when I run zfs recv, the dmesg has a WARNING message: ZFS WARNING: Unable to create ZVOL zones/vm/win7pro/disk0@afterinstall (error=17). (I also have a snapshot of afterinstall) and zfs list -t snapshot is zones/vm/win7pro@afterinstall 11.5K - 21.5K - zones/vm/win7pro@20160117 12K - 22.5K - zones/vm/win7pro/disk0@afterinstall 2.70G - 5.83G - zones/vm/win7pro/disk0@20160117 10.0G - 13.1G - when I boot the VM. it crash at somepoint. any idea what is going on? I try zfs recv in the same host, same result(also has the WARNING message.) and I try dd the disk0 to file, and then restore from file. the vm runs fine. Thanks. From owner-freebsd-fs@freebsd.org Mon Jan 18 07:16:49 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1B2A0A86BE2 for ; Mon, 18 Jan 2016 07:16:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 07DA71DE3 for ; Mon, 18 Jan 2016 07:16:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0I7GmCQ072237 for ; Mon, 18 Jan 2016 07:16:48 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 176449] zfs(1): ZFS NFS export went wrong with special hostname character Date: Mon, 18 Jan 2016 07:16:49 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 9.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: everytrash@gmail.com X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 07:16:49 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D176449 --- Comment #2 from everytrash --- Any new information? It's almost 3 years now :) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Mon Jan 18 09:48:10 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B671FA857B1 for ; Mon, 18 Jan 2016 09:48:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A6E8F18D5 for ; Mon, 18 Jan 2016 09:48:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0I9mAqh076142 for ; Mon, 18 Jan 2016 09:48:10 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 206328] Crash on shutdown with swap on NFS file (with patch) Date: Mon, 18 Jan 2016 09:48:10 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: tvijlbrief@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 09:48:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206328 --- Comment #3 from Tom Vijlbrief --- bufshutdown() ends with: if (panicstr =3D=3D NULL)=20 vfs_unmountall();=20 }=20 swapoff_all();=20 Why not just reverse the order? So swapoff_all() before the vfs_unmountall(), so that the NFS filesystem is still available. Perhaps even at the start of bufshutdown(). Still wondering what the reason of a swapoff_all() call just before the act= ual reboot is. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Mon Jan 18 12:31:36 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8DB0AA87A82 for ; Mon, 18 Jan 2016 12:31:36 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 57B471963 for ; Mon, 18 Jan 2016 12:31:35 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1aL8iS-00078j-M3 for freebsd-fs@freebsd.org; Mon, 18 Jan 2016 13:15:29 +0100 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-fs@freebsd.org Subject: Re: [Bug 206328] Crash on shutdown with swap on NFS file (with patch) References: Date: Mon, 18 Jan 2016 13:15:22 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/1.0 (Win32) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: -- X-Spam-Score: -2.9 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED, BAYES_00 autolearn=disabled version=3.4.0 X-Scan-Signature: 51a43cd7ff6838d9e9bce89dbcde6c26 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 12:31:36 -0000 On Mon, 18 Jan 2016 10:48:10 +0100, wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206328 > > --- Comment #3 from Tom Vijlbrief --- > bufshutdown() ends with: > > > if (panicstr == NULL) > vfs_unmountall(); > } > swapoff_all(); > > Why not just reverse the order? > > So swapoff_all() before the vfs_unmountall(), so that the NFS filesystem > is > still available. > > Perhaps even at the start of bufshutdown(). > > Still wondering what the reason of a swapoff_all() call just before the > actual > reboot is. > Maybe... leaving swap on a mirrored disk will give a rebuild of the mirror on boot if swap is not swapped off. From owner-freebsd-fs@freebsd.org Mon Jan 18 15:07:38 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A50B1A86DE5 for ; Mon, 18 Jan 2016 15:07:38 +0000 (UTC) (envelope-from karli.sjoberg@slu.se) Received: from EXCH2-1.slu.se (pop.slu.se [77.235.224.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "webmail.slu.se", Issuer "TERENA SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 40D3019CF for ; Mon, 18 Jan 2016 15:07:37 +0000 (UTC) (envelope-from karli.sjoberg@slu.se) Received: from exch2-4.slu.se (77.235.224.124) by EXCH2-1.slu.se (77.235.224.121) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 18 Jan 2016 15:52:20 +0100 Received: from exch2-4.slu.se ([::1]) by exch2-4.slu.se ([fe80::a44b:9cc6:beb0:b0f2%22]) with mapi id 15.00.1104.000; Mon, 18 Jan 2016 15:52:20 +0100 From: =?utf-8?B?S2FybGkgU2rDtmJlcmc=?= To: "freebsd-fs@freebsd.org" Subject: Troubleshoot high interrupt on CPU Thread-Topic: Troubleshoot high interrupt on CPU Thread-Index: AQHRUf/UzbD2J0XOiU2eFcqp+sAccQ== Date: Mon, 18 Jan 2016 14:52:19 +0000 Message-ID: <1453128791.3882.23.camel@slu.se> Reply-To: =?utf-8?B?S2FybGkgU2rDtmJlcmc=?= Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [77.235.228.63] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 15:07:38 -0000 SGV5IGFsbCENCg0KV2XCtHJlIGV4cGVyaWVuY2luZyBpbnRlcm1pdHRlbnQgImVwaXNvZGVzIiBv biBlc3BlY2lhbGx5IG9uZSBvZiBvdXINCnN0b3JhZ2Ugc2VydmVycywgdGhhdCBDUFUgdXNhZ2Ug Z29lcyBvdmVyIDQ1MCU6DQoNCjQ1Ni42OSUgW2ludHJdDQpSVU4gOTAuOTclIFtpbnRye2lycTI2 NTogaXgwOnF1ZSB9XQ0KQ1BVMiA4OC45NiUgW2ludHJ7aXJxMjY2OiBpeDA6cXVlIH1dDQpXQUlU IDU1Ljk2JSBbaW50cntpcnEyNjg6IGl4MDpxdWUgfV0NClJVTiA1Mi45OCUgW2ludHJ7aXJxMjY3 OiBpeDA6cXVlIH1dDQpXQUlUIDQxLjk5JSBbaW50cntpcnEyNzk6IGl4MTpxdWUgfV0NCkNQVTUg MzcuOTklIFtpbnRye2lycTI3ODogaXgxOnF1ZSB9XQ0KV0FJVCAzNi45NiUgW2ludHJ7aXJxMjc3 OiBpeDE6cXVlIH1dDQpDUFUzIDI1Ljk4JSBbaW50cntpcnEyNzY6IGl4MTpxdWUgfV0NCg0KU28g ZnJvbSB0aGlzIEnCtG0gdGhpbmtpbmcgaXTCtHMgc29tZXRoaW5nIHRvIGRvIHdpdGggdGhlIG5l dHdvcmssIHNpbmNlDQppdMK0cyBpeCBpbnRlcmZhY2VzLiBEdXJpbmcgdGhlc2UgZXBpc29kZXMg bmV0d29yayB0cmFmZmljIGdvZXMgZG93biB0bw0KbmlsIGFuZCBjbGllbnRzIGxvb3NlIGNvbnRh Y3QsIGlTQ1NJLWRpc2tzIHJlY29ubmVjdHMsIGRpcmVjdG9yaWVzIGNhbsK0dA0Kb3BlbiwgbXVz aWMgc3RvcHMgcGxheWluZywgZXRjLiBIb3cgY2FuIEkgZGVidWcgdGhpcyBmdXJ0aGVyPyBJcyB0 aGVyZQ0KbW9yZSBpbmZvcm1hdGlvbiBJIGNhbiBzdXBwbHkgdGhhdCB3b3VsZCBoZWxwIHlvdSBi ZXR0ZXIgdW5kZXJzdGFuZCB0aGUNCnNpdHVhdGlvbj8NCg0KL0sNCg== From owner-freebsd-fs@freebsd.org Mon Jan 18 15:40:32 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9135AA8798B for ; Mon, 18 Jan 2016 15:40:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8115E1F47 for ; Mon, 18 Jan 2016 15:40:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0IFeW6c011100 for ; Mon, 18 Jan 2016 15:40:32 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 205816] [ext2fs] [patch] EXT4 sparse blocks unsupported, contain garbage when read Date: Mon, 18 Jan 2016 15:40:32 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: feature, patch X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: pfg@FreeBSD.org X-Bugzilla-Flags: mfc-stable9? mfc-stable10? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 15:40:32 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D205816 --- Comment #16 from commit-hook@freebsd.org --- A commit references this bug: Author: pfg Date: Mon Jan 18 15:39:33 UTC 2016 New revision: 294271 URL: https://svnweb.freebsd.org/changeset/base/294271 Log: MFC r293680 ext4: add support for reading sparse files Add support for sparse files in ext4. Also implement read-ahead, which greatly increases the performance when transferring files from ext4. The sparse file support has become very common in ext4. Both features implemented by Damjan Jovanovic. PR: 205816 Changes: _U stable/10/ stable/10/sys/fs/ext2fs/ext2_bmap.c stable/10/sys/fs/ext2fs/ext2_extents.c stable/10/sys/fs/ext2fs/ext2_extents.h stable/10/sys/fs/ext2fs/ext2_vnops.c --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-fs@freebsd.org Mon Jan 18 15:44:35 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AA499A87C65 for ; Mon, 18 Jan 2016 15:44:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9A68F19F2 for ; Mon, 18 Jan 2016 15:44:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0IFiZIt022307 for ; Mon, 18 Jan 2016 15:44:35 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 205816] [ext2fs] [patch] EXT4 sparse blocks unsupported, contain garbage when read Date: Mon, 18 Jan 2016 15:44:35 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: feature, patch X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: pfg@FreeBSD.org X-Bugzilla-Flags: mfc-stable9? mfc-stable10? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 15:44:35 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D205816 --- Comment #17 from commit-hook@freebsd.org --- A commit references this bug: Author: pfg Date: Mon Jan 18 15:43:37 UTC 2016 New revision: 294273 URL: https://svnweb.freebsd.org/changeset/base/294273 Log: MFC r293680 ext4: add support for reading sparse files Add support for sparse files in ext4. Also implement read-ahead, which greatly increases the performance when transferring files from ext4. The sparse file support has become very common in ext4. Both features implemented by Damjan Jovanovic. PR: 205816 Changes: _U stable/9/sys/ _U stable/9/sys/fs/ stable/9/sys/fs/ext2fs/ext2_bmap.c stable/9/sys/fs/ext2fs/ext2_extents.c stable/9/sys/fs/ext2fs/ext2_extents.h stable/9/sys/fs/ext2fs/ext2_vnops.c --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-fs@freebsd.org Mon Jan 18 15:44:53 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 33AD5A87C9C for ; Mon, 18 Jan 2016 15:44:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2412A1A6D for ; Mon, 18 Jan 2016 15:44:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0IFiq49022693 for ; Mon, 18 Jan 2016 15:44:53 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 205816] [ext2fs] [patch] EXT4 sparse blocks unsupported, contain garbage when read Date: Mon, 18 Jan 2016 15:44:52 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: feature, patch X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: pfg@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: pfg@FreeBSD.org X-Bugzilla-Flags: mfc-stable9+ mfc-stable10+ X-Bugzilla-Changed-Fields: flagtypes.name Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 15:44:53 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D205816 Pedro F. Giffuni changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|mfc-stable9?, mfc-stable10? |mfc-stable9+, mfc-stable10+ --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-fs@freebsd.org Mon Jan 18 15:48:31 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 07959A87DFD for ; Mon, 18 Jan 2016 15:48:31 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 926451D22 for ; Mon, 18 Jan 2016 15:48:30 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wm0-x22c.google.com with SMTP id b14so129399344wmb.1 for ; Mon, 18 Jan 2016 07:48:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-type:content-transfer-encoding; bh=bPrqhsRXMaFQsktj8YZIHZuLhYEjneIL41oprQEzF+A=; b=vaplN2sx3VECJjOMDLCzaVqF0Mt+MAC7RnsoVCYYZ3OuqKX/NRG/1lvqU5lO81+8L6 Q2EAPFhM8q4UpxeF2tqYbJBA8hcqlBx/mDUa6+/qsKbw9oH1jqBmbtjf6sdFOKw6JKOK h79jtTLh4HuBRejZmjiqGOgq4K+1SQB8YhYBMZ+g+oztgaZb2Zy7LXK3ov5aVeS7hYVc sn1lhI+JNm0Y3WXDqmFgORJHZO+ODheLHcrkeBAf3+mZtmkJW4ZSsy6LnC3gO5+Vb4u/ N0+o4rAP2TRLqv8fGvtNk+21oe0H3NwD7zJT1ZDiiMEci2+XcNWjVUzcOY1qxDo5//Fe 9bmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-type :content-transfer-encoding; bh=bPrqhsRXMaFQsktj8YZIHZuLhYEjneIL41oprQEzF+A=; b=ZMLZL/Uawe5TczHNSyFE9EkWtpOPYnN/ddhAzEcmlLiTPn6zMp7izEjz2daziIpwSK IdioxBOQn3Ux74DbW92gwp6ivdP6mxVSweHCBik7cSz4Ek5NOXnuDmjorF67I7I1dBGu 2vW3g06c2obT5iK3EghU4W1R+EsOj7AWt4iwpHyo/sIsNvpxDujl1eHlLk4PTRvdm7T3 eLe/rLhZcBnN1cTimj4oOnR37civly5WzhQkRrPzcIstalHHM+qzZ0yeOKG5FdGBpbvI nz5ACof7PwmtclrRCCDhJ2Hdsm5SFWlDh98LeVZkNsVhAsJgAAnAnY4u7+8md3QIJ4h7 pj3w== X-Gm-Message-State: ALoCoQkHIsdFhI1hhxFMkazTn8xOaU7g9ewYaZYnHUmSiPVChIlsrOMawKVohRSJJbr0iHQOBDuA5HQHPHekLMZ8Vl5S9EYbZw== X-Received: by 10.194.111.232 with SMTP id il8mr29245785wjb.150.1453132109132; Mon, 18 Jan 2016 07:48:29 -0800 (PST) Received: from ernst.home (p4FCA6205.dip0.t-ipconnect.de. [79.202.98.5]) by smtp.gmail.com with ESMTPSA id 79sm16373221wmo.7.2016.01.18.07.48.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Jan 2016 07:48:28 -0800 (PST) Date: Mon, 18 Jan 2016 16:48:28 +0100 From: Gary Jennejohn To: "Ronald Klop" Cc: freebsd-fs@freebsd.org Subject: Re: [Bug 206328] Crash on shutdown with swap on NFS file (with patch) Message-ID: <20160118164828.2aedaac8@ernst.home> In-Reply-To: References: Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 15:48:31 -0000 On Mon, 18 Jan 2016 13:15:22 +0100 "Ronald Klop" wrote: > On Mon, 18 Jan 2016 10:48:10 +0100, wrote: > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206328 > > > > --- Comment #3 from Tom Vijlbrief --- > > bufshutdown() ends with: > > > > > > if (panicstr == NULL) > > vfs_unmountall(); > > } > > swapoff_all(); > > > > Why not just reverse the order? > > > > So swapoff_all() before the vfs_unmountall(), so that the NFS filesystem > > is > > still available. > > > > Perhaps even at the start of bufshutdown(). > > > > Still wondering what the reason of a swapoff_all() call just before the > > actual > > reboot is. > > > > Maybe... leaving swap on a mirrored disk will give a rebuild of the mirror > on boot if swap is not swapped off. > Right, eventually swapgeom_close() gets called to clean things up. Still, it seems rather strange that all the swapped out pages are paged back in when the utlimate goal is to close the swap devices cleanly. Of course, there is some logic in the code to handle the case where some process(es) may be actively swapping while the kernel is shutting things down. -- Gary Jennejohn From owner-freebsd-fs@freebsd.org Mon Jan 18 17:39:47 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7B645A86739 for ; Mon, 18 Jan 2016 17:39:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6C5701742 for ; Mon, 18 Jan 2016 17:39:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0IHdl9U007725 for ; Mon, 18 Jan 2016 17:39:47 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 206328] Crash on shutdown with swap on NFS file (with patch) Date: Mon, 18 Jan 2016 17:39:47 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: tvijlbrief@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 17:39:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206328 --- Comment #4 from Tom Vijlbrief --- Created attachment 165768 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D165768&action= =3Dedit Proposed patch Do swapoff_all() BEFORE unmounting the filesystems, so that an NFS swap fil= e is not orphaned. This prevents a panic on reboot/halt or when shutdown cannot do a successfu= ll swapoff due to insufficient working memory. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Mon Jan 18 22:37:19 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 50CC6A869AF for ; Mon, 18 Jan 2016 22:37:19 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 0630610DF for ; Mon, 18 Jan 2016 22:37:18 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) IronPort-PHdr: 9a23:GUun0hzNm2vmNULXCy+O+j09IxM/srCxBDY+r6Qd0eITIJqq85mqBkHD//Il1AaPBtWFraMawLOK6+jJYi8p39WoiDg6aptCVhsI2409vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6kO74TNaIBjjLw09fr2zQd6MyZXpnLnuo9X6WEZhunmUWftKNhK4rAHc5IE9oLBJDeIP8CbPuWZCYO9MxGlldhq5lhf44dqsrtY4q3wD89pozcNLUL37cqIkVvQYSW1+ayFmrPHs4CPKQguG+HYaXn8f2jVPHATM9AnzFsPrvSzluuNlwAGAMMH2RKxyUjOnufRFUhjt3R0GPD1x1Wjcich9ieoPuheorB97zov8fYaaKfd6ZqObdtpMFjkJZdpYSyEUWtD0VIAIFedUeL8A94Q= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DQAQDyZ51W/61jaINEGoQMbQaIULNFAQ2BYhgKhSNKAoFyFAEBAQEBAQEBgQmCLYIHAQEBBAEBASAEJyALDAQCAQgOAwQBAQECAg0ZAgInAQkeCAIECAcEAQgLCQSHeg4srm2QEQEBAQEBAQEBAQEBAQEBAQEBAQEBARiBAIEuhCeEf4Q3AQGDO4FJBY45iGGFSIUrhEpKhyWFNIpsg28CIAEBQoIRG4F7IDQBBoVzOoEIAQEB X-IronPort-AV: E=Sophos;i="5.22,314,1449550800"; d="scan'208";a="261871298" Received: from nipigon.cs.uoguelph.ca (HELO zcs1.mail.uoguelph.ca) ([131.104.99.173]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 18 Jan 2016 17:37:11 -0500 Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 702F515F574; Mon, 18 Jan 2016 17:37:11 -0500 (EST) Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id w-L6rVbA2FkF; Mon, 18 Jan 2016 17:37:10 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 3527F15F56E; Mon, 18 Jan 2016 17:37:10 -0500 (EST) X-Virus-Scanned: amavisd-new at zcs1.mail.uoguelph.ca Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id unQK1pqGciZN; Mon, 18 Jan 2016 17:37:10 -0500 (EST) Received: from zcs1.mail.uoguelph.ca (zcs1.mail.uoguelph.ca [172.17.95.18]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id C252D15F56D; Mon, 18 Jan 2016 17:37:09 -0500 (EST) Date: Mon, 18 Jan 2016 17:37:09 -0500 (EST) From: Rick Macklem To: Raghavendra Gowdappa Cc: Jeff Darcy , Raghavendra G , freebsd-fs , Hubbard Jordan , Xavier Hernandez , Gluster Devel Message-ID: <1045057902.165261325.1453156629344.JavaMail.zimbra@uoguelph.ca> In-Reply-To: <1256214214.7158114.1452310490692.JavaMail.zimbra@redhat.com> References: <571237035.145690509.1451437960464.JavaMail.zimbra@uoguelph.ca> <1083933309.146084334.1451517977647.JavaMail.zimbra@uoguelph.ca> <568F6D07.6070500@datalab.es> <1924941590.6473225.1452248249994.JavaMail.zimbra@redhat.com> <981529129.154244852.1452304799182.JavaMail.zimbra@uoguelph.ca> <1256214214.7158114.1452310490692.JavaMail.zimbra@redhat.com> Subject: Re: [Gluster-devel] FreeBSD port of GlusterFS racks up a lot of CPU usage MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.10] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF43 (Win)/8.0.9_GA_6191) Thread-Topic: FreeBSD port of GlusterFS racks up a lot of CPU usage Thread-Index: nzgvBLPPgcBXuRsf6GlZU17foVfxCE+M3nAjcp2ixGppRbv/tw== X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 22:37:19 -0000 Raghavendra Gowdappa wrote: > > > ----- Original Message ----- > > From: "Rick Macklem" > > To: "Jeff Darcy" > > Cc: "Raghavendra G" , "freebsd-fs" > > , "Hubbard Jordan" > > , "Xavier Hernandez" , "Gluster > > Devel" > > Sent: Saturday, January 9, 2016 7:29:59 AM > > Subject: Re: [Gluster-devel] FreeBSD port of GlusterFS racks up a lot of > > CPU usage > > > > Jeff Darcy wrote: > > > > > I don't know anything about gluster's poll implementation so I may > > > > > be totally wrong, but would it be possible to use an eventfd (or a > > > > > pipe if eventfd is not supported) to signal the need to add more > > > > > file descriptors to the poll call ? > > > > > > > > > > > > > > > The poll call should listen on this new fd. When we need to change > > > > > the fd list, we should simply write to the eventfd or pipe from > > > > > another thread. This will cause the poll call to return and we will > > > > > be able to change the fd list without having a short timeout nor > > > > > having to decide on any trade-off. > > > > > > > > > > > > Thats a nice idea. Based on my understanding of why timeouts are being > > > > used, this approach can work. > > > > > > The own-thread code which preceded the current poll implementation did > > > something similar, using a pipe fd to be woken up for new *outgoing* > > > messages. That code still exists, and might provide some insight into > > > how to do this for the current poll code. > > I took a look at event-poll.c and found something interesting... > > - A pipe called "breaker" is already set up by event_pool_new_poll() and > > closed by event_pool_destroy_poll(), however it never gets used for > > anything. > > I did a check on history, but couldn't find any information on why it was > removed. Can you send this patch to http://review.gluster.org ? We can > review and merge the patch over there. If you are not aware, development > work flow can be found at: > > http://www.gluster.org/community/documentation/index.php/Developers > Actually, the patch turned out to be a flop. Sometimes a fuse mount would end up with an empty file system with the patch. (I don't know why it was broken, but maybe the original author tan into issues as well?) Anyhow, I am now using the 3.7.6 event-poll.c code except that I have increased the timeout from 1msec->10msec. (Going from 1->5->10 didn't seem to cause a problem, but I got slower test runs when I increased to 20msec, so I've settled on 10mses. This does reduce the CPU usage when the GlusterFS file systems aren't active.) I will submit this one line change to your workflow if it continues to test ok. Thanks for everyone's input, rick > > > > So, I added a few lines of code that writes a byte to it whenever the list > > of > > file descriptors is changed and read when poll() returns, if its revents is > > set. > > I also changed the timeout to -1 (infinity) and it seems to work for a > > trivial > > test. > > --> Btw, I also noticed the "changed" variable gets set to 1 on a change, > > but > > never reset to 0. I didn't change this, since it looks "racey". (ie. I > > think you could easily get a race between a thread that clears it and > > one > > that adds a new fd.) > > > > A slightly safer version of the patch would set a long (100msec ??) timeout > > instead > > of -1. > > > > Anyhow, I've attached the patch in case anyone would like to try it and > > will > > create a bug report for this after I've had more time to test it. > > (I only use a couple of laptops, so my testing will be minimal.) > > > > Thanks for all the help, rick > > > > > _______________________________________________ > > > freebsd-fs@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > > > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > > > > > > From owner-freebsd-fs@freebsd.org Tue Jan 19 04:25:24 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E42F1A867CB for ; Tue, 19 Jan 2016 04:25:23 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id A3797106D for ; Tue, 19 Jan 2016 04:25:23 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) IronPort-PHdr: 9a23:gwu8pxe7KGIUFn1oeL6X+M1JlGMj4u6mDksu8pMizoh2WeGdxc6yZh7h7PlgxGXEQZ/co6odzbGG7eaxBidfut6oizMrTt9lb1c9k8IYnggtUoauKHbQC7rUVRE8B9lIT1R//nu2YgB/Ecf6YEDO8DXptWZBUiv2OQc9HOnpAIma153xjLDsvcyMKFoTzBOGIppMbzyO5T3LsccXhYYwYo0Q8TDu5kVyRuJN2GlzLkiSlRuvru25/Zpk7jgC86l5r50IeezAcq85Vb1VCig9eyBwvZWz9EqLcQzaxXwaSXkflAZJBUDv4RX9Q4z2rGOute1mxCiZN8DyZb8xUDWmqaxsTUm7pj0AMmsD8WrUwul5h6FfrRfp8wZ6yoXXZIyQHOd5cb7QecsaA2FICJUCHxddC5+xOtNcR9EKOvxV+syk/wMD X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DOAQC4uZ1W/61jaINehH+IULNEAQ2BYoYPAoFyFAEBAQEBAQEBgQmCLYIHAQEBAwEjBFIFCwIBCA4KAgINGQICVwIEiCYIryOPfAEBAQEBAQEBAgEBAQEBAQEBG4EAhVWEf4d0gUkFjjmIYY89hESIX0SOFwIgAQFChCcghhqBCAEBAQ X-IronPort-AV: E=Sophos;i="5.22,315,1449550800"; d="scan'208";a="263496061" Received: from nipigon.cs.uoguelph.ca (HELO zcs1.mail.uoguelph.ca) ([131.104.99.173]) by esa-annu.net.uoguelph.ca with ESMTP; 18 Jan 2016 23:25:16 -0500 Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id AC0DF15F55D; Mon, 18 Jan 2016 23:25:16 -0500 (EST) Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 18zTPjdfjpkP; Mon, 18 Jan 2016 23:25:16 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 5BCF215F565; Mon, 18 Jan 2016 23:25:16 -0500 (EST) X-Virus-Scanned: amavisd-new at zcs1.mail.uoguelph.ca Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id cf6osFCIknyV; Mon, 18 Jan 2016 23:25:16 -0500 (EST) Received: from zcs1.mail.uoguelph.ca (zcs1.mail.uoguelph.ca [172.17.95.18]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 43B0B15F55D; Mon, 18 Jan 2016 23:25:16 -0500 (EST) Date: Mon, 18 Jan 2016 23:25:16 -0500 (EST) From: Rick Macklem To: Konstantin Belousov Cc: FreeBSD Filesystems , Kirk McKusick Message-ID: <855760730.165482737.1453177516248.JavaMail.zimbra@uoguelph.ca> In-Reply-To: <20160117035858.GO3942@kib.kiev.ua> References: <1696608910.154845456.1452438117036.JavaMail.zimbra@uoguelph.ca> <20160114092934.GL72455@kib.kiev.ua> <964333498.161527381.1452827658163.JavaMail.zimbra@uoguelph.ca> <20160115095749.GC3942@kib.kiev.ua> <1817287612.162823118.1452909605928.JavaMail.zimbra@uoguelph.ca> <20160116191116.GI3942@kib.kiev.ua> <853868666.163292727.1452986431921.JavaMail.zimbra@uoguelph.ca> <20160117035858.GO3942@kib.kiev.ua> Subject: Re: panic ffs_truncate3 (maybe fuse being evil) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.10] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF43 (Win)/8.0.9_GA_6191) Thread-Topic: panic ffs_truncate3 (maybe fuse being evil) Thread-Index: J9p5e5CYpA4BYA2S5z+Ll5xyazdl9A== X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 04:25:24 -0000 Kostik wrote: > On Sat, Jan 16, 2016 at 06:20:31PM -0500, Rick Macklem wrote: > > Kostik wrote: > > > Was IO_EXT flag passed to the ffs_truncate() invocation where the > > > assert ffs_truncate3 fired ? > > > > > Yes. The only call to UFS_TRUNCATE() in ufs_inactive() specified both > > IO_EXT | IO_NORMAL. > > Please try this. > Still happens. I put the old panic test in, but with a printf() instead of panic() and the printf() happens with this patch. Btw, whenever I've looked, the entry is on the clean list. No other panics happen and the file system fsck's fine after the test run. rick > diff --git a/sys/ufs/ffs/ffs_vnops.c b/sys/ufs/ffs/ffs_vnops.c > index 381f6f8..ecc3f9b 100644 > --- a/sys/ufs/ffs/ffs_vnops.c > +++ b/sys/ufs/ffs/ffs_vnops.c > @@ -1313,7 +1313,8 @@ ffs_close_ea(struct vnode *vp, int commit, struct ucred > *cred, struct thread *td > /* XXX: I'm not happy about truncating to zero size */ > if (ip->i_ea_len < dp->di_extsize) > error = ffs_truncate(vp, 0, IO_EXT, cred); > - error = ffs_extwrite(vp, &luio, IO_EXT | IO_SYNC, cred); > + error = ffs_extwrite(vp, &luio, IO_EXT | IO_SYNC | IO_UNIT, > + cred); > } > if (--ip->i_ea_refs == 0) { > free(ip->i_ea_area, M_TEMP); > From owner-freebsd-fs@freebsd.org Tue Jan 19 06:01:24 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B1C60A885A5 for ; Tue, 19 Jan 2016 06:01:24 +0000 (UTC) (envelope-from rgowdapp@redhat.com) Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx1.redhat.com", Issuer "DigiCert SHA2 Extended Validation Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 98E0D15D6 for ; Tue, 19 Jan 2016 06:01:24 +0000 (UTC) (envelope-from rgowdapp@redhat.com) Received: from zmail13.collab.prod.int.phx2.redhat.com (zmail13.collab.prod.int.phx2.redhat.com [10.5.83.15]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id u0J61KY6002251; Tue, 19 Jan 2016 01:01:20 -0500 Date: Tue, 19 Jan 2016 01:01:19 -0500 (EST) From: Raghavendra Gowdappa To: Rick Macklem Cc: Jeff Darcy , Raghavendra G , freebsd-fs , Hubbard Jordan , Xavier Hernandez , Gluster Devel Message-ID: <7769801.11211464.1453183279015.JavaMail.zimbra@redhat.com> In-Reply-To: <1045057902.165261325.1453156629344.JavaMail.zimbra@uoguelph.ca> References: <571237035.145690509.1451437960464.JavaMail.zimbra@uoguelph.ca> <568F6D07.6070500@datalab.es> <1924941590.6473225.1452248249994.JavaMail.zimbra@redhat.com> <981529129.154244852.1452304799182.JavaMail.zimbra@uoguelph.ca> <1256214214.7158114.1452310490692.JavaMail.zimbra@redhat.com> <1045057902.165261325.1453156629344.JavaMail.zimbra@uoguelph.ca> Subject: Re: [Gluster-devel] FreeBSD port of GlusterFS racks up a lot of CPU usage MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.70.1.92] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - GC25 (Linux)/8.0.6_GA_5922) Thread-Topic: FreeBSD port of GlusterFS racks up a lot of CPU usage Thread-Index: nzgvBLPPgcBXuRsf6GlZU17foVfxCE+M3nAjcp2ixGppRbv/t1U+cI5T X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 06:01:24 -0000 ----- Original Message ----- > From: "Rick Macklem" > To: "Raghavendra Gowdappa" > Cc: "Jeff Darcy" , "Raghavendra G" , "freebsd-fs" > , "Hubbard Jordan" , "Xavier Hernandez" , "Gluster > Devel" > Sent: Tuesday, January 19, 2016 4:07:09 AM > Subject: Re: [Gluster-devel] FreeBSD port of GlusterFS racks up a lot of CPU usage > > Raghavendra Gowdappa wrote: > > > > > > ----- Original Message ----- > > > From: "Rick Macklem" > > > To: "Jeff Darcy" > > > Cc: "Raghavendra G" , "freebsd-fs" > > > , "Hubbard Jordan" > > > , "Xavier Hernandez" , "Gluster > > > Devel" > > > Sent: Saturday, January 9, 2016 7:29:59 AM > > > Subject: Re: [Gluster-devel] FreeBSD port of GlusterFS racks up a lot of > > > CPU usage > > > > > > Jeff Darcy wrote: > > > > > > I don't know anything about gluster's poll implementation so I may > > > > > > be totally wrong, but would it be possible to use an eventfd (or a > > > > > > pipe if eventfd is not supported) to signal the need to add more > > > > > > file descriptors to the poll call ? > > > > > > > > > > > > > > > > > > The poll call should listen on this new fd. When we need to change > > > > > > the fd list, we should simply write to the eventfd or pipe from > > > > > > another thread. This will cause the poll call to return and we > > > > > > will > > > > > > be able to change the fd list without having a short timeout nor > > > > > > having to decide on any trade-off. > > > > > > > > > > > > > > > Thats a nice idea. Based on my understanding of why timeouts are > > > > > being > > > > > used, this approach can work. > > > > > > > > The own-thread code which preceded the current poll implementation did > > > > something similar, using a pipe fd to be woken up for new *outgoing* > > > > messages. That code still exists, and might provide some insight into > > > > how to do this for the current poll code. > > > I took a look at event-poll.c and found something interesting... > > > - A pipe called "breaker" is already set up by event_pool_new_poll() and > > > closed by event_pool_destroy_poll(), however it never gets used for > > > anything. > > > > I did a check on history, but couldn't find any information on why it was > > removed. Can you send this patch to http://review.gluster.org ? We can > > review and merge the patch over there. If you are not aware, development > > work flow can be found at: > > > > http://www.gluster.org/community/documentation/index.php/Developers > > > Actually, the patch turned out to be a flop. Sometimes a fuse mount would end > up with an empty file system with the patch. (I don't know why it was broken, > but maybe the original author tan into issues as well?) +static void +event_pool_changed (struct event_pool *event_pool) +{ + + /* Write a byte into the breaker pipe to wake up poll(). */ + if (event_pool->breaker[1] >= 0) + write(event_pool->breaker[1], "X", 1); +} breaker is set to non-blocking on both read and write ends. So, probably write might be failing sometimes with EAGAIN/EBUSY and thereby preventing the socket from being registered. Probably that might be the reason? if (event_pool->breaker[1] >= 0) { do { ret = write(event_pool->breaker[1], "X", 1); } while (ret != 1); } Also similar logic might be required while flushing out junk from read end too. > > Anyhow, I am now using the 3.7.6 event-poll.c code except that I have > increased > the timeout from 1msec->10msec. (Going from 1->5->10 didn't seem to cause a > problem, but I got slower test runs when I increased to 20msec, so I've > settled on > 10mses. This does reduce the CPU usage when the GlusterFS file systems aren't > active.) > I will submit this one line change to your workflow if it continues to test > ok. > > Thanks for everyone's input, rick > > > > > > > So, I added a few lines of code that writes a byte to it whenever the > > > list > > > of > > > file descriptors is changed and read when poll() returns, if its revents > > > is > > > set. > > > I also changed the timeout to -1 (infinity) and it seems to work for a > > > trivial > > > test. > > > --> Btw, I also noticed the "changed" variable gets set to 1 on a change, > > > but > > > never reset to 0. I didn't change this, since it looks "racey". (ie. > > > I > > > think you could easily get a race between a thread that clears it and > > > one > > > that adds a new fd.) > > > > > > A slightly safer version of the patch would set a long (100msec ??) > > > timeout > > > instead > > > of -1. > > > > > > Anyhow, I've attached the patch in case anyone would like to try it and > > > will > > > create a bug report for this after I've had more time to test it. > > > (I only use a couple of laptops, so my testing will be minimal.) > > > > > > Thanks for all the help, rick > > > > > > > _______________________________________________ > > > > freebsd-fs@freebsd.org mailing list > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > > > > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > > > > > > > > > > From owner-freebsd-fs@freebsd.org Tue Jan 19 07:49:54 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2AA3CA886DA for ; Tue, 19 Jan 2016 07:49:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1B30A14DE for ; Tue, 19 Jan 2016 07:49:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0J7nrjr083082 for ; Tue, 19 Jan 2016 07:49:53 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 206238] FUSE can't enter to DIRECT_IO mode during file create. Date: Tue, 19 Jan 2016 07:49:53 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: freebsd@moosefs.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 07:49:54 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206238 --- Comment #4 from MooseFS --- Thank you for your patches. We applied them and all seems to work fine now. We have a question. When it will be added to official kernel? Best regards MooseFS Support Team --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Tue Jan 19 09:27:24 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 48506A88534 for ; Tue, 19 Jan 2016 09:27:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3779C17EA for ; Tue, 19 Jan 2016 09:27:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0J9RNV1088397 for ; Tue, 19 Jan 2016 09:27:24 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 205816] [ext2fs] [patch] EXT4 sparse blocks unsupported, contain garbage when read Date: Tue, 19 Jan 2016 09:27:24 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: feature, patch X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: ardovm@yahoo.it X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: pfg@FreeBSD.org X-Bugzilla-Flags: mfc-stable9+ mfc-stable10+ X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 09:27:24 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D205816 Arrigo Marchiori changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ardovm@yahoo.it --- Comment #18 from Arrigo Marchiori --- (In reply to commit-hook from comment #17) Hello, this commit seems to break builds on 9-STABLE, because of the unnamed union= in stable/9/sys/fs/ext2fs/ext2_extents.h Excerpt from the build log: [...] In file included from @/fs/ext2fs/inode.h:46, from /usr/src/sys/modules/ext2fs/../../fs/ext2fs/ext2_extents.c:41: @/fs/ext2fs/ext2_extents.h:91: warning: declaration does not declare anythi= ng HTH. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-fs@freebsd.org Tue Jan 19 10:35:33 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5B356A88EC0 for ; Tue, 19 Jan 2016 10:35:33 +0000 (UTC) (envelope-from martin@lispworks.com) Received: from lwfs1-cam.cam.lispworks.com (mail.lispworks.com [46.17.166.21]) by mx1.freebsd.org (Postfix) with ESMTP id E84241935 for ; Tue, 19 Jan 2016 10:35:32 +0000 (UTC) (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com (higson.cam.lispworks.com [192.168.1.7]) by lwfs1-cam.cam.lispworks.com (8.14.9/8.14.9) with ESMTP id u0JAOgR5033630; Tue, 19 Jan 2016 10:24:42 GMT (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com (localhost.localdomain [127.0.0.1]) by higson.cam.lispworks.com (8.14.4) id u0JA57ip004666; Tue, 19 Jan 2016 10:05:07 GMT Received: (from martin@localhost) by higson.cam.lispworks.com (8.14.4/8.14.4/Submit) id u0JA57Nl004520; Tue, 19 Jan 2016 10:05:07 GMT Date: Tue, 19 Jan 2016 10:05:07 GMT Message-Id: <201601191005.u0JA57Nl004520@higson.cam.lispworks.com> From: Martin Simmons To: Raghavendra Gowdappa CC: rmacklem@uoguelph.ca, jdarcy@redhat.com, raghavendra@gluster.com, gluster-devel@gluster.org, freebsd-fs@freebsd.org, xhernandez@datalab.es, jkh@ixsystems.com In-reply-to: <7769801.11211464.1453183279015.JavaMail.zimbra@redhat.com> (message from Raghavendra Gowdappa on Tue, 19 Jan 2016 01:01:19 -0500 (EST)) Subject: Re: [Gluster-devel] FreeBSD port of GlusterFS racks up a lot of CPU usage References: <571237035.145690509.1451437960464.JavaMail.zimbra@uoguelph.ca> <568F6D07.6070500@datalab.es> <1924941590.6473225.1452248249994.JavaMail.zimbra@redhat.com> <981529129.154244852.1452304799182.JavaMail.zimbra@uoguelph.ca> <1256214214.7158114.1452310490692.JavaMail.zimbra@redhat.com> <1045057902.165261325.1453156629344.JavaMail.zimbra@uoguelph.ca> <7769801.11211464.1453183279015.JavaMail.zimbra@redhat.com> X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 10:35:33 -0000 >>>>> On Tue, 19 Jan 2016 01:01:19 -0500 (EST), Raghavendra Gowdappa said: > > ----- Original Message ----- > > From: "Rick Macklem" > > To: "Raghavendra Gowdappa" > > Cc: "Jeff Darcy" , "Raghavendra G" , "freebsd-fs" > > , "Hubbard Jordan" , "Xavier Hernandez" , "Gluster > > Devel" > > Sent: Tuesday, January 19, 2016 4:07:09 AM > > Subject: Re: [Gluster-devel] FreeBSD port of GlusterFS racks up a lot of CPU usage > > > > Raghavendra Gowdappa wrote: > > > > > > > > > ----- Original Message ----- > > > > From: "Rick Macklem" > > > > To: "Jeff Darcy" > > > > Cc: "Raghavendra G" , "freebsd-fs" > > > > , "Hubbard Jordan" > > > > , "Xavier Hernandez" , "Gluster > > > > Devel" > > > > Sent: Saturday, January 9, 2016 7:29:59 AM > > > > Subject: Re: [Gluster-devel] FreeBSD port of GlusterFS racks up a lot of > > > > CPU usage > > > > > > > > Jeff Darcy wrote: > > > > > > > I don't know anything about gluster's poll implementation so I may > > > > > > > be totally wrong, but would it be possible to use an eventfd (or a > > > > > > > pipe if eventfd is not supported) to signal the need to add more > > > > > > > file descriptors to the poll call ? > > > > > > > > > > > > > > > > > > > > > The poll call should listen on this new fd. When we need to change > > > > > > > the fd list, we should simply write to the eventfd or pipe from > > > > > > > another thread. This will cause the poll call to return and we > > > > > > > will > > > > > > > be able to change the fd list without having a short timeout nor > > > > > > > having to decide on any trade-off. > > > > > > > > > > > > > > > > > > Thats a nice idea. Based on my understanding of why timeouts are > > > > > > being > > > > > > used, this approach can work. > > > > > > > > > > The own-thread code which preceded the current poll implementation did > > > > > something similar, using a pipe fd to be woken up for new *outgoing* > > > > > messages. That code still exists, and might provide some insight into > > > > > how to do this for the current poll code. > > > > I took a look at event-poll.c and found something interesting... > > > > - A pipe called "breaker" is already set up by event_pool_new_poll() and > > > > closed by event_pool_destroy_poll(), however it never gets used for > > > > anything. > > > > > > I did a check on history, but couldn't find any information on why it was > > > removed. Can you send this patch to http://review.gluster.org ? We can > > > review and merge the patch over there. If you are not aware, development > > > work flow can be found at: > > > > > > http://www.gluster.org/community/documentation/index.php/Developers > > > > > Actually, the patch turned out to be a flop. Sometimes a fuse mount would end > > up with an empty file system with the patch. (I don't know why it was broken, > > but maybe the original author tan into issues as well?) > > +static void > +event_pool_changed (struct event_pool *event_pool) > +{ > + > + /* Write a byte into the breaker pipe to wake up poll(). */ > + if (event_pool->breaker[1] >= 0) > + write(event_pool->breaker[1], "X", 1); > +} > > breaker is set to non-blocking on both read and write ends. So, probably write might be failing sometimes with EAGAIN/EBUSY and thereby preventing the socket from being registered. Probably that might be the reason? In what situations does write return EAGAIN/EBUSY for a pipe? If it is only when the pipe's internal buffer is full, then there is still unread data and the reading end will wake up anyway, so there should be no need to write more. > if (event_pool->breaker[1] >= 0) { > do { > ret = write(event_pool->breaker[1], "X", 1); > } while (ret != 1); > } This will busy-wait, which doesn't look good. > Also similar logic might be required while flushing out junk from read end too. Failure to read everything should be benign because it will just cause poll to return again immediately next time. > > > > Anyhow, I am now using the 3.7.6 event-poll.c code except that I have > > increased > > the timeout from 1msec->10msec. (Going from 1->5->10 didn't seem to cause a > > problem, but I got slower test runs when I increased to 20msec, so I've > > settled on > > 10mses. This does reduce the CPU usage when the GlusterFS file systems aren't > > active.) > > I will submit this one line change to your workflow if it continues to test > > ok. > > > > Thanks for everyone's input, rick > > > > > > > > > > So, I added a few lines of code that writes a byte to it whenever the > > > > list > > > > of > > > > file descriptors is changed and read when poll() returns, if its revents > > > > is > > > > set. > > > > I also changed the timeout to -1 (infinity) and it seems to work for a > > > > trivial > > > > test. > > > > --> Btw, I also noticed the "changed" variable gets set to 1 on a change, > > > > but > > > > never reset to 0. I didn't change this, since it looks "racey". (ie. > > > > I > > > > think you could easily get a race between a thread that clears it and > > > > one > > > > that adds a new fd.) > > > > > > > > A slightly safer version of the patch would set a long (100msec ??) > > > > timeout > > > > instead > > > > of -1. > > > > > > > > Anyhow, I've attached the patch in case anyone would like to try it and > > > > will > > > > create a bug report for this after I've had more time to test it. > > > > (I only use a couple of laptops, so my testing will be minimal.) > > > > > > > > Thanks for all the help, rick > > > > > > > > > _______________________________________________ > > > > > freebsd-fs@freebsd.org mailing list > > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > > > > > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > > > > > > > > > > > > > > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-fs@freebsd.org Tue Jan 19 11:41:30 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2E25AA88E44 for ; Tue, 19 Jan 2016 11:41:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1EEF31DD5 for ; Tue, 19 Jan 2016 11:41:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0JBfTFV019511 for ; Tue, 19 Jan 2016 11:41:29 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 205816] [ext2fs] [patch] EXT4 sparse blocks unsupported, contain garbage when read Date: Tue, 19 Jan 2016 11:41:30 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: feature, patch X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: ardovm@yahoo.it X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: pfg@FreeBSD.org X-Bugzilla-Flags: mfc-stable9+ mfc-stable10+ X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 11:41:30 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D205816 --- Comment #19 from Arrigo Marchiori --- Created attachment 165814 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D165814&action= =3Dedit Patch for 9-STABLE to restore compilation This patch is a tentative adaptation of base r294273 to restore compilation= on 9-STABLE. An anonymous union was given a name. An additional assignment is added to a= void a compilation warning. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-fs@freebsd.org Tue Jan 19 11:53:33 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4AAE6A87333 for ; Tue, 19 Jan 2016 11:53:33 +0000 (UTC) (envelope-from rgowdapp@redhat.com) Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx1.redhat.com", Issuer "DigiCert SHA2 Extended Validation Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 30572154E for ; Tue, 19 Jan 2016 11:53:33 +0000 (UTC) (envelope-from rgowdapp@redhat.com) Received: from zmail13.collab.prod.int.phx2.redhat.com (zmail13.collab.prod.int.phx2.redhat.com [10.5.83.15]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id u0JBrUQc011680; Tue, 19 Jan 2016 06:53:30 -0500 Date: Tue, 19 Jan 2016 06:53:29 -0500 (EST) From: Raghavendra Gowdappa To: Martin Simmons Cc: rmacklem@uoguelph.ca, jdarcy@redhat.com, raghavendra@gluster.com, gluster-devel@gluster.org, freebsd-fs@freebsd.org, xhernandez@datalab.es, jkh@ixsystems.com Message-ID: <1210026335.11409907.1453204409914.JavaMail.zimbra@redhat.com> In-Reply-To: <201601191005.u0JA57Nl004520@higson.cam.lispworks.com> References: <571237035.145690509.1451437960464.JavaMail.zimbra@uoguelph.ca> <1924941590.6473225.1452248249994.JavaMail.zimbra@redhat.com> <981529129.154244852.1452304799182.JavaMail.zimbra@uoguelph.ca> <1256214214.7158114.1452310490692.JavaMail.zimbra@redhat.com> <1045057902.165261325.1453156629344.JavaMail.zimbra@uoguelph.ca> <7769801.11211464.1453183279015.JavaMail.zimbra@redhat.com> <201601191005.u0JA57Nl004520@higson.cam.lispworks.com> Subject: Re: [Gluster-devel] FreeBSD port of GlusterFS racks up a lot of CPU usage MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_11409905_1746344817.1453204409912" X-Originating-IP: [10.70.1.92] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - GC25 (Linux)/8.0.6_GA_5922) Thread-Topic: FreeBSD port of GlusterFS racks up a lot of CPU usage Thread-Index: OZOLDNW4oGfXyYSZl51nSYlZYSJouA== X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 11:53:33 -0000 ------=_Part_11409905_1746344817.1453204409912 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- Original Message ----- > From: "Martin Simmons" > To: "Raghavendra Gowdappa" > Cc: rmacklem@uoguelph.ca, jdarcy@redhat.com, raghavendra@gluster.com, gluster-devel@gluster.org, > freebsd-fs@freebsd.org, xhernandez@datalab.es, jkh@ixsystems.com > Sent: Tuesday, January 19, 2016 3:35:07 PM > Subject: Re: [Gluster-devel] FreeBSD port of GlusterFS racks up a lot of CPU usage > > >>>>> On Tue, 19 Jan 2016 01:01:19 -0500 (EST), Raghavendra Gowdappa said: > > > > ----- Original Message ----- > > > From: "Rick Macklem" > > > To: "Raghavendra Gowdappa" > > > Cc: "Jeff Darcy" , "Raghavendra G" > > > , "freebsd-fs" > > > , "Hubbard Jordan" , "Xavier > > > Hernandez" , "Gluster > > > Devel" > > > Sent: Tuesday, January 19, 2016 4:07:09 AM > > > Subject: Re: [Gluster-devel] FreeBSD port of GlusterFS racks up a lot of > > > CPU usage > > > > > > Raghavendra Gowdappa wrote: > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Rick Macklem" > > > > > To: "Jeff Darcy" > > > > > Cc: "Raghavendra G" , "freebsd-fs" > > > > > , "Hubbard Jordan" > > > > > , "Xavier Hernandez" , > > > > > "Gluster > > > > > Devel" > > > > > Sent: Saturday, January 9, 2016 7:29:59 AM > > > > > Subject: Re: [Gluster-devel] FreeBSD port of GlusterFS racks up a lot > > > > > of > > > > > CPU usage > > > > > > > > > > Jeff Darcy wrote: > > > > > > > > I don't know anything about gluster's poll implementation so I > > > > > > > > may > > > > > > > > be totally wrong, but would it be possible to use an eventfd > > > > > > > > (or a > > > > > > > > pipe if eventfd is not supported) to signal the need to add > > > > > > > > more > > > > > > > > file descriptors to the poll call ? > > > > > > > > > > > > > > > > > > > > > > > > The poll call should listen on this new fd. When we need to > > > > > > > > change > > > > > > > > the fd list, we should simply write to the eventfd or pipe from > > > > > > > > another thread. This will cause the poll call to return and we > > > > > > > > will > > > > > > > > be able to change the fd list without having a short timeout > > > > > > > > nor > > > > > > > > having to decide on any trade-off. > > > > > > > > > > > > > > > > > > > > > Thats a nice idea. Based on my understanding of why timeouts are > > > > > > > being > > > > > > > used, this approach can work. > > > > > > > > > > > > The own-thread code which preceded the current poll implementation > > > > > > did > > > > > > something similar, using a pipe fd to be woken up for new > > > > > > *outgoing* > > > > > > messages. That code still exists, and might provide some insight > > > > > > into > > > > > > how to do this for the current poll code. > > > > > I took a look at event-poll.c and found something interesting... > > > > > - A pipe called "breaker" is already set up by event_pool_new_poll() > > > > > and > > > > > closed by event_pool_destroy_poll(), however it never gets used for > > > > > anything. > > > > > > > > I did a check on history, but couldn't find any information on why it > > > > was > > > > removed. Can you send this patch to http://review.gluster.org ? We can > > > > review and merge the patch over there. If you are not aware, > > > > development > > > > work flow can be found at: > > > > > > > > http://www.gluster.org/community/documentation/index.php/Developers > > > > > > > Actually, the patch turned out to be a flop. Sometimes a fuse mount would > > > end > > > up with an empty file system with the patch. (I don't know why it was > > > broken, > > > but maybe the original author tan into issues as well?) > > > > +static void > > +event_pool_changed (struct event_pool *event_pool) > > +{ > > + > > + /* Write a byte into the breaker pipe to wake up poll(). */ > > + if (event_pool->breaker[1] >= 0) > > + write(event_pool->breaker[1], "X", 1); > > +} > > > > breaker is set to non-blocking on both read and write ends. So, probably > > write might be failing sometimes with EAGAIN/EBUSY and thereby preventing > > the socket from being registered. Probably that might be the reason? > > In what situations does write return EAGAIN/EBUSY for a pipe? If it is only > when the pipe's internal buffer is full, then there is still unread data and > the reading end will wake up anyway, so there should be no need to write > more. That's a valid point. I was kind of thinking out loud since I couldn't figure out what was wrong in earlier approach. I was particularly interested in whether write can fail because of any error. Since we were not checking the return value, a write failure can result in a socket not being registered. Though I couldn't think of any particular reason for failure, felt that its a loose end that can be tied up. On a different note, I found a bug in current poll implementation which could've resulted in high cpu usage. I've attached the diff, which wouldn't do an array copy (of registered events to ufd) every "timeout" seconds and which I hope which will bring down cpu usage. The issue was event_pool->changed was never reset and hence every timeout seconds, we would interpret that event_pool has changed even though it has not. > > > > if (event_pool->breaker[1] >= 0) { > > do { > > ret = write(event_pool->breaker[1], "X", 1); > > } while (ret != 1); > > } > > This will busy-wait, which doesn't look good. > > > > Also similar logic might be required while flushing out junk from read end > > too. > > Failure to read everything should be benign because it will just cause poll > to > return again immediately next time. > > > > > > > > Anyhow, I am now using the 3.7.6 event-poll.c code except that I have > > > increased > > > the timeout from 1msec->10msec. (Going from 1->5->10 didn't seem to cause > > > a > > > problem, but I got slower test runs when I increased to 20msec, so I've > > > settled on > > > 10mses. This does reduce the CPU usage when the GlusterFS file systems > > > aren't > > > active.) > > > I will submit this one line change to your workflow if it continues to > > > test > > > ok. > > > > > > Thanks for everyone's input, rick > > > > > > > > > > > > > So, I added a few lines of code that writes a byte to it whenever the > > > > > list > > > > > of > > > > > file descriptors is changed and read when poll() returns, if its > > > > > revents > > > > > is > > > > > set. > > > > > I also changed the timeout to -1 (infinity) and it seems to work for > > > > > a > > > > > trivial > > > > > test. > > > > > --> Btw, I also noticed the "changed" variable gets set to 1 on a > > > > > change, > > > > > but > > > > > never reset to 0. I didn't change this, since it looks "racey". > > > > > (ie. > > > > > I > > > > > think you could easily get a race between a thread that clears it > > > > > and > > > > > one > > > > > that adds a new fd.) > > > > > > > > > > A slightly safer version of the patch would set a long (100msec ??) > > > > > timeout > > > > > instead > > > > > of -1. > > > > > > > > > > Anyhow, I've attached the patch in case anyone would like to try it > > > > > and > > > > > will > > > > > create a bug report for this after I've had more time to test it. > > > > > (I only use a couple of laptops, so my testing will be minimal.) > > > > > > > > > > Thanks for all the help, rick > > > > > > > > > > > _______________________________________________ > > > > > > freebsd-fs@freebsd.org mailing list > > > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > > > > > > To unsubscribe, send any mail to > > > > > > "freebsd-fs-unsubscribe@freebsd.org" > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > freebsd-fs@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > > > ------=_Part_11409905_1746344817.1453204409912 Content-Type: text/x-patch; name=poll.diff Content-Disposition: attachment; filename=poll.diff Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL2xpYmdsdXN0ZXJmcy9zcmMvZXZlbnQtcG9sbC5jIGIvbGliZ2x1c3RlcmZz L3NyYy9ldmVudC1wb2xsLmMKaW5kZXggMDA4ZGExMC4uMzc0ZDNjZSAxMDA2NDQKLS0tIGEvbGli Z2x1c3RlcmZzL3NyYy9ldmVudC1wb2xsLmMKKysrIGIvbGliZ2x1c3RlcmZzL3NyYy9ldmVudC1w b2xsLmMKQEAgLTQzMiw2ICs0MzIsOCBAQCBldmVudF9kaXNwYXRjaF9wb2xsX3Jlc2l6ZSAoc3Ry dWN0IGV2ZW50X3Bvb2wgKmV2ZW50X3Bvb2wsCiAgICAgICAgICAgICAgICAgICAgICAgICB1ZmRz W2ldLnJldmVudHMgPSAwOwogICAgICAgICAgICAgICAgIH0KIAorICAgICAgICAgICAgICAgIGV2 ZW50X3Bvb2wtPmNoYW5nZWQgPSAwOworCiAgICAgICAgICAgICAgICAgc2l6ZSA9IGk7CiAgICAg ICAgIH0KIHVubG9jazoK ------=_Part_11409905_1746344817.1453204409912-- From owner-freebsd-fs@freebsd.org Tue Jan 19 14:15:32 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 49686A8843A for ; Tue, 19 Jan 2016 14:15:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 393A61637 for ; Tue, 19 Jan 2016 14:15:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0JEFVXd034523 for ; Tue, 19 Jan 2016 14:15:32 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 205816] [ext2fs] [patch] EXT4 sparse blocks unsupported, contain garbage when read Date: Tue, 19 Jan 2016 14:15:31 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: feature, patch X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: pfg@FreeBSD.org X-Bugzilla-Flags: mfc-stable9+ mfc-stable10+ X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 14:15:32 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D205816 --- Comment #20 from commit-hook@freebsd.org --- A commit references this bug: Author: pfg Date: Tue Jan 19 14:15:10 UTC 2016 New revision: 294323 URL: https://svnweb.freebsd.org/changeset/base/294323 Log: Revert r294273 MFC r293680 ext4: add support for reading sparse files The change was meant for newer versions and doesn't work out of the box. While it seems easy to adapt I prfer not to have the implementations diverge at this time. Reported by: Arrigo Marchiori PR: 205816 Changes: _U stable/9/sys/ _U stable/9/sys/fs/ stable/9/sys/fs/ext2fs/ext2_bmap.c stable/9/sys/fs/ext2fs/ext2_extents.c stable/9/sys/fs/ext2fs/ext2_extents.h stable/9/sys/fs/ext2fs/ext2_vnops.c --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-fs@freebsd.org Tue Jan 19 14:19:00 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 93EBEA88602 for ; Tue, 19 Jan 2016 14:19:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 844FB1A36 for ; Tue, 19 Jan 2016 14:19:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0JEJ0ON039398 for ; Tue, 19 Jan 2016 14:19:00 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 205816] [ext2fs] [patch] EXT4 sparse blocks unsupported, contain garbage when read Date: Tue, 19 Jan 2016 14:19:00 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: feature, patch X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: pfg@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: pfg@FreeBSD.org X-Bugzilla-Flags: mfc-stable9- mfc-stable10+ X-Bugzilla-Changed-Fields: flagtypes.name bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 14:19:00 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D205816 Pedro F. Giffuni changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|mfc-stable9+ |mfc-stable9- Status|In Progress |Closed Resolution|--- |FIXED --- Comment #21 from Pedro F. Giffuni --- (In reply to Arrigo Marchiori from comment #19) Thanks for the report Arrigo! Merging to stable was admittedly a bad decision. I reverted the change as I don't want to handle diverging versions of the ext2fs driver at this time. I may consider merging a fixed version later. Pedro. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-fs@freebsd.org Tue Jan 19 22:51:41 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 659C3A87763 for ; Tue, 19 Jan 2016 22:51:41 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 03D161795 for ; Tue, 19 Jan 2016 22:51:40 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) IronPort-PHdr: 9a23:1D6juBxWFPHLAQ/XCy+O+j09IxM/srCxBDY+r6Qd0O4TIJqq85mqBkHD//Il1AaPBtWFrasc06GO7+jJYi8p39WoiDg6aptCVhsI2409vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6kO74TNaIBjjLw09fr2zQd6MyZ3vj6vqp9X6WEZhunmUWftKNhK4rAHc5IE9oLBJDeIP8CbPuWZCYO9MxGlldhq5lhf44dqsrtY4q3wD89pozcNLUL37cqIkVvQYSW1+ayFmrPDtrgTJGAuT+mMHACJRlhtTHxOD4gv3U53qvm39rOU63SCbOcj/S/cwWC++7qFlT1jmkioKPSU1tW/M2fB32ZhSrxKouRF5z5TdKK6SK/Z3ZrvUNYcASm1eUs9JTwRbD4+8ZpdJBO0Ea7V2tY748mEPphj2IACnB+fiz3ccnHr/1q4+3uEJDAbJwQEkB9JIu32C/4a9D7sbTe3glPqA9j7Edf4DnG6lsIU= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DQAQDhvJ5W/61jaINEGoQMbQaIULJuAQ2BYxgKhSNKAoF+FAEBAQEBAQEBgQmCLYIHAQEBBAEBARoGBCAHIAsMBAIBCA4DBAEBAQICDRkCAicBCR4IAgQIBwQBCAsJBId6DiyvaIR2inABAQEBAQEBAQEBAQEBAQEBAQEBAQEVe4EihB2EdIQyAQEFRIJrgUkFjjmIYYVIhSuESkqHJYU0imyDbgIgAQFCghEbgXsgNAEGhSU6gQgBAQE X-IronPort-AV: E=Sophos;i="5.22,319,1449550800"; d="scan'208";a="262094234" Received: from nipigon.cs.uoguelph.ca (HELO zcs1.mail.uoguelph.ca) ([131.104.99.173]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 19 Jan 2016 17:51:33 -0500 Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 468C715F55D; Tue, 19 Jan 2016 17:51:33 -0500 (EST) Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Bot-Y-wxxAs5; Tue, 19 Jan 2016 17:51:31 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 6764B15F565; Tue, 19 Jan 2016 17:51:31 -0500 (EST) X-Virus-Scanned: amavisd-new at zcs1.mail.uoguelph.ca Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id LtbZLrfcxgoC; Tue, 19 Jan 2016 17:51:31 -0500 (EST) Received: from zcs1.mail.uoguelph.ca (zcs1.mail.uoguelph.ca [172.17.95.18]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 49A4715F55D; Tue, 19 Jan 2016 17:51:31 -0500 (EST) Date: Tue, 19 Jan 2016 17:51:31 -0500 (EST) From: Rick Macklem To: Raghavendra Gowdappa Cc: Martin Simmons , jdarcy@redhat.com, raghavendra@gluster.com, gluster-devel@gluster.org, freebsd-fs@freebsd.org, xhernandez@datalab.es, jkh@ixsystems.com Message-ID: <1131345057.166731657.1453243891024.JavaMail.zimbra@uoguelph.ca> In-Reply-To: <1210026335.11409907.1453204409914.JavaMail.zimbra@redhat.com> References: <571237035.145690509.1451437960464.JavaMail.zimbra@uoguelph.ca> <1924941590.6473225.1452248249994.JavaMail.zimbra@redhat.com> <981529129.154244852.1452304799182.JavaMail.zimbra@uoguelph.ca> <1256214214.7158114.1452310490692.JavaMail.zimbra@redhat.com> <1045057902.165261325.1453156629344.JavaMail.zimbra@uoguelph.ca> <7769801.11211464.1453183279015.JavaMail.zimbra@redhat.com> <201601191005.u0JA57Nl004520@higson.cam.lispworks.com> <1210026335.11409907.1453204409914.JavaMail.zimbra@redhat.com> Subject: Re: [Gluster-devel] FreeBSD port of GlusterFS racks up a lot of CPU usage MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.10] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF43 (Win)/8.0.9_GA_6191) Thread-Topic: FreeBSD port of GlusterFS racks up a lot of CPU usage Thread-Index: OZOLDNW4oGfXyYSZl51nSYlZYSJouFB8ktyC X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 22:51:41 -0000 Raghavendra Gowdappa wrote: > > > ----- Original Message ----- > > From: "Martin Simmons" > > To: "Raghavendra Gowdappa" > > Cc: rmacklem@uoguelph.ca, jdarcy@redhat.com, raghavendra@gluster.com, > > gluster-devel@gluster.org, > > freebsd-fs@freebsd.org, xhernandez@datalab.es, jkh@ixsystems.com > > Sent: Tuesday, January 19, 2016 3:35:07 PM > > Subject: Re: [Gluster-devel] FreeBSD port of GlusterFS racks up a lot of > > CPU usage > > > > >>>>> On Tue, 19 Jan 2016 01:01:19 -0500 (EST), Raghavendra Gowdappa said: > > > > > > ----- Original Message ----- > > > > From: "Rick Macklem" > > > > To: "Raghavendra Gowdappa" > > > > Cc: "Jeff Darcy" , "Raghavendra G" > > > > , "freebsd-fs" > > > > , "Hubbard Jordan" , "Xavier > > > > Hernandez" , "Gluster > > > > Devel" > > > > Sent: Tuesday, January 19, 2016 4:07:09 AM > > > > Subject: Re: [Gluster-devel] FreeBSD port of GlusterFS racks up a lot > > > > of > > > > CPU usage > > > > > > > > Raghavendra Gowdappa wrote: > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Rick Macklem" > > > > > > To: "Jeff Darcy" > > > > > > Cc: "Raghavendra G" , "freebsd-fs" > > > > > > , "Hubbard Jordan" > > > > > > , "Xavier Hernandez" , > > > > > > "Gluster > > > > > > Devel" > > > > > > Sent: Saturday, January 9, 2016 7:29:59 AM > > > > > > Subject: Re: [Gluster-devel] FreeBSD port of GlusterFS racks up a > > > > > > lot > > > > > > of > > > > > > CPU usage > > > > > > > > > > > > Jeff Darcy wrote: > > > > > > > > > I don't know anything about gluster's poll implementation so > > > > > > > > > I > > > > > > > > > may > > > > > > > > > be totally wrong, but would it be possible to use an eventfd > > > > > > > > > (or a > > > > > > > > > pipe if eventfd is not supported) to signal the need to add > > > > > > > > > more > > > > > > > > > file descriptors to the poll call ? > > > > > > > > > > > > > > > > > > > > > > > > > > > The poll call should listen on this new fd. When we need to > > > > > > > > > change > > > > > > > > > the fd list, we should simply write to the eventfd or pipe > > > > > > > > > from > > > > > > > > > another thread. This will cause the poll call to return and > > > > > > > > > we > > > > > > > > > will > > > > > > > > > be able to change the fd list without having a short timeout > > > > > > > > > nor > > > > > > > > > having to decide on any trade-off. > > > > > > > > > > > > > > > > > > > > > > > > Thats a nice idea. Based on my understanding of why timeouts > > > > > > > > are > > > > > > > > being > > > > > > > > used, this approach can work. > > > > > > > > > > > > > > The own-thread code which preceded the current poll > > > > > > > implementation > > > > > > > did > > > > > > > something similar, using a pipe fd to be woken up for new > > > > > > > *outgoing* > > > > > > > messages. That code still exists, and might provide some insight > > > > > > > into > > > > > > > how to do this for the current poll code. > > > > > > I took a look at event-poll.c and found something interesting... > > > > > > - A pipe called "breaker" is already set up by > > > > > > event_pool_new_poll() > > > > > > and > > > > > > closed by event_pool_destroy_poll(), however it never gets used > > > > > > for > > > > > > anything. > > > > > > > > > > I did a check on history, but couldn't find any information on why it > > > > > was > > > > > removed. Can you send this patch to http://review.gluster.org ? We > > > > > can > > > > > review and merge the patch over there. If you are not aware, > > > > > development > > > > > work flow can be found at: > > > > > > > > > > http://www.gluster.org/community/documentation/index.php/Developers > > > > > > > > > Actually, the patch turned out to be a flop. Sometimes a fuse mount > > > > would > > > > end > > > > up with an empty file system with the patch. (I don't know why it was > > > > broken, > > > > but maybe the original author tan into issues as well?) > > > > > > +static void > > > +event_pool_changed (struct event_pool *event_pool) > > > +{ > > > + > > > + /* Write a byte into the breaker pipe to wake up poll(). */ > > > + if (event_pool->breaker[1] >= 0) > > > + write(event_pool->breaker[1], "X", 1); > > > +} > > > > > > breaker is set to non-blocking on both read and write ends. So, probably > > > write might be failing sometimes with EAGAIN/EBUSY and thereby preventing > > > the socket from being registered. Probably that might be the reason? > > > > In what situations does write return EAGAIN/EBUSY for a pipe? If it is > > only > > when the pipe's internal buffer is full, then there is still unread data > > and > > the reading end will wake up anyway, so there should be no need to write > > more. > > That's a valid point. I was kind of thinking out loud since I couldn't figure > out what was wrong in earlier approach. I was particularly interested in > whether write can fail because of any error. Since we were not checking the > return value, a write failure can result in a socket not being registered. > Though I couldn't think of any particular reason for failure, felt that its > a loose end that can be tied up. > > On a different note, I found a bug in current poll implementation which > could've resulted in high cpu usage. I've attached the diff, which wouldn't > do an array copy (of registered events to ufd) every "timeout" seconds and > which I hope which will bring down cpu usage. The issue was > event_pool->changed was never reset and hence every timeout seconds, we > would interpret that event_pool has changed even though it has not. > I saw this and was going to do what your patch does, but I think that the ufd[] must be re-initialized before another poll call anyhow. (When poll() times out, it does a "continue;" and skips processing the ufd[] list.) The man pages don't clarify which of the fields "event, revent" are guaranteed to remain unchanged when a timeout returns. As such, I would think re-initializing the ufd[] is the safe way to do it. Anyhow, this CPU usage isn't a big deal and mostly goes away when you change the timeout from 1msec->10msec. (Checking for new fds 100 times/sec seems like it should be often enough.) > > > > > > > if (event_pool->breaker[1] >= 0) { > > > do { > > > ret = write(event_pool->breaker[1], "X", 1); > > > } while (ret != 1); This was just to ensure the write succeeds, despite the non-blocking setting. (In the code I was testing, I did have a log message call for when it didn't return 1 and I didn't see that message logged, from what I remember.) To be honest, I am seeing a couple of much more serious problems that I need to chase. (I reported the one about "rm -r" which somehow ends up with files on both bricks even though I am using "plain distribute", so this doesn't make much sense to me. The other is a case of a directory where the "ls" only shows the files from one of the two bricks and can't find the rest of the files, although they are on the other brick. I don't know why this happens for one directory, but not others.) The FreeBSD port is pretty green and the FreeBSD fuse module is, too. I am planning on doing some testing using the NFSv3 server instead, to see if these are fuse related. Bottom line, I'm sorry I even mentioned this. It isn't a big issue and is easily avoided by increasing the timeout to 10msec. Anyhow, thanks for all the comments, rick > > > } > > > > This will busy-wait, which doesn't look good. > > > > > > > Also similar logic might be required while flushing out junk from read > > > end > > > too. > > > > Failure to read everything should be benign because it will just cause poll > > to > > return again immediately next time. > > > > > > > > > > > > Anyhow, I am now using the 3.7.6 event-poll.c code except that I have > > > > increased > > > > the timeout from 1msec->10msec. (Going from 1->5->10 didn't seem to > > > > cause > > > > a > > > > problem, but I got slower test runs when I increased to 20msec, so I've > > > > settled on > > > > 10mses. This does reduce the CPU usage when the GlusterFS file systems > > > > aren't > > > > active.) > > > > I will submit this one line change to your workflow if it continues to > > > > test > > > > ok. > > > > > > > > Thanks for everyone's input, rick > > > > > > > > > > > > > > > > So, I added a few lines of code that writes a byte to it whenever > > > > > > the > > > > > > list > > > > > > of > > > > > > file descriptors is changed and read when poll() returns, if its > > > > > > revents > > > > > > is > > > > > > set. > > > > > > I also changed the timeout to -1 (infinity) and it seems to work > > > > > > for > > > > > > a > > > > > > trivial > > > > > > test. > > > > > > --> Btw, I also noticed the "changed" variable gets set to 1 on a > > > > > > change, > > > > > > but > > > > > > never reset to 0. I didn't change this, since it looks "racey". > > > > > > (ie. > > > > > > I > > > > > > think you could easily get a race between a thread that clears > > > > > > it > > > > > > and > > > > > > one > > > > > > that adds a new fd.) > > > > > > > > > > > > A slightly safer version of the patch would set a long (100msec ??) > > > > > > timeout > > > > > > instead > > > > > > of -1. > > > > > > > > > > > > Anyhow, I've attached the patch in case anyone would like to try it > > > > > > and > > > > > > will > > > > > > create a bug report for this after I've had more time to test it. > > > > > > (I only use a couple of laptops, so my testing will be minimal.) > > > > > > > > > > > > Thanks for all the help, rick > > > > > > > > > > > > > _______________________________________________ > > > > > > > freebsd-fs@freebsd.org mailing list > > > > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > > > > > > > To unsubscribe, send any mail to > > > > > > > "freebsd-fs-unsubscribe@freebsd.org" > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > freebsd-fs@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > > > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > > > > > > From owner-freebsd-fs@freebsd.org Tue Jan 19 23:03:37 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D86D0A87D4C for ; Tue, 19 Jan 2016 23:03:37 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 764F31D86 for ; Tue, 19 Jan 2016 23:03:36 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) IronPort-PHdr: 9a23:e9fAvRAxpfFhzdSkZyR6UyQJP3N1i/DPJgcQr6AfoPdwSP7zosbcNUDSrc9gkEXOFd2CrakU1ayP6/irATBIyK3CmU5BWaQEbwUCh8QSkl5oK+++Imq/EsTXaTcnFt9JTl5v8iLzG0FUHMHjew+a+SXqvnYsExnyfTB4Ov7yUtaLyZ/niabro8WYO1kArQH+SI0xBS3+lR/WuMgSjNkqAYcK4TyNnEF1ff9Lz3hjP1OZkkW0zM6x+Jl+73YY4Kp5pIZoGJ/3dKUgTLFeEC9ucyVsvJWq5lH/Sl6173QcW3sblBZSCkDq6w72V4/pu2OurOV6xyWTJdXeV704WT2+qaxsTUm7pj0AMmsD8WrUwul5h6FfrRfp8wZ6yoXXZIyQHOd5cb7QecsaA2FICJUCHxddC5+xOtNcR9EKOvxV+syk/wMD X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DQAQDCv55W/61jaINEGoQMbQaIULJuAQ2BYxgKhSNKAoF+FAEBAQEBAQEBgQmCLYIHAQEBBAEBASAEJyALDAQCAQgOAwQBAQECAg0ZAgInAQkeCAIECAcEAQgLCQSHeg4sr2yPZgEBAQEBAQEBAQEBAQEBAQEBAQEBARV7gSKEHYR0hDIBAYM0gUkFjjmIYYVIhSuESkqHJYU0imyDbgIgAQFCghEbgXsgNAEGhSU6gQgBAQE X-IronPort-AV: E=Sophos;i="5.22,319,1449550800"; d="scan'208";a="263681084" Received: from nipigon.cs.uoguelph.ca (HELO zcs1.mail.uoguelph.ca) ([131.104.99.173]) by esa-annu.net.uoguelph.ca with ESMTP; 19 Jan 2016 18:03:35 -0500 Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 3899415F55D; Tue, 19 Jan 2016 18:03:35 -0500 (EST) Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id HRv7cWUNnBex; Tue, 19 Jan 2016 18:03:34 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id E3BC615F565; Tue, 19 Jan 2016 18:03:33 -0500 (EST) X-Virus-Scanned: amavisd-new at zcs1.mail.uoguelph.ca Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ixiAjH2CpmTC; Tue, 19 Jan 2016 18:03:33 -0500 (EST) Received: from zcs1.mail.uoguelph.ca (zcs1.mail.uoguelph.ca [172.17.95.18]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 7C7BA15F55D; Tue, 19 Jan 2016 18:03:33 -0500 (EST) Date: Tue, 19 Jan 2016 18:03:33 -0500 (EST) From: Rick Macklem To: Raghavendra Gowdappa Cc: Jeff Darcy , Raghavendra G , freebsd-fs , Hubbard Jordan , Xavier Hernandez , Gluster Devel Message-ID: <2123305838.166743619.1453244613417.JavaMail.zimbra@uoguelph.ca> In-Reply-To: <7769801.11211464.1453183279015.JavaMail.zimbra@redhat.com> References: <571237035.145690509.1451437960464.JavaMail.zimbra@uoguelph.ca> <568F6D07.6070500@datalab.es> <1924941590.6473225.1452248249994.JavaMail.zimbra@redhat.com> <981529129.154244852.1452304799182.JavaMail.zimbra@uoguelph.ca> <1256214214.7158114.1452310490692.JavaMail.zimbra@redhat.com> <1045057902.165261325.1453156629344.JavaMail.zimbra@uoguelph.ca> <7769801.11211464.1453183279015.JavaMail.zimbra@redhat.com> Subject: Re: [Gluster-devel] FreeBSD port of GlusterFS racks up a lot of CPU usage MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.11] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF43 (Win)/8.0.9_GA_6191) Thread-Topic: FreeBSD port of GlusterFS racks up a lot of CPU usage Thread-Index: nzgvBLPPgcBXuRsf6GlZU17foVfxCE+M3nAjcp2ixGppRbv/t1U+cI5TEnAitWU= X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 23:03:38 -0000 Raghavendra Gowdappa wrote: > > > ----- Original Message ----- > > From: "Rick Macklem" > > To: "Raghavendra Gowdappa" > > Cc: "Jeff Darcy" , "Raghavendra G" > > , "freebsd-fs" > > , "Hubbard Jordan" , "Xavier > > Hernandez" , "Gluster > > Devel" > > Sent: Tuesday, January 19, 2016 4:07:09 AM > > Subject: Re: [Gluster-devel] FreeBSD port of GlusterFS racks up a lot of > > CPU usage > > > > Raghavendra Gowdappa wrote: > > > > > > > > > ----- Original Message ----- > > > > From: "Rick Macklem" > > > > To: "Jeff Darcy" > > > > Cc: "Raghavendra G" , "freebsd-fs" > > > > , "Hubbard Jordan" > > > > , "Xavier Hernandez" , > > > > "Gluster > > > > Devel" > > > > Sent: Saturday, January 9, 2016 7:29:59 AM > > > > Subject: Re: [Gluster-devel] FreeBSD port of GlusterFS racks up a lot > > > > of > > > > CPU usage > > > > > > > > Jeff Darcy wrote: > > > > > > > I don't know anything about gluster's poll implementation so I > > > > > > > may > > > > > > > be totally wrong, but would it be possible to use an eventfd (or > > > > > > > a > > > > > > > pipe if eventfd is not supported) to signal the need to add more > > > > > > > file descriptors to the poll call ? > > > > > > > > > > > > > > > > > > > > > The poll call should listen on this new fd. When we need to > > > > > > > change > > > > > > > the fd list, we should simply write to the eventfd or pipe from > > > > > > > another thread. This will cause the poll call to return and we > > > > > > > will > > > > > > > be able to change the fd list without having a short timeout nor > > > > > > > having to decide on any trade-off. > > > > > > > > > > > > > > > > > > Thats a nice idea. Based on my understanding of why timeouts are > > > > > > being > > > > > > used, this approach can work. > > > > > > > > > > The own-thread code which preceded the current poll implementation > > > > > did > > > > > something similar, using a pipe fd to be woken up for new *outgoing* > > > > > messages. That code still exists, and might provide some insight > > > > > into > > > > > how to do this for the current poll code. > > > > I took a look at event-poll.c and found something interesting... > > > > - A pipe called "breaker" is already set up by event_pool_new_poll() > > > > and > > > > closed by event_pool_destroy_poll(), however it never gets used for > > > > anything. > > > > > > I did a check on history, but couldn't find any information on why it was > > > removed. Can you send this patch to http://review.gluster.org ? We can > > > review and merge the patch over there. If you are not aware, development > > > work flow can be found at: > > > > > > http://www.gluster.org/community/documentation/index.php/Developers > > > > > Actually, the patch turned out to be a flop. Sometimes a fuse mount would > > end > > up with an empty file system with the patch. (I don't know why it was > > broken, > > but maybe the original author tan into issues as well?) > > +static void > +event_pool_changed (struct event_pool *event_pool) > +{ > + > + /* Write a byte into the breaker pipe to wake up poll(). */ > + if (event_pool->breaker[1] >= 0) > + write(event_pool->breaker[1], "X", 1); > +} > > breaker is set to non-blocking on both read and write ends. So, probably > write might be failing sometimes with EAGAIN/EBUSY and thereby preventing > the socket from being registered. Probably that might be the reason? > > if (event_pool->breaker[1] >= 0) { > do { > ret = write(event_pool->breaker[1], "X", 1); > } while (ret != 1); > } > > Also similar logic might be required while flushing out junk from read end > too. > Just fyi, I did have a loop on the read() code. Past experience is that a write() only fails when the pipe is full and, as someone else noted, that should have triggered the poll(). I did have log message stuff in the code I was testing, but I didn't look at it closely once I saw it was broken. I just went back to what worked. I may test this some more someday, but until then, the code in 3.7.6 works ok. Thanks for your comments, rick > > > > Anyhow, I am now using the 3.7.6 event-poll.c code except that I have > > increased > > the timeout from 1msec->10msec. (Going from 1->5->10 didn't seem to cause a > > problem, but I got slower test runs when I increased to 20msec, so I've > > settled on > > 10mses. This does reduce the CPU usage when the GlusterFS file systems > > aren't > > active.) > > I will submit this one line change to your workflow if it continues to test > > ok. > > > > Thanks for everyone's input, rick > > > > > > > > > > So, I added a few lines of code that writes a byte to it whenever the > > > > list > > > > of > > > > file descriptors is changed and read when poll() returns, if its > > > > revents > > > > is > > > > set. > > > > I also changed the timeout to -1 (infinity) and it seems to work for a > > > > trivial > > > > test. > > > > --> Btw, I also noticed the "changed" variable gets set to 1 on a > > > > change, > > > > but > > > > never reset to 0. I didn't change this, since it looks "racey". > > > > (ie. > > > > I > > > > think you could easily get a race between a thread that clears it > > > > and > > > > one > > > > that adds a new fd.) > > > > > > > > A slightly safer version of the patch would set a long (100msec ??) > > > > timeout > > > > instead > > > > of -1. > > > > > > > > Anyhow, I've attached the patch in case anyone would like to try it and > > > > will > > > > create a bug report for this after I've had more time to test it. > > > > (I only use a couple of laptops, so my testing will be minimal.) > > > > > > > > Thanks for all the help, rick > > > > > > > > > _______________________________________________ > > > > > freebsd-fs@freebsd.org mailing list > > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > > > > > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > > > > > > > > > > > > > > > From owner-freebsd-fs@freebsd.org Wed Jan 20 04:42:41 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9A0D6A878BC for ; Wed, 20 Jan 2016 04:42:41 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 203191C64 for ; Wed, 20 Jan 2016 04:42:40 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) IronPort-PHdr: 9a23:h8cbJhymIaOupFvXCy+O+j09IxM/srCxBDY+r6Qd0O4TIJqq85mqBkHD//Il1AaPBtWFrasc06GJ7ujJYi8p39WoiDg6aptCVhsI2409vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6kO74TNaIBjjLw09fr2zQd6MyZ3vj6vtptX6WEZhunmUWftKNhK4rAHc5IE9oLBJDeIP8CbPuWZCYO9MxGlldhq5lhf44dqsrtY4q3wD89pozcNLUL37cqIkVvQYSW1+ayFmrPDtrgTJGAuT+mMHACJRlhtTHxOD4gv3U53qvm39rOU63SCbOcj/S/cwWC++7qFlT1jmkioKPSU1tW/M2fB32ZhSrxKouRF5z5TdKK6SK/Z3ZrvUNYcASm1eUs9JTwRbD4+8ZpdJBO0Ea7V2tY748mEPphj2IACnB+fiz3ccnHr/1q4+3uEJDAbJwQEkB9JIu32C/4a9D7sbTe3glPqA9j7Edf4DnG6lsIU= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DQAQA9D59W/61jaINEGoQMbQaIUbJyAQ2BYxgKhSNKAoF/FAEBAQEBAQEBgQmCLYIHAQEBAwEBAQEgBCAHIAsFBwQCAQgOAwQBAQECAg0ZAgInAQkeCAIECAcEAQgLCQSHcggOLK9dhHaKUAEBAQEBAQEBAQEBAQEBAQEBAQEBARV7gSKEHYR0hDIBAUmCa4FJBYdjhlY9iCSFSIUrhEpKhyWFNIpsg24CIAEBQoIRG4F7IDQBBoVpOoEIAQEB X-IronPort-AV: E=Sophos;i="5.22,319,1449550800"; d="scan'208";a="262129284" Received: from nipigon.cs.uoguelph.ca (HELO zcs1.mail.uoguelph.ca) ([131.104.99.173]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 19 Jan 2016 23:42:38 -0500 Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id AE19815F55D; Tue, 19 Jan 2016 23:42:38 -0500 (EST) Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id BemTlmwyJkM0; Tue, 19 Jan 2016 23:42:37 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 1855615F565; Tue, 19 Jan 2016 23:42:37 -0500 (EST) X-Virus-Scanned: amavisd-new at zcs1.mail.uoguelph.ca Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id MrkxAnBGVeD7; Tue, 19 Jan 2016 23:42:36 -0500 (EST) Received: from zcs1.mail.uoguelph.ca (zcs1.mail.uoguelph.ca [172.17.95.18]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id E77A715F55D; Tue, 19 Jan 2016 23:42:36 -0500 (EST) Date: Tue, 19 Jan 2016 23:42:36 -0500 (EST) From: Rick Macklem To: Raghavendra Gowdappa Cc: Martin Simmons , jdarcy@redhat.com, raghavendra@gluster.com, gluster-devel@gluster.org, freebsd-fs@freebsd.org, xhernandez@datalab.es, jkh@ixsystems.com Message-ID: <456488053.167003584.1453264956923.JavaMail.zimbra@uoguelph.ca> In-Reply-To: <1210026335.11409907.1453204409914.JavaMail.zimbra@redhat.com> References: <571237035.145690509.1451437960464.JavaMail.zimbra@uoguelph.ca> <1924941590.6473225.1452248249994.JavaMail.zimbra@redhat.com> <981529129.154244852.1452304799182.JavaMail.zimbra@uoguelph.ca> <1256214214.7158114.1452310490692.JavaMail.zimbra@redhat.com> <1045057902.165261325.1453156629344.JavaMail.zimbra@uoguelph.ca> <7769801.11211464.1453183279015.JavaMail.zimbra@redhat.com> <201601191005.u0JA57Nl004520@higson.cam.lispworks.com> <1210026335.11409907.1453204409914.JavaMail.zimbra@redhat.com> Subject: Re: [Gluster-devel] FreeBSD port of GlusterFS racks up a lot of CPU usage MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.11] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF43 (Win)/8.0.9_GA_6191) Thread-Topic: FreeBSD port of GlusterFS racks up a lot of CPU usage Thread-Index: OZOLDNW4oGfXyYSZl51nSYlZYSJouJYp5+QD X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 04:42:41 -0000 Raghavendra Gowdappa wrote: > > > ----- Original Message ----- > > From: "Martin Simmons" > > To: "Raghavendra Gowdappa" > > Cc: rmacklem@uoguelph.ca, jdarcy@redhat.com, raghavendra@gluster.com, > > gluster-devel@gluster.org, > > freebsd-fs@freebsd.org, xhernandez@datalab.es, jkh@ixsystems.com > > Sent: Tuesday, January 19, 2016 3:35:07 PM > > Subject: Re: [Gluster-devel] FreeBSD port of GlusterFS racks up a lot of > > CPU usage > > > > >>>>> On Tue, 19 Jan 2016 01:01:19 -0500 (EST), Raghavendra Gowdappa said: > > > > > > ----- Original Message ----- > > > > From: "Rick Macklem" > > > > To: "Raghavendra Gowdappa" > > > > Cc: "Jeff Darcy" , "Raghavendra G" > > > > , "freebsd-fs" > > > > , "Hubbard Jordan" , "Xavier > > > > Hernandez" , "Gluster > > > > Devel" > > > > Sent: Tuesday, January 19, 2016 4:07:09 AM > > > > Subject: Re: [Gluster-devel] FreeBSD port of GlusterFS racks up a lot > > > > of > > > > CPU usage > > > > > > > > Raghavendra Gowdappa wrote: > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Rick Macklem" > > > > > > To: "Jeff Darcy" > > > > > > Cc: "Raghavendra G" , "freebsd-fs" > > > > > > , "Hubbard Jordan" > > > > > > , "Xavier Hernandez" , > > > > > > "Gluster > > > > > > Devel" > > > > > > Sent: Saturday, January 9, 2016 7:29:59 AM > > > > > > Subject: Re: [Gluster-devel] FreeBSD port of GlusterFS racks up a > > > > > > lot > > > > > > of > > > > > > CPU usage > > > > > > > > > > > > Jeff Darcy wrote: > > > > > > > > > I don't know anything about gluster's poll implementation so > > > > > > > > > I > > > > > > > > > may > > > > > > > > > be totally wrong, but would it be possible to use an eventfd > > > > > > > > > (or a > > > > > > > > > pipe if eventfd is not supported) to signal the need to add > > > > > > > > > more > > > > > > > > > file descriptors to the poll call ? > > > > > > > > > > > > > > > > > > > > > > > > > > > The poll call should listen on this new fd. When we need to > > > > > > > > > change > > > > > > > > > the fd list, we should simply write to the eventfd or pipe > > > > > > > > > from > > > > > > > > > another thread. This will cause the poll call to return and > > > > > > > > > we > > > > > > > > > will > > > > > > > > > be able to change the fd list without having a short timeout > > > > > > > > > nor > > > > > > > > > having to decide on any trade-off. > > > > > > > > > > > > > > > > > > > > > > > > Thats a nice idea. Based on my understanding of why timeouts > > > > > > > > are > > > > > > > > being > > > > > > > > used, this approach can work. > > > > > > > > > > > > > > The own-thread code which preceded the current poll > > > > > > > implementation > > > > > > > did > > > > > > > something similar, using a pipe fd to be woken up for new > > > > > > > *outgoing* > > > > > > > messages. That code still exists, and might provide some insight > > > > > > > into > > > > > > > how to do this for the current poll code. > > > > > > I took a look at event-poll.c and found something interesting... > > > > > > - A pipe called "breaker" is already set up by > > > > > > event_pool_new_poll() > > > > > > and > > > > > > closed by event_pool_destroy_poll(), however it never gets used > > > > > > for > > > > > > anything. > > > > > > > > > > I did a check on history, but couldn't find any information on why it > > > > > was > > > > > removed. Can you send this patch to http://review.gluster.org ? We > > > > > can > > > > > review and merge the patch over there. If you are not aware, > > > > > development > > > > > work flow can be found at: > > > > > > > > > > http://www.gluster.org/community/documentation/index.php/Developers > > > > > > > > > Actually, the patch turned out to be a flop. Sometimes a fuse mount > > > > would > > > > end > > > > up with an empty file system with the patch. (I don't know why it was > > > > broken, > > > > but maybe the original author tan into issues as well?) > > > > > > +static void > > > +event_pool_changed (struct event_pool *event_pool) > > > +{ > > > + > > > + /* Write a byte into the breaker pipe to wake up poll(). */ > > > + if (event_pool->breaker[1] >= 0) > > > + write(event_pool->breaker[1], "X", 1); > > > +} > > > > > > breaker is set to non-blocking on both read and write ends. So, probably > > > write might be failing sometimes with EAGAIN/EBUSY and thereby preventing > > > the socket from being registered. Probably that might be the reason? > > > > In what situations does write return EAGAIN/EBUSY for a pipe? If it is > > only > > when the pipe's internal buffer is full, then there is still unread data > > and > > the reading end will wake up anyway, so there should be no need to write > > more. > > That's a valid point. I was kind of thinking out loud since I couldn't figure > out what was wrong in earlier approach. I was particularly interested in > whether write can fail because of any error. Since we were not checking the > return value, a write failure can result in a socket not being registered. > Though I couldn't think of any particular reason for failure, felt that its > a loose end that can be tied up. > > On a different note, I found a bug in current poll implementation which > could've resulted in high cpu usage. I've attached the diff, which wouldn't > do an array copy (of registered events to ufd) every "timeout" seconds and > which I hope which will bring down cpu usage. The issue was > event_pool->changed was never reset and hence every timeout seconds, we > would interpret that event_pool has changed even though it has not. > > > > > > > > if (event_pool->breaker[1] >= 0) { > > > do { > > > ret = write(event_pool->breaker[1], "X", 1); > > > } while (ret != 1); > > > } > > > > This will busy-wait, which doesn't look good. > > Sorry. I should have looked before I replied before. In FreeBSD, a pipe write() will fail with errno EAGAIN if the pipe is full. (For that case, I don't think a retry would be necessary. It does look like there is a very slight possibility that the write() could fail with errno EINTR when a signal is posted to the thread/process. (I have no idea if this will ever happen in GlusterFS, but looping while the write() fails with errno EINTR would probably be more correct than no loop. When I looked at this I found that I had broken the read() on the pipe when I added some logging code (not in the patch I posted) for the read() failed with EAGAIN (ie. no data to be read) case. This probably explains why the patch failed. I will test a fixed up patch someday and if it seems to work fine for a fair amount of testing, I will submit it for review. As noted before, it isn't a serious problem, so I don't think there is any rush on this. Sorry for the confusion I caused, rick > > > > > Also similar logic might be required while flushing out junk from read > > > end > > > too. > > > > Failure to read everything should be benign because it will just cause poll > > to > > return again immediately next time. > > > > > > > > > > > > Anyhow, I am now using the 3.7.6 event-poll.c code except that I have > > > > increased > > > > the timeout from 1msec->10msec. (Going from 1->5->10 didn't seem to > > > > cause > > > > a > > > > problem, but I got slower test runs when I increased to 20msec, so I've > > > > settled on > > > > 10mses. This does reduce the CPU usage when the GlusterFS file systems > > > > aren't > > > > active.) > > > > I will submit this one line change to your workflow if it continues to > > > > test > > > > ok. > > > > > > > > Thanks for everyone's input, rick > > > > > > > > > > > > > > > > So, I added a few lines of code that writes a byte to it whenever > > > > > > the > > > > > > list > > > > > > of > > > > > > file descriptors is changed and read when poll() returns, if its > > > > > > revents > > > > > > is > > > > > > set. > > > > > > I also changed the timeout to -1 (infinity) and it seems to work > > > > > > for > > > > > > a > > > > > > trivial > > > > > > test. > > > > > > --> Btw, I also noticed the "changed" variable gets set to 1 on a > > > > > > change, > > > > > > but > > > > > > never reset to 0. I didn't change this, since it looks "racey". > > > > > > (ie. > > > > > > I > > > > > > think you could easily get a race between a thread that clears > > > > > > it > > > > > > and > > > > > > one > > > > > > that adds a new fd.) > > > > > > > > > > > > A slightly safer version of the patch would set a long (100msec ??) > > > > > > timeout > > > > > > instead > > > > > > of -1. > > > > > > > > > > > > Anyhow, I've attached the patch in case anyone would like to try it > > > > > > and > > > > > > will > > > > > > create a bug report for this after I've had more time to test it. > > > > > > (I only use a couple of laptops, so my testing will be minimal.) > > > > > > > > > > > > Thanks for all the help, rick > > > > > > > > > > > > > _______________________________________________ > > > > > > > freebsd-fs@freebsd.org mailing list > > > > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > > > > > > > To unsubscribe, send any mail to > > > > > > > "freebsd-fs-unsubscribe@freebsd.org" > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > freebsd-fs@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > > > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > > > > > > From owner-freebsd-fs@freebsd.org Wed Jan 20 04:50:18 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6D9FFA87A7D for ; Wed, 20 Jan 2016 04:50:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5DC3C1D33 for ; Wed, 20 Jan 2016 04:50:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0K4oH1t091487 for ; Wed, 20 Jan 2016 04:50:18 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 206238] FUSE can't enter to DIRECT_IO mode during file create. Date: Wed, 20 Jan 2016 04:50:17 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: rmacklem@uoguelph.ca X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 04:50:18 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206238 --- Comment #5 from rmacklem@uoguelph.ca --- A guess w.r.t. getting these patches in a release would be 6mon->1year. Now, the patches will probably make it into what FreeBSD calls head/current in April and in stable/10 in May. (This assumes that head isn't frozen for the FreeBSD11 release in April.) (It's too late for the 10.3 release and I'm not sure if/when a 10.4 release is planned.) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Thu Jan 21 05:43:57 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8908DA8A203 for ; Thu, 21 Jan 2016 05:43:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7A48F15E0 for ; Thu, 21 Jan 2016 05:43:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0L5huJd017908 for ; Thu, 21 Jan 2016 05:43:57 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 206448] ZFS hang/stall when drives in ATA mode Date: Thu, 21 Jan 2016 05:43:57 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 05:43:57 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206448 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri Jan 22 15:43:09 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 02028A8DBBA for ; Fri, 22 Jan 2016 15:43:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E8A2A1A13 for ; Fri, 22 Jan 2016 15:43:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0MFh8pD085881 for ; Fri, 22 Jan 2016 15:43:08 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 181565] [swap] Problem with vnode-backed swap space. Date: Fri, 22 Jan 2016 15:43:09 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rs@bytecamp.net X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 15:43:09 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D181565 Robert Schulze changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rs@bytecamp.net --- Comment #3 from Robert Schulze --- If you add "late" to the mount options, it will work. This is not properly documented. With kind regards, Robert Schulze --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri Jan 22 22:35:27 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AB150A8E4CC for ; Fri, 22 Jan 2016 22:35:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9A94111BA for ; Fri, 22 Jan 2016 22:35:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0MMZRSq049474 for ; Fri, 22 Jan 2016 22:35:27 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 181565] [swap] Problem with vnode-backed swap space. Date: Fri, 22 Jan 2016 22:35:27 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 22:35:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D181565 Mark Millard changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |markmi@dsl-only.net --- Comment #4 from Mark Millard --- FYI: See Bug 206048 - 11.0-CURRENT -r293227 (and others) arm (rpi2/BeagleBone Black) amd64 etc: swapfile usage hangs; swap partition works for a problem that may apply to 10.x as well when using things like: file=3D/var/spool/swap/swapfile file=3D/swap0 --unless those files are on their own file systems/partitions not used for other (used) files. (A swap file by itself on its own partition/file system= has not shown the problem. Mixing with other IO from the same file system/parti= tion does. But only so much information can be put in a subject line.) It may be worth testing if the involved 10.x context(s) hang before settlin= g on this sort of placement of the file. One of the comments suggested a command like: stress -d 2 -m 3 --vm-keep was sufficient to show the problem on at least 11.0-CURRENT amd64 contexts.= I guess that command is from the port sysutils/stress . It would actually be good to have 10.x comments in Bug 206048 reporting how such testing went if someone tries it. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sat Jan 23 16:03:23 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 33F4DA8D218 for ; Sat, 23 Jan 2016 16:03:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0439F1036 for ; Sat, 23 Jan 2016 16:03:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0NG3MP9042493 for ; Sat, 23 Jan 2016 16:03:22 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 206530] ext2fs: fsck.ext3 reports "Inode 157938 has INDEX_FL flag set but is not a directory" Date: Sat, 23 Jan 2016 16:03:22 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: damjan.jov@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status keywords bug_severity priority component assigned_to reporter cc attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 16:03:23 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206530 Bug ID: 206530 Summary: ext2fs: fsck.ext3 reports "Inode 157938 has INDEX_FL flag set but is not a directory" Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: New Keywords: patch Severity: Affects Some People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: damjan.jov@gmail.com CC: freebsd-fs@FreeBSD.org Created attachment 166011 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D166011&action= =3Dedit Initialize the inode's i_flag to 0 during allocation fsck.ext3 on a cleanly unmounted EXT3 filesystem that went through heavy fi= le creation (OpenOffice build, about 80000 new files) gives a dozen or so of t= hese errors during "Pass 1: Checking inodes, blocks, and sizes": Inode 157938 has INDEX_FL flag set but is not a directory. Clear HTree index? This error is benign to our ext2fs driver, as it requires the inode's mode = to be directory for this flag to have any effect. However it's not benign to o= ther EXT3 implementations - it breaks at least fsck.ext3 itself if the "-n" opti= on to it is used or "no" is answered to that question, since it misinterprets = the inode as a directory, giving further false errors because that pseudo-direc= tory will appear corrupt. Adding this hack: if (!S_ISDIR(ip->i_mode) && (ip->i_flag & IN_E4INDEX) !=3D 0) panic("non-directory has index!?\n"); to ext2_i2ei() to catch wrong use of this flag just before the inode is wri= tten to disk, produces this revealing stack trace: KDB: stack backtrace: db_trace_self_wrapper() vpanic() panic() ext2_i2ei() ext2_update() ext2_makeinode() ext2_create() VOP_CREATE_APV() vn_open_cred() kern_openat() amd64_syscall() Xfast_syscall() Reading through those functions shows ext2_makeinode() calls ext2_valloc() which apparently reuses inodes from disk without initializing their i_flag field, hence if a previously deleted directory's inode is reused for a file, the IN_E4INDEX flag from it will still be set, and wrongly written to the file's inode! I am attaching a patch that initializes i_flag to 0. With it, fsck.ext3 rep= orts a clean scan after the same test. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-fs@freebsd.org Sat Jan 23 17:57:42 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D00BBA8EFF2 for ; Sat, 23 Jan 2016 17:57:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C0B4D1B79 for ; Sat, 23 Jan 2016 17:57:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0NHvgIC001051 for ; Sat, 23 Jan 2016 17:57:42 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 206530] ext2fs: fsck.ext3 reports "Inode 157938 has INDEX_FL flag set but is not a directory" Date: Sat, 23 Jan 2016 17:57:43 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: pfg@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: pfg@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 17:57:42 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206530 Pedro F. Giffuni changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |In Progress CC| |pfg@FreeBSD.org Assignee|freebsd-bugs@FreeBSD.org |pfg@FreeBSD.org --- Comment #1 from Pedro F. Giffuni --- Take ... --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-fs@freebsd.org Sat Jan 23 18:47:10 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 92670A8FDA7 for ; Sat, 23 Jan 2016 18:47:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7F8401772 for ; Sat, 23 Jan 2016 18:47:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0NIlAQH080556 for ; Sat, 23 Jan 2016 18:47:10 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 206530] ext2fs: fsck.ext3 reports "Inode 157938 has INDEX_FL flag set but is not a directory" Date: Sat, 23 Jan 2016 18:47:10 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: pfg@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: pfg@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 18:47:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206530 --- Comment #2 from Pedro F. Giffuni --- (In reply to Damjan Jovanovic from comment #0) While your patch is not wrong, the root cause is elsewhere. IN_E4INDEX and IN_E4EXTENTS are Ext4 attributes that we hide in i_flag but they should never get written since we don't have Ext4 write support. Curiously, it appears the situation also happened at some point on linux: http://sourceforge.net/p/e2fsprogs/bugs/41/ --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-fs@freebsd.org Sat Jan 23 21:01:34 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BB7B0A8E863 for ; Sat, 23 Jan 2016 21:01:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AC8F31257 for ; Sat, 23 Jan 2016 21:01:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0NL1YeC085617 for ; Sat, 23 Jan 2016 21:01:34 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 206530] ext2fs: fsck.ext3 reports "Inode 157938 has INDEX_FL flag set but is not a directory" Date: Sat, 23 Jan 2016 21:01:34 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: pfg@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: pfg@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 21:01:34 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206530 --- Comment #3 from Pedro F. Giffuni --- Created attachment 166027 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D166027&action= =3Dedit Alternative workaround I still have to check if we are handling i_flag correctly but please test t= his workaround for now. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-fs@freebsd.org Sat Jan 23 21:21:53 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 95BDAA8F098 for ; Sat, 23 Jan 2016 21:21:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 86BC51EAA for ; Sat, 23 Jan 2016 21:21:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0NLLrNr042395 for ; Sat, 23 Jan 2016 21:21:53 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 206530] ext2fs: fsck.ext3 reports "Inode 157938 has INDEX_FL flag set but is not a directory" Date: Sat, 23 Jan 2016 21:21:53 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: pfg@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: pfg@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 21:21:53 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206530 Pedro F. Giffuni changed: What |Removed |Added ---------------------------------------------------------------------------- CC|freebsd-fs@FreeBSD.org |gnehzuil@gmail.com --- Comment #4 from Pedro F. Giffuni --- Add Zheng Liu --=20 You are receiving this mail because: You are on the CC list for the bug.=