From owner-freebsd-fs@freebsd.org Thu Jun 4 21:24:38 2020 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9FE8E332969 for ; Thu, 4 Jun 2020 21:24:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49dJh55267z40PC for ; Thu, 4 Jun 2020 21:24:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x730.google.com with SMTP id w3so7740987qkb.6 for ; Thu, 04 Jun 2020 14:24:37 -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=2OGwHfORPv2p1+dWb6AKCxdesrv03fX00+ruHk64Haw=; b=UIudO9tF45G6FFvYy416E2wkRSft997CQQqolrYJWDQ4Xp9N5zvCCSi38+0HpsP3aE j+j4aGZbVwtG01GqXb9z5rShbMoW3zlv49m+zbz6TbjkP9PT2b/CqsBjWPjIxzZzNx8w sJJxLneSFgPM9TxyF4IHPrqNutSzWr4+6OM0E4Dlo3h+wVSIW630lTmuRxcFhmuBJODL Rv1n/UZMmyf+eMgo/UK8HSYTkWgmlEGYNVJZuqSap9UwjX7HIasEEuyTLbUo8PNRKlki +W+x191tVPIiqGWDctYz2V2AK7dwVrrgdxrQmiWUn0TFkKlmjCMbkDQrqmPoH1rWf5ZI ++lw== 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=2OGwHfORPv2p1+dWb6AKCxdesrv03fX00+ruHk64Haw=; b=ANmEVC/C4wKL9dbbdmfbi+zJH4uFnyW36hj0KHmJ7eYAHiJeFoZP4stzhmWhlftVo2 XUl7kfV7cSNa6myQOfh3p/NbETCSMWlkZ/ugUTbNW9lZYqd0RSf2xqqhclQOtnpnaxiO dtpoibtWPXK1ODRJb7olbxN93LoQuQ528wEOUMMVzvMNDRcnSrwipl6UAnUFE7FZSYQe FK/p0r3t4NozHJGKv4n/mqzbMqS7uuUIGJINqpaRqfG9vyuPwb0gLeF2qXgayU8JgINX 7vStDMOQlJP33cshlZijZ9rVJhQ9h6SzHLWAWsXI3wbMF4gpARJYxi+fSI5H8isWBB6z qFiQ== X-Gm-Message-State: AOAM531AS5ZlXK8QxXHk4vnO9lbsoHlQWu61MbIP0WqAznMsQeb2sbdv esK2uCl61dGhSikAb/2849jZIHGFvt+87lfeNuJsP3YV X-Google-Smtp-Source: ABdhPJxeJ2y2i7PnUicf/TPZ7rHOoAHE6+VTWC5YXUZLkhgBzm4vnFfDHLBMtb3IHUj/KKr3J838uYsjHCcT9QV+66Q= X-Received: by 2002:a37:5c47:: with SMTP id q68mr6595935qkb.495.1591305876681; Thu, 04 Jun 2020 14:24:36 -0700 (PDT) MIME-Version: 1.0 References: <1d05302e-db7f-2538-16ee-dcd73c229e37@national.shitposting.agency> <8e221643-965c-3cbb-a043-4eed786c01e3@protonmail.com> In-Reply-To: From: Warner Losh Date: Thu, 4 Jun 2020 15:24:25 -0600 Message-ID: Subject: Re: newfs(1) on a file To: goatshit54108@national.shitposting.agency Cc: FreeBSD FS X-Rspamd-Queue-Id: 49dJh55267z40PC X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=UIudO9tF; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::730) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.01 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.01)[-1.010]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.00)[0.004]; NEURAL_HAM_LONG(-1.00)[-1.001]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::730:from]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 21:24:38 -0000 On Thu, Jun 4, 2020 at 3:14 PM wrote: > On 6/4/20 5:04 PM, Nazim Can Bedir via freebsd-fs wrote: > > in order to include efficient and proper caching of disk > > blocks into the equation, damn filesystem backing stores need to be > > exist as devices. > > I find that hard to believe, at least with that exact wording. An > alternative "Sorry, but all current FreeBSD-kernel filesystem-code is > designed only with underlying block devices in mind, so some work is needed > to handle other cases." sounds acceptable. > > The caching strategy mainly depends on the filesystem type, its > implementation, and the settings. For some "filesystems", such as swap > spaces, caching is specifically to be avoided. > > Linux is able to perform `swapon ./file`, FreeBSD isn't. > echp | dd oseek=10000 count=1 of=fred swapon /dev/$(mdconfig -f fred) Does the trick. > > if mount command couldn't mount a GAY filesystem from the file > > as-is, then newfs(8) command shouldn't allow to create filesystem on > > file as-is (otherwise, idiot FreeBSD users like me could think that > > "aah, if newfs initialises filesystem on file without md, then it must > > be able to mount without md). > > But newfs *is* able to create a filesystem on a regular file. > It's a bug, born from a long legacy of needing the information in the disklabel in the past. That requirement has passed... > > I really don't understand what is the damn problem here? Filesystem > > operations are performed on special files (a.k.a disks); and md kernel > > driver does exist for that purpose. > > Again, I don't like this way of thinking. First, it goes again the Unix > philosophy. Second, there is a clear separation between (a) creating, > attempting to repair or debugging an instance of a filesystem, and (b) > mounting a filesystem, thus connecting it to the kernel's filesystem-system > -- a highly flammable area --, which practically assumes that the instance > is well-formatted, and demands exclusive write access. > I agree. makefs is what's usually used since it lets you layer in a tree as well. newfs on a file, by itself, isn't so useful, so this has remained broken... Warner