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