From owner-freebsd-arm@freebsd.org Wed Mar 23 06:36:39 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 A6387AD7C91 for ; Wed, 23 Mar 2016 06:36:39 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6E935150C for ; Wed, 23 Mar 2016 06:36:39 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22d.google.com with SMTP id 124so19985063iov.3 for ; Tue, 22 Mar 2016 23:36:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=P/fe7SkyuuqUDclH23kx39f91iZhJqPQfVsrJR8OScc=; b=V8IxuMT9QFsq0UyNswa4n3/V89iIQwUyBciLEneM0JqmBTYH4gokUk/JyW9nvFWQJ9 RGCluhH4uexViZAzdTpJtOdvV353Ilzcl9JPkQyno95yPFxksZq64KBGNeX/ot4LA+eg pT0ELSn/T3PY0PAQyPwQodJnf/L7v/z9PnTvQBZdfffCjxtQkluoTBO/IMDk68BY7wnj 5QELIESObGE9ctcM2Pc/v5p1295Bn9Te6TFH6IZii7J19WusWsz3qj7qEGUyr/J2yiMq EWhRTQTlYv8Rk0846YsyqrHkPOWkhpnOETxcRU7dwhDzCot8PzlpaKHgV/xZzDhnoEjN emgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=P/fe7SkyuuqUDclH23kx39f91iZhJqPQfVsrJR8OScc=; b=XGcWDklYL7CTl3gDlBrvrfeycEcnH5D5dE1TELLMA0teXYIElik+X+mnIVhUYt4uyA 5lOvWwoOxqfuFt5sroF7k8wBLIcDUrN6lGgdibLVDHkZuuM7YOPVmS4vfQQhp4V6J5kz E+g8GVM0zRDpB/4lw4exOJUsGBpZxarnsQ7qPjRxIqOAa3HYkhgK6BvxdeXGswh24F/e ucs97USi0m/ybFVUe/JoDQ440dyFpvxp09tlCSjGvPdQUTbCreFD+QsyoH67prreJYYC fngPuFYDMOUACuLbJYOb0DeVkk/n9DBTA5/kwFsTE2aSPFg10DaySzUn56cfkJsFtQkZ 01ow== X-Gm-Message-State: AD7BkJLfJkHVAHLGznbAamfhqjAXAk8e+tGh8y4y3hHpiKSsscFgPNKA1VuxW9T5dLtw/vWBVLSJD/eFkIJEqg== MIME-Version: 1.0 X-Received: by 10.50.30.134 with SMTP id s6mr21215665igh.36.1458714998856; Tue, 22 Mar 2016 23:36:38 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.36.65.230 with HTTP; Tue, 22 Mar 2016 23:36:38 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: <20160322141432.3f0a3a61@X220.alogt.com> References: <20160321175952.GA83908@www.zefox.net> <1458586884.68920.96.camel@freebsd.org> <20160321221153.GB83908@www.zefox.net> <20160322141432.3f0a3a61@X220.alogt.com> Date: Wed, 23 Mar 2016 00:36:38 -0600 X-Google-Sender-Auth: oae0YMDEVjMzpcFxmEIK_LvF-VY Message-ID: Subject: Re: Effect of partitioning on wear-leveling From: Warner Losh To: Erich Dollansky Cc: bob prohaska , "freebsd-arm@freebsd.org" , Ian Lepore Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 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: Wed, 23 Mar 2016 06:36:39 -0000 On Tue, Mar 22, 2016 at 12:14 AM, Erich Dollansky wrote: > Hi, > > On Mon, 21 Mar 2016 15:11:53 -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? > > > we use memory disk for /var and /tmp. If you really need the content of > these directories, you could write them back to flash by a script every > hour or so and save all the writes between. > > Do not forget the flash devices used in Raspberries & Co. cannot be > compared with the flash devices used in flash disk. Raspberries don't have flash. :) SD cards generally use similar NAND to consumer grade SSDs, but have firmware optimized for the digital camera market. There are some differences, but the chips are basically the same under the hood. Many of the optimizations trade off speed for longevity differently between SSDs and SD cards. NVME adds a new layer of fun to all this, but even there tweaks to the different program and erase algorithms are extensive. Warner