From owner-freebsd-arm@freebsd.org Mon Mar 21 22:41:13 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 2544CAD8532 for ; Mon, 21 Mar 2016 22:41:13 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 0C362C93 for ; Mon, 21 Mar 2016 22:41:12 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 09923358-efb6-11e5-9036-c33267960ba8 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Mon, 21 Mar 2016 22:41:22 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u2LMfA1S009972; Mon, 21 Mar 2016 16:41:10 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1458600070.68920.107.camel@freebsd.org> Subject: Re: Effect of partitioning on wear-leveling From: Ian Lepore To: bob prohaska Cc: freebsd-arm@freebsd.org Date: Mon, 21 Mar 2016 16:41:10 -0600 In-Reply-To: <20160321221153.GB83908@www.zefox.net> References: <20160321175952.GA83908@www.zefox.net> <1458586884.68920.96.camel@freebsd.org> <20160321221153.GB83908@www.zefox.net> 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.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:41:13 -0000 On Mon, 2016-03-21 at 15:11 -0700, bob prohaska wrote: > 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 My point was: every block written to the device might end up anywhere on the device. A block written to /var might end up right next to a block from the rootfs that's mounted read-only. Furthermore, the device may decide to move blocks around internally that you haven't even written to for months or years. For example, if a 1MB erase block only contains a few 512 byte areas with live data, the controller might just move those to a more-used 1MB block and erase the original so that the original block is ready for new data in the future without an erase delay. It keeps a translation table off to the side so that it knows when you ask for block N, that's currently living in its idea of block M somewhere else. So, it makes no sense to me to worry about any of this. There's basically nothing you can do with partitioning that has any deterministic effect on where the data gets stored in the device. Also, it's been my experience that it's impossible to "wear out" an sdcard. I once ran a program that just wrote random data continuously at full speed to a 512MB card for several months nonstop. No noticible effect on the card. I actually still use that card today (in one of our older products whose filesystem image only needs about 40MB). -- Ian