From owner-freebsd-stable@freebsd.org Wed Dec 9 14:50:53 2015 Return-Path: Delivered-To: freebsd-stable@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 47EB49D5D6E for ; Wed, 9 Dec 2015 14:50:53 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from smtp.rlwinm.de (smtp.rlwinm.de [IPv6:2a01:4f8:201:31ef::e]) (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 13DE91DE6 for ; Wed, 9 Dec 2015 14:50:53 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from crest.local (unknown [87.253.189.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.rlwinm.de (Postfix) with ESMTPSA id 61943C05C for ; Wed, 9 Dec 2015 15:50:42 +0100 (CET) Subject: Re: Periodic jobs triggering panics in 10.1 and 10.2 To: freebsd-stable@freebsd.org References: <34FA7D40-8758-460D-AC14-20B21D2E3F8D@ebureau.com> <1449619470.31831.9.camel@michaeleichorn.com> <56682278.4040302@sorbs.net> From: Jan Bramkamp Message-ID: <56683FC1.3050001@rlwinm.de> Date: Wed, 9 Dec 2015 15:50:41 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <56682278.4040302@sorbs.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 14:50:53 -0000 On 09/12/15 13:45, Michelle Sullivan wrote: > Michael B. Eichorn wrote: >> On Tue, 2015-12-08 at 16:31 -0600, Dustin Wenz wrote: >> >>> I suspect this is a zfs bug that is triggered by the access patterns >>> in the periodic scripts. There is significant load on the system when >>> the scheduled processes start, because all jails execute the same >>> scripts at the same time. >>> >>> I've been able to alleviate this problem by disabling the security >>> scans within the jails, but leave it enabled on the root host. >>> >> >> To avoid the problem of jails all starting things at the same time, use >> the cron(8) flags -j and -J to set a 'jitter' which will cause cron to >> sleep for a random period of specified duration (60 sec max). Cron >> flags can be set using the rc.conf variable 'cron_flags'. >> _______________________________________________ >> > > No that will just hide it (if successful at all) and it won't work in > all cases. > > ... i386 is even worse for similar (not the same) instability triggered > by the same scripts ... because zfs should not be used with the stock > i386 kernel (which means if you're using it the whole patching process > with freebsd-update won't work or will 'undo' your kernel config.) Do you have a good idea how to prevent users from shooting themselves in the foot by running ZFS on 32 Bit kernels? > Personally I think zfs should be optional only for 'advanced' users and > come with a whole host of warnings about what it is not suitable for.... > however, it seems to be treated as a magic bullet for data corruption > issues yet all I have seen is an ever growing list of where it causes > problems.. when did UFS become an unreliable FS that is susceptible to > chronic data corruption? As storage capacity grew a lot faster than reliability. UFS is a good file system for its time, but it trusts hardware absolutely. Modern hardware doesn't deserve this level of trust. ZFS detects and recovers without dataloss from most errors caused by the limited hardware reliability. ZFS isn't just a tool to deal with hardware limitations it's also a convenience I no longer want to give up. Snapshots and replication streams simplify backups and a background scrub once a week (or month) sure beats waiting for fsck.