Atime and btrfs: a bad combination?

Posted Jun 1, 2012 18:48 UTC (Fri) by Yorick (guest, #19241)
In reply to: Atime and btrfs: a bad combination? by jzbiciak
Parent article: Atime and btrfs: a bad combination?

Your suggestions sound eminently sensible to me, although I would settle for the first item and call it a day. More fundamentally, the article author seems to think that it is a problem that atime is slow on btrfs. Quite the contrary: it is excellent news, especially since it seems to be caused by the basic btrfs design principles (so it is hard to "fix").

In fact, once most people agree that there is no reason whatsoever not to mount everything with noatime, we can drop it altogether and start reaping the benefits. All operations are faster, the code becomes simpler, and we can put the now free space in inodes (both on disk and in memory) to more productive use. It is difficult to see any costs here—what would break? finger?

Then, once that has been taken care of, we can go on dealing with some other part of the baroque Unix legacy. Remove 99 % of the TTY options, perhaps? We can start slowly, by taking away the one that converts lower to upper case, and see if anyone notices.

Atime and btrfs: a bad combination?

Posted Jun 1, 2012 21:40 UTC (Fri) by jzbiciak (guest, #5246) [Link]

<stty olcuc>

WE CAN START SLOWLY, BY TAKING AWAY THE ONE THAT CONVERTS LOWER TO UPPER CASE, AND SEE IF ANYONE NOTICES.

I'M SURE ANYONE WHO MIGHT COMPLAIN WILL DO SO VERY LOUDLY.

<STTY -OLCUC>

Atime and btrfs: a bad combination?

Posted Jun 4, 2012 12:59 UTC (Mon) by nix (subscriber, #2304) [Link] (2 responses)

And with every change you lose a bit of your userbase. Before you know it you end up with not very much userbase left at all.

Atime and btrfs: a bad combination?

Posted Jun 4, 2012 14:50 UTC (Mon) by hummassa (subscriber, #307) [Link]

You made me smile.

One of our problems as developers is exactly that: one does not simply take features away. Lots of systems made me bury them exactly by trying to take "my" features (the ones I used and cared for and needed) away.

Atime and btrfs: a bad combination?

Posted Jun 5, 2012 12:19 UTC (Tue) by Yorick (guest, #19241) [Link]

I'm going to assume you mean atime specifically, and not olcuc or anything else (you would have a hard time arguing for that one).

To remove old cruft, a good start is quarantine. Simply don't implement atime in new file systems (btrfs); people who need it for their business-critical fingerd can run UFS or ext2 or something else. The important part is that we don't let use of a bad feature to spread, since that is only going to make it harder to get rid of.

Instead of making code worse for everyone for the (dubious) benefit of a vocal minority of cavemen, deal with the problem head-on. Give them a chance to adapt - help them all you can - but set a firm date for when the coddling stops.