Date: Mon, 21 Mar 2016 16:41:10 -0600 From: Ian Lepore <ian@freebsd.org> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm@freebsd.org Subject: Re: Effect of partitioning on wear-leveling Message-ID: <1458600070.68920.107.camel@freebsd.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1458600070.68920.107.camel>