[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20081228213852.GA20439@srcf.ucam.org>
Date: Sun, 28 Dec 2008 21:38:52 +0000
From: Matthew Garrett <mjg59@...f.ucam.org>
To: Éric Piel <E.A.B.Piel@...elft.nl>
Cc: linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH, resend] relatime: Let relatime update atime at least once per day
On Sun, Dec 28, 2008 at 10:24:55PM +0100, Éric Piel wrote:
> Of course, by construction, there is nothing relying on the current
> relatime semantics. The problem is that whenever you are making relatime
> 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
significant problem, then I think there's a more serious underlying
problem.
> Actually, you are changing relatime from a boolean condition (maximum
> one additional write per write) to a atime with a coarse grain (maximum
> 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 that
> needs a precision of one hour. So maybe what is actually needed is a
> third option, a "grainatime" option where you can change the precision
> of the atime.
The answer to "The current two options are suboptimal in almost all
cases" is very rarely "Add a new option". If boot is touching too many
files, it should stop touching as many files. If you have crap disks,
get better disks. If your life is spent tuning fs parameters for 1%
performance gains, find a better job.
--
Matthew Garrett | mjg59@...f.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists