User: Password:
|
|
Subscribe / Log in / New account

Dirty pages, faster writing and fsync

Dirty pages, faster writing and fsync

Posted Apr 4, 2014 19:00 UTC (Fri) by dlang (subscriber, #313)
In reply to: Dirty pages, faster writing and fsync by etienne
Parent article: PostgreSQL pain points

that would only extend the data to be synced to the directory data. but on ext3 fsync() isn't finished until it writes out all dirty data for all files in all directories.


(Log in to post comments)

Dirty pages, faster writing and fsync

Posted Apr 7, 2014 11:13 UTC (Mon) by etienne (guest, #25256) [Link]

You want to sync the directory data, but also the parent directory recursively (because directory data may have moved on disk, maybe because now it is bigger).
If you sync a directory data, you would better sync its children to not have invalid metadata on disk and a non bootable system after a crash.
Then, for the general case, you may want to sync the directory data of any other link to this file.
So you want the "fsync algorithm" to know if it is syncing data or metadata.
You can also change the meaning of fsync() to sync only in the filesystem journal, assuming you will replay the journal before trying to read that file after a crash (hope you did not fsync("vmlinuz"), no bootloader will replay the journal at that time).

Dirty pages, faster writing and fsync

Posted Apr 7, 2014 19:01 UTC (Mon) by dlang (subscriber, #313) [Link]

we can argue over the details all week, I'm not an expert here.

But the fact is that every filesystem except ext3 is able to do a fsync without syncing all pending data on the filesystem, and this has been acknowledged as a significant problem by the ext developers. They made sure that ext4 did not suffer the same problem.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds