Date: Mon, 21 Mar 2016 15:11:53 -0700 From: bob prohaska <fbsd@www.zefox.net> To: Ian Lepore <ian@freebsd.org> Cc: freebsd-arm@freebsd.org, bob prohaska <fbsd@www.zefox.net> Subject: Re: Effect of partitioning on wear-leveling Message-ID: <20160321221153.GB83908@www.zefox.net> In-Reply-To: <1458586884.68920.96.camel@freebsd.org> References: <20160321175952.GA83908@www.zefox.net> <1458586884.68920.96.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160321221153.GB83908>