Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for December 5, 2013
Deadline scheduling: coming soon?
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
The problem is that FS transactions usually wait two or three times as we collect the file data, log blocks, and commit blocks. The atomics can bring it down to just one.
LCJ: Atomic I/O operations
Posted Jun 1, 2013 13:52 UTC (Sat) by butlerm (subscriber, #13312)
The point about write barriers is that if implemented properly filesystem activity could proceed with zero waits. The only thing necessary is if a write fails subsequent queued writes must fail as well. Data blocks, barrier, log blocks, barrier, commit block, barrier, and so on. The latency could be arbitrarily high with zero effect on throughput.
Posted Jun 1, 2013 23:41 UTC (Sat) by giraffedata (subscriber, #1954)
Posted Jun 2, 2013 0:13 UTC (Sun) by butlerm (subscriber, #13312)
Posted Jun 2, 2013 1:08 UTC (Sun) by masoncl (subscriber, #47138)
For fsync, O_DIRECT etc, you need to wait because we're not just promising a consistent FS, we're also promising a given thing will really be there after a crash.
Posted Jun 2, 2013 21:44 UTC (Sun) by butlerm (subscriber, #13312)
Posted Jun 3, 2013 14:20 UTC (Mon) by foom (subscriber, #14868)
If there was some other way to express a required ordering of writes to the kernel than fsync, many uses of fsync could be eliminated.
Posted Jun 6, 2013 17:05 UTC (Thu) by sanxiyn (guest, #44599)
Posted Jun 6, 2013 21:13 UTC (Thu) by kleptog (subscriber, #1183)
... do my filesystem calls ...
based on the idea that it's easy to understand and hard to screw up.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds