From nobody Sat Jul 20 09:08:48 2024 X-Original-To: bugs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WR11Y1VmLz5RJCl for ; Sat, 20 Jul 2024 09:08:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WR11X4Qykz4jRM for ; Sat, 20 Jul 2024 09:08:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1721466528; a=rsa-sha256; cv=none; b=vMeKVzB/HpIh7/1Iv7nolEnAUWfQVtO7s/Emxwpbpdi4ibHW5LiTiUYPsaRDF5CADJw5va jYzmiwWhQaVIGYdOvAtGFga0qAjurkXy5rnFxGtlI7zVtMjG6gn8mL6L1E0C3YfRCI3GQF oeModJFMF6qRaKpc3OOZotRxVaHLnYLlWEqkHHLgIzyNHBhAijYxzofszLsH8SkRFmeWDf etfEdlL/gdmAy7NNuaMsq8USaaY1dg0aSBQxcQ/BpiVNqP9TrZylKtk2Qt66E+cERQBbj+ JwbIqj1nE8ziJC/N+PY9d7uCT99dpGjfdZUyF8TJMJHQocHAZWj8nBdYCUP3Xg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1721466528; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=o+YO70umueiqnAbRkRESMms2iWRAqTi1XJNQuA7XiVk=; b=M8C9jvlBy/rAujZgLH7XGPRONG68R1LY+Xdw+vz0zQYdd/J9AljeBcA10coqH4ZjQS7V5+ 0iXOy6v8NSHd4UZjTsZtNNnaCNWcFXUi1ST6J0LcKej01uBxcKTaKOyW9hP9+k4XVR6uAR o90m7S6dcx8EZ6z5AIIZFKOCW57tLc96BAXzOuxMRAgFsEP+JBC+H3WyI/OgIG9Frt1oW2 xtCjvm/v+lYYo2lHiBkI8dJQWtXQBqhuceyLcIj3XWAflwLzYy4FzzYRswcFE30+B6luNc JK+pIHt1LRc8BpJSAx6JvZt9AElsCoMkb66A10rmagfZYBldPgRzKWXKm79OQw== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4WR11X3pYVz198J for ; Sat, 20 Jul 2024 09:08:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 46K98mOd031659 for ; Sat, 20 Jul 2024 09:08:48 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 46K98mJJ031657 for bugs@FreeBSD.org; Sat, 20 Jul 2024 09:08:48 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 280383] Removing the last link to an open file prevents remounting read-only--suggest document and/or code change Date: Sat, 20 Jul 2024 09:08:48 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: Unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: billblake2018@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-bugs@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D280383 Bug ID: 280383 Summary: Removing the last link to an open file prevents remounting read-only--suggest document and/or code change Product: Base System Version: Unspecified Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: billblake2018@gmail.com Long ago, an issue was resolved in which removing the last link to an open = file followed by downgrading the file system to read-only could have unfortunate consequences, by forbidding a downgrade when any open file had no links. (https://svnweb.freebsd.org/base?view=3Drevision&revision=3D89384) This was reasonable because closing the file would require deallocating the file's i= node and disk blocks, which could no longer be done if the file system was downgraded. I got bit by this because, if this is documented at all, it is not document= ed in any obvious place. E.g., the mount(8) man page gives no clue that you c= an't do this; it only says, in the documentation for the -u option, that it will fail if any file is opened for write. mount(2) is similarly silent. A minimal improvement would be a document change to mount(8) so that the -u option indicates that one may not downgrade a file system if there are any = open files with no links. In addition, mount(2) should say that one can get EBU= SY from such an attempt. But I thought about this for awhile and realized that this is a problem wit= h a relatively simple solution. It basically needs a directory with a specific name in a specific place and a single flag bit in an on-disk inode and in t= he corresponding vnode. Let's call this directory .lastlink and put it in the root of a mounted file system. Then one can make the following changes: 1) When the last link to an open file is to be removed: Choose a file name, say, "#" (as with lost+found). If the .lastlink directory exists and .lastlink/# does not exist, link .lastlink/# to the open file a= nd flag the inode and its vnode before the (no longer) last link is removed. 2) When an open file with a flagged vnode is closed, unlink .lastlink/# if the file system is read/write. 3) Leave the current downgrade code alone, except possibly adding a comment. 4) When a file system is (re)mounted r/w, scan .lastlink, if it exists, for links to any flagged inodes and unlink those files if they are not open. 5) Make fsck know about .lastlink so that it can remove any flagged inodes. With these changes, if no directory .lastlink exists, the current behavior = is preserved. But if that directory exists and nobody creates problematic file names in it, open, unlinked files never exist and so can't prevent downgrad= ing the file system. If a downgrade does happen, the deletion that should have happened when the file was closed does actually happen, but only when the f= ile system is next mounted r/w. If something other than the above code creates= a # file in .lastlink, the worst that'll happen is that the system reverts to prior behavior if an inode whose matches has its last link removed while it is open. --=20 You are receiving this mail because: You are the assignee for the bug.=