Messages in this thread | | | Date | Sun, 5 Aug 2007 11:00:29 -0400 | From | Theodore Tso <> | Subject | Re: [PATCH 00/23] per device dirty throttling -v8 |
| |
On Sun, Aug 05, 2007 at 02:26:53AM +0200, Andi Kleen wrote: > I always thought the right solution would be to just sync atime only > very very lazily. This means if a inode is only dirty because of an > atime update put it on a "only write out when there is nothing to do > or the memory is really needed" list.
As I've mentioend earlier, the memory balancing issues that arise when we add an "atime dirty" bit scare me a little. It can be addressed, obviously, but at the cost of more code complexity.
An alternative is to simply have a tunable parameter, via either a mount option or stashed in the superblock which controls atime's granularity guarantee. That is, only update the atime if it is older than some set time that could be configurable as a mount option or in the superblock. Most of the time, an HSM system simply wants to know if a file has been used sometime "recently", where recently might be measured in hours or in days.
This is IMHO slightly better than relatime, since it keeps the spirit of the atime update, while keeping the performance impact to a very minimal (and tunable) level.
- Ted
P.S. Yet alternative is to specify noatime on an individual file/directory basis. We've had this capability for a *long* time, and if a distro were to set noatime for all files in certain hierarchies (i.e., /usr/include) and certain top-level directories (since the chattr +A flag is inherited), I think folks would find that this would reduce the I/O traffic of noatime by a huge amount. This also would be 100% POSIX compliant, since we are extending the filesystem and setting certain files to use it. But if users want to know when was the last time they looked at a particular file in their home directory, they would still have that facility.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |