From: Matthew Garrett Subject: Re: [PATCH, resend] relatime: Let relatime update atime at least once per day Date: Sun, 28 Dec 2008 21:38:52 +0000 Message-ID: <20081228213852.GA20439@srcf.ucam.org> References: <20081228152901.GB13565@srcf.ucam.org> <4957CDD2.9040903@tudelft.nl> <20081228195921.GB19176@srcf.ucam.org> <4957EEA7.3050101@tudelft.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org To: =?iso-8859-1?Q?=C9ric?= Piel Return-path: Received: from cavan.codon.org.uk ([93.93.128.6]:58545 "EHLO vavatch.codon.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756184AbYL1Vi4 (ORCPT ); Sun, 28 Dec 2008 16:38:56 -0500 Content-Disposition: inline In-Reply-To: <4957EEA7.3050101@tudelft.nl> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Sun, Dec 28, 2008 at 10:24:55PM +0100, =C9ric Piel wrote: > Of course, by construction, there is nothing relying on the current > relatime semantics. The problem is that whenever you are making relat= ime > closer to the atime behaviour, you are also getting closer to the > original drawbacks of atime (one read generates one write). If your io is sufficiently limited that one write per file per day is a= =20 significant problem, then I think there's a more serious underlying=20 problem. > Actually, you are changing relatime from a boolean condition (maximum > one additional write per write) to a atime with a coarse grain (maxim= um > one additional write per day). Today you found a use case that needs = a > precision of one day. Tomorrow, someone else will find a use case tha= t > needs a precision of one hour. So maybe what is actually needed is a > third option, a "grainatime" option where you can change the precisio= n > of the atime. The answer to "The current two options are suboptimal in almost all=20 cases" is very rarely "Add a new option". If boot is touching too many=20 files, it should stop touching as many files. If you have crap disks,=20 get better disks. If your life is spent tuning fs parameters for 1%=20 performance gains, find a better job. --=20 Matthew Garrett | mjg59@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html