From owner-freebsd-arm@freebsd.org Tue Dec 15 20:27:24 2015 Return-Path: Delivered-To: freebsd-arm@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 4B205A485C7 for ; Tue, 15 Dec 2015 20:27:24 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from erouter6.ore.mailhop.org (erouter6.ore.mailhop.org [54.187.213.119]) (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 13CF911BB for ; Tue, 15 Dec 2015 20:27:24 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound3.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Tue, 15 Dec 2015 20:27:16 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id tBFKRLfH021453; Tue, 15 Dec 2015 13:27:21 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1450211241.25138.75.camel@freebsd.org> Subject: Re: No space left in lost+found From: Ian Lepore To: Mark Felder , bob prohaska Cc: freebsd-arm@freebsd.org Date: Tue, 15 Dec 2015 13:27:21 -0700 In-Reply-To: <1450209274.4299.468358681.22757635@webmail.messagingengine.com> References: <20151215181047.GA29187@www.zefox.net> <1450204738.4176380.468287977.048387B9@webmail.messagingengine.com> <20151215191845.GB29187@www.zefox.net> <1450209274.4299.468358681.22757635@webmail.messagingengine.com> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 20:27:24 -0000 On Tue, 2015-12-15 at 13:54 -0600, Mark Felder wrote: > > On Tue, Dec 15, 2015, at 13:18, bob prohaska wrote: > > Hi Mark, > > > > Here's what I get, da0p4 is /tmp > > > > root@www:/lost+found # tunefs -p /dev/da0p4 > > tunefs: soft update journaling: (-j) enabled > > > root@www:/lost+found # tunefs -p /dev/mmcsd0s2a > > tunefs: soft update journaling: (-j) enabled > > I would recommend turning off soft update journaling and see if your > problem goes away. If that doesn't work, perhaps disable soft updates > entirely. Anyone else have thoughts on this? > I've always been anti-journaling, but only some of reasons are based inprovable facts. Over the years there have been a lot of complaints about it. Probably some of them were genuine then, but have long since been fixed. Some of them may have been user error or bad hardware. But all in all, it has left me with a very negative opinion of journaling with ufs. But that's all emotion, not really hard facts. A few factual things... Journaling means doing a lot more writing and on an sdcard that's slow. A lot of people say it's also bad in terms of wearing out the card, but that doesn't worry me so much, it's a lot harder to kill an sdcard than most people think. To me the strongest argument against it for most small-system users is that the whole point of journaling is to take a small performance hit on each write to avoid a long (sometimes hours-long) downtime doing fsck after a crash. It doesn't improve reliability by storing extra info that can make a better recovery than fsck alone, it's just a "pay me now or pay me later" performance tradeoff. But on an sdcard the performance hit for extra writing isn't small, and the time to do a full fsck after a crash isn't large. So in that sense journaling adds nothing of value. IMO, soft updates (without journaling) is almost mandatory on an sdcard. Without it, there is so much extra metadata IO that performance is horrible. -- Ian