From owner-freebsd-arm@freebsd.org Mon Mar 21 22:11:55 2016 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 A7F8DAD8E46 for ; Mon, 21 Mar 2016 22:11:55 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (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 72B5332A; Mon, 21 Mar 2016 22:11:55 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.14.9/8.14.5) with ESMTP id u2LMBr4m084485; Mon, 21 Mar 2016 15:11:53 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.14.9/8.14.5/Submit) id u2LMBrRD084484; Mon, 21 Mar 2016 15:11:53 -0700 (PDT) (envelope-from fbsd) Date: Mon, 21 Mar 2016 15:11:53 -0700 From: bob prohaska To: Ian Lepore Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: Effect of partitioning on wear-leveling Message-ID: <20160321221153.GB83908@www.zefox.net> References: <20160321175952.GA83908@www.zefox.net> <1458586884.68920.96.camel@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1458586884.68920.96.camel@freebsd.org> User-Agent: Mutt/1.4.2.3i X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 22:11:55 -0000 On Mon, Mar 21, 2016 at 01:01:24PM -0600, Ian Lepore wrote: > > Freebsd does no wear-leveling, it's up to the microcontrollers within > the storage devices to do that. > > Those controllers have no notion of partitioning or filesystem layout > and do whatever they want to do internally about wear leveling. That > leads to the mildly disturbing situation of having blocks from a > readonly filesystem and blocks from a writable filesystem sharing the > same flash erase-block inside the device. One likes to think of the > data in a readonly filesystem as safely protected from the read-modify > -write activity that happens at the flash erase-block level, but no > such g'tee is made on any mmc, sd, or usb flash-based devices I know > of. > > - Ian > Ok, thanks. It sounds like /var and /tmp could be confined to limited-size partitions while still permitting wear leveling to use other, less-used parts of the device. So, if a block nominally in /var reaches end of life can the wear leveling controller start stashing data anywhere on the device? As a practical matter, should I even be worrying about this? Folks once made a big deal of partitioning storage so a runaway process couldn't choke the whole machine. Is the precaution still worth taking on ARM? bob prohaska