Not logged in
Log in now
Create an account
Subscribe to LWN
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
Atime and btrfs: a bad combination?
Posted Jun 2, 2012 7:49 UTC (Sat) by liljencrantz (subscriber, #28458)
As such, I think it's extremely sad to see that relatively modern software, like popcon, is *still* being written that makes the misguided mistake of using this feature.
Posted Jun 3, 2012 10:19 UTC (Sun) by ballombe (subscriber, #9523)
Posted Jun 3, 2012 11:00 UTC (Sun) by liljencrantz (subscriber, #28458)
Posted Jun 3, 2012 14:57 UTC (Sun) by Yorick (subscriber, #19241)
We see this every time a sensible proposal comes forth to dump an old misfeature that causes way more grief than enjoyment. Control characters in file names, for example...
Posted Jun 3, 2012 19:48 UTC (Sun) by nybble41 (subscriber, #55106)
The downside, of course, would be that some daemon would have to run in the background to collect the audit data. However, that could still involve less overhead than updating atimes on every filesystem read.
Posted Jun 5, 2012 9:31 UTC (Tue) by zack (subscriber, #7062)
The "converting reads into write" argument is very nice (and lyric), but it's not particularly compelling. atime is not changing the intrinsic nature of reads. atime is a logging/accounting mechanism like many others that an OS kernel implements. It is in the nature of accounting to consume space and that happens (inevitably) also when you log actions that, per se, wouldn't have consumed any space. I don't see any inherent flaw in that, it is "just" a matter of difficult trade-offs about where to store the information and how to minimize their size when space is tight.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds