From nobody Fri Jun 23 01:03:14 2023 X-Original-To: fs@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 4QnJrf540yz4h9JC for ; Fri, 23 Jun 2023 01:03:14 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QnJrf3zvxz3v7L for ; Fri, 23 Jun 2023 01:03:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1687482194; 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: in-reply-to:in-reply-to:references:references; bh=PwmW2TMsEoRgE1aSiEAgu7xDhEs230MoU5dxsefTqOA=; b=WMjBBy/62aReQv9tBF9c+2pHltK6ECTiLRWwEQ2o2qfMjuhsFXwfesQQazBhi9V3GoiiGW eXfzDWQBhZsMZ404TSQV/c55b/YXd34Y3GbgS+m1efrijZ74ypuAecLNNCVijw2nT0xcqK Z7FNNguRwdJHuHHuvUh6X0Y8YK61hLeRdawmpNuttnP0gHQN4kgFUs7dKnwxiKvLsk/9ZL ziSZPOXKqZpTDWzRya6W6TnGHYshcb80KZHylOiKc0ROP1d4pBgTsIVvHdiKJgAayaXOjb jSRm1G3zuK7Ym5BlpfMdbC8ypOxLGR6cgrNBmrTNruRoZonLW5uMgGQozsbV2w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1687482194; a=rsa-sha256; cv=none; b=hMnDRuvG9vNQYMEog8/25+i1T2LxCQee5P+5Yb+wkryDWxYlNSZtKB64wkWNFBHTaV/WIP Ld44dk/m+ICfTOqi2VbwBZuxPymLpejUmLvZ2qK4tkPv0HN17pPGoGExwzWedESuoRawXz 6TsOTPYzhg1UmVembVWyT4ESlJoKj6AqzT/cdcE3Zzz78bxrefntMP6mvO//qB5TsLAcnp vKWByRe+ai98T/IXsLNTREnIE/w7yzpTG6B1pHDGktDApg9FKi+b89jEfKPuFIm+NtSJce w+AzE2ymYM6l/X2vSbGxIUzNUA9VtlR7jfTjC7NPF9P0SFmPkLuAXJCGIacHXQ== 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 4QnJrf34Kmzl2Q for ; Fri, 23 Jun 2023 01:03:14 +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 35N13EJN049095 for ; Fri, 23 Jun 2023 01:03:14 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 35N13Epl049094 for fs@FreeBSD.org; Fri, 23 Jun 2023 01:03:14 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: fs@FreeBSD.org Subject: [Bug 271925] chflags(1) fails to remove uarch flag with hardlinked files (ZFS) Date: Fri, 23 Jun 2023 01:03:14 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: jamie@catflap.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271925 --- Comment #5 from Jamie Landeg-Jones --- (In reply to Stefan E=C3=9Fer from comment #1) TThanks for the quick response! Apologies for the late reply, I haven't been at home for the last 2 weeks, = so online time is more sporadic. The problem with /bin/chflags is more generic - it's just that this ZFS qui= rk highlighted the difference. The more general case is that whilst /bin/chfla= gs will not modify a file if the modification isn't needed, the logic fails wh= en files are hardlinked... Though fixing this may be not worth the effort, it's just pedantry at the end of the day, and might even be considered "correct" behaviour - i.e. "if a file is hardlinked then expect it to be accessed for each link found." Anyway, if it was fixed, I think filtering out duplicate inodes would be the cleanest and most efficient solution. For example, (and I forgot to mention in my post, sorry) I did a quick chflags(2) syscall wrapper code to set the flags on a file to 0: #include #include #include #include #include #include int main (int argc, char **argv) { while (*++argv !=3D NULL) if (lchflags (*argv, 0) =3D=3D -1) warnx("%s: %s", *argv, strerror (errno)); } On tmpfs, UFS, and ZFS,touching a test file, and setting some flags, then running the above program resets the flags, and updates ctime, as expected. On all three filesystems, running it again always updates the ctime on all 3 filesystems, but on ZFS it switches on uarch. Running it again switches off uarch. Using /bin/chflags, on all three filesystems, running it again doesn't upda= te the ctime, or on ZFS, toggle the uarch. So the consensus seems to be "chflags(2)" updates regardless, whilst /bin/chflags will stat the file and only make the chflags(2) call if necess= ary (of course, this gets tripped up in the hardlinked case mentioned in this b= ug report) > This seems to be caused by ZFS collecting multiple flag updates and by ef= fectively mapping the setting of flags to toggling of flags. I don't think it's that - try the above test program - whilst filesystems h= ave the logic "any change updates the ctime", ZFS has the additional "any change other than one that unsets uarch will also set uarch" - this seems to break down because when you attempt to remove uarch on a file that doesn't have u= arch set, this fails the "we are removing uarch" logic. This, I suspect, should = be fixed in ZFS. > but I guess that the second call sees that the new attributes are identi= cal to the (already altered) current attributes of the file and then marks = it to not need a vnode update on stable storage. I think it's the other way around. The chflags system call (and therefore Z= FS) run the code even if the attributes are identical. /bin/chflags doesn't run the call if the new attributes are identical, but = this logic fails if a file is hardlinked, because the initial stat shows "both" = need to be updated, There are also consistencies in chmod(1) - chmod on ZFS causes an update ev= en if no actual chmod takes place - i haven't looked more closely at this, but this opens up a whole can of worms. I guess the first question should be "If any metdata change is attempted on= a file that doesn't actually result in the data being changed (because it's "changing" it to the value it already has) then whose responsibility is it = to not attempt the change, and consequently update ctime? Is it userland, or is it the syscall, or is it the filesystem code itself? Cheers, Jamie --=20 You are receiving this mail because: You are the assignee for the bug.=