From owner-freebsd-arch@freebsd.org Fri Nov 2 17:26:57 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 048DA10D43D6 for ; Fri, 2 Nov 2018 17:26:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it1-x12f.google.com (mail-it1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8C016764AB for ; Fri, 2 Nov 2018 17:26:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it1-x12f.google.com with SMTP id p64-v6so4208862itp.0 for ; Fri, 02 Nov 2018 10:26:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=x7UfYorw/CzWNVSPE1MiOm14pjdEcCmu4UnfkqANxAw=; b=KDPlqMuZAEPYhZ0zirJY9vjyqdANs5FoHH+VI3mLluw3aIDWl0GsfqbPHtIeFzQgyL igKu/MaQwobv8iOeMrnhJ/FkybP8DxjqWdeO+OIHmtXVVuaEI3k17SaoUaHkyB5bmB6i iuMguAmBYrLQSfg1OL2ggOxcM7nABXE8Cblz6a7xZqOHYrkFXfDOscD9XMlQJ76MnUFD OkEO+4fJNFli2FmUp61BfFylexz8INW286U3sSnwQ12nj8lKdGyDvF5Q7rL+qKUeScm2 qn1G357AeA6yginw983QTJRIx525ewpiR7dofcZ/ArkDXEcq1g3590BnkHjY3GLIFCg3 Ht5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=x7UfYorw/CzWNVSPE1MiOm14pjdEcCmu4UnfkqANxAw=; b=iLyVqoGw/7IUM5CStsN3wcBtpZGhXasNF31gxMqIUz6s+nqtNomD+34YoMZiBl+rPM cvf3XuUf/Nd7/a6CPpuwjo9c/p/nM0EKrRlOvqQVsRFAa5TmXTpEqhC0xLjoKwvvMKUG JaoqRCbOrMrZQw/MP8yvKcWwhtwT83gK6BwFwQ7/WR27tul1gXta8pC/zjeCmlLfDP6e UPCh8l7oH0uOVyLSa048locwl/7tdCocLbQCtSWIpICQ0jJydRfv2NJ9tURU9QP79sw0 +i0RoOaLOoUyCxbOG27KwOAeX1F8aVeR21juuZzK3EljFCtnplgQw3//5dIbeUcN/rVQ ufbQ== X-Gm-Message-State: AGRZ1gKorZSrIB7LtaDaaOInhv7W4Mm6hE61sv4KbSc7aN9MZBFxJnlH 72tFRXz10Mh1ajlFahKcsoy/WFDHQqbw7x8Qa5yfmPId X-Google-Smtp-Source: AJdET5daieGQMI5NVeXlcpovGJrjQdZCvJab47uUONA6lkraUbKSldC5vm6t7JiyyS2ZiiXPwAiKHAGqh9YMlm3giao= X-Received: by 2002:a24:eb0b:: with SMTP id h11-v6mr131158itj.47.1541179615594; Fri, 02 Nov 2018 10:26:55 -0700 (PDT) MIME-Version: 1.0 References: <1541178458.22340.242.camel@freebsd.org> In-Reply-To: <1541178458.22340.242.camel@freebsd.org> From: Warner Losh Date: Fri, 2 Nov 2018 11:26:44 -0600 Message-ID: Subject: Re: NANDFS -- Any current users? To: Ian Lepore Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2018 17:26:57 -0000 On Fri, Nov 2, 2018 at 11:07 AM Ian Lepore wrote: > On Fri, 2018-11-02 at 11:01 -0600, Warner Losh wrote: > > Are there any current users of NANDFS? > > This may be a good thing to ask in arm@ and mips@. Some old arm kernel > configs include it, because some of the *Plug line of armv5 systems > come with compatible nand parts on the board (but of course just having > it in the kernel doesn't mean anyone is actually using it). > I'll be polling there to. > We tried to use it at $work a few years ago, but it was too buggy to > deploy. Fixes have been done to it since then, but I/we never re-tested > because we had an alternate homebrew solution. > I had similar experience... My analysis is that it can't possibly work. It fails to abide by the vnode locking protocol, so the vnodes can be freed up out from under the routines that are trying to use them as a locking protocol for their data. This has remained unfixed since it was identified in the 10-current time frame. I'd wanted to use it since an append only filesystem is well suited to SSDs, but found that while the code worked OKish on the system when there was no load, but as soon as you started churning vnodes it would panic. nandfs_lookup, for example, drops the lock and relocks the vnode without refing it so it can disappear as soon as it unlock returns if there's no reference. There's other places where there's lock ordering issues with its use of the lock manager and the way it mixes with mtx_lock/unlock. These two issues are what made me give up on it since the quick, naive changes revealed the next layer of issues that I'm not recalling at the moment. Warner