Date: Sun, 18 Jan 2015 22:55:07 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= <trasz@freebsd.org> Cc: arch@freebsd.org Subject: Re: Access times on directories. Message-ID: <20150118221955.F60362@besplex.bde.org> In-Reply-To: <20150118103959.GA54396@brick.home> References: <20150118103959.GA54396@brick.home>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 18 Jan 2015, Edward Tomasz [utf-8] Napiera=C5~Ba wrote: > What is FreeBSD semantics for atime updates on directories? It does not > seem to be working. Is that by design? read(2) marks the atime for update in the usual way for directories on most or all file systems that support read(2) on directories. That is about the only time atimes are marked on directories. However, read(2) is rarely used for reading directories. Most directory reads are probably done by readdir(2), and it uses getdirentries(2). POSIX requires readdir() to mark the atime for update if an (uncached) directory entry is actually read. This seems to be quite broken. There is no code in either readdir() or getdirentries to waste time marking the atime. I think directory searches for the purpose of creating a new entry also don't update the atime, but this is not required by POSIX. > The reason I'm asking is because it would allow autounmountd(8) to actual= ly > unmount filesystems some specified time after last use, by checking atime > of filesystem's root, instead of just retrying unmount(2) until it succee= ds. That wouldn't be a robust test. It would be guaranteed to not work for the r/o mount case. I would like file systems to do this. Actually, to automatically sync everything and mark the file system as clean if there have been no writes to it for some time. ffs should do this per cylinder group (not so easy) in such a way that only the unclean cg's need to be fscked. atime updates would get in the way of this. A file system with atime updates enabled would rarely remain unwritten to for sufficiently long to be marked as clean unless it is not used at all. Bruce From owner-freebsd-arch@FreeBSD.ORG Mon Jan 19 11:03:59 2015 Return-Path: <owner-freebsd-arch@FreeBSD.ORG> Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7E5FBB12; Mon, 19 Jan 2015 11:03:59 +0000 (UTC) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (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 1A17AA76; Mon, 19 Jan 2015 11:03:59 +0000 (UTC) Received: by mail-wi0-f171.google.com with SMTP id l15so6365113wiw.4; Mon, 19 Jan 2015 03:03:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:mime-version:date:content-type:content-transfer-encoding :message-id:from:subject:to:cc:in-reply-to:references; bh=yooY94k7QoYhMmn8x05hn+sUbWy29tVUWma37teju7c=; b=UgXN93o1W2rBVbv7DFYQdFYfiuY3RFFfcecGP2nAtUlqdKB9fZHircRCWuMupel5dj Ww4KbEyKp/DeiKzEyVuKLCD2csbIff/dUqRnDO6EYYPhTl3dTogaF87TF/NyJYbGKlqi ofTaUBZ4PSjG9ExlqNoOVT1Qnac2lVlPGrSL2I81Nf/zzx+J6qDI/6cTuWARtOelxpLs U9nVWK4sCFw2/CwdAXC4o2vN2nMLY8AaE1U7DozbPBxwlEBGv6LrQ9Tt3l3d/ieY9yUk oBHcnT9Yeuev3Sv5Vs6RG9PVmj8VOjhjX4SykcpCNTyDeVb/4P+yieCu0sDxlitaKxIJ RHTQ== X-Received: by 10.180.74.146 with SMTP id t18mr33626803wiv.62.1421665437420; Mon, 19 Jan 2015 03:03:57 -0800 (PST) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id n3sm13768365wiw.5.2015.01.19.03.03.56 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Jan 2015 03:03:56 -0800 (PST) Sender: Baptiste Daroussin <baptiste.daroussin@gmail.com> Received: from mail.etoilebsd.net (localhost [IPv6:::1]); by ivaldir.etoilebsd.net (OpenSMTPD) with ESMTP id 8c06d551; Mon, 19 Jan 2015 12:03:55 +0100 (CET) Mime-Version: 1.0 Date: Mon, 19 Jan 2015 11:03:55 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-ID: <23213143eab742c5b090a07817240a72@mail.etoilebsd.net> X-Mailer: RainLoop/1.7.2.220 From: "Baptiste Daroussin" <bapt@freebsd.org> Subject: Re: futimens/utimensat (was: Re: Change default VFS timestamp precision?) To: "Jilles Tjoelker" <jilles@stack.nl>, "Garrett Wollman" <wollman@hergotha.csail.mit.edu> In-Reply-To: <20150103161306.GB46373@stack.nl> References: <20150103161306.GB46373@stack.nl> <201412161348.41219.jhb@freebsd.org> <77322.1418933100@critter.freebsd.dk> <77371.1418933642@critter.freebsd.dk> <7567696.mqJ3jgzJgL@ralph.baldwin.cx> <82135.1419010861@critter.freebsd.dk> <20141219194800.GA29107@stack.nl> <201412192012.sBJKC1rW086109@hergotha.csail.mit.edu> Cc: portmgr@freebsd.org, pluknet@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture <freebsd-arch.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arch>, <mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch/>; List-Post: <mailto:freebsd-arch@freebsd.org> List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>, <mailto:freebsd-arch-request@freebsd.org?subject=subscribe> X-List-Received-Date: Mon, 19 Jan 2015 11:03:59 -0000 January 3 2015 5:13 PM, "Jilles Tjoelker" <jilles@stack.nl> wrote: =0A> O= n Fri, Dec 19, 2014 at 03:12:01PM -0500, Garrett Wollman wrote:=0A> =0A>>= In article <20141219194800.GA29107@stack.nl>, jilles@stack.nl writes:=0A= >> =0A>>> Because there is no API to set timestamps with nanosecond resol= ution,=0A>>> and therefore a cp -p copy of a file will appear older than = the original=0A>>> with 99.9% probability. I think that is undesirable.= =0A>> =0A>> But that's something we can easily fix -- and should have don= e, years=0A>> ago. Why don't we just *do* that?=0A>> =0A>> Of course, in = the case of NFS clients, where this issue is most=0A>> severe, the RPCs a= re already defined. The underlying VOP_SETATTR has=0A>> no trouble with n= anoseconds, either. It's just a matter of providing=0A>> a standard libra= ry interface (and associated system call(s)) to do it,=0A>> and since Lin= ux has already implemented this, we can just implement=0A>> that interfac= e and applications will get it "for free".=0A> =0A> OK, I dusted off the = old patch from pluknet@ and added many necessary=0A> things.=0A> =0A> Ple= ase review at https://reviews.freebsd.org/D1426=0A>; =0A> I added a compat= ibility wrapper, mainly to save portmgr some work. Of=0A> course, this do= es not add to the old kernel a version of lutimes() that=0A> works relati= ve to a file descriptor.=0A> =0A> I also have changes for cp, mv and more= utilities, but that's a=0A> different patch. There is also contrib code = that either only supports=0A> old calls or is explicitly configured to us= e only old calls.=0A> =0A=0AWhen you have the final version of the patch = and willing to commit please send portmgr a heads up.=0AFYI committing Th= ursday such patches is a good idea as it gives portmgr almost a week to u= pgrade the builders :)=0A=0ABest regards,=0ABapt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150118221955.F60362>