On 19 April 2015 at 22:28, Martin Steigerwald <mar...@lichtvoll.de> wrote: > Am Sonntag, 19. April 2015, 21:20:11 schrieb Craig Ringer: >> Hi all > > Hi Craig, > >> I'm looking into the advisability of running PostgreSQL on BTRFS, and >> after looking at the FAQ there's something I'm hoping you could >> clarify. >> >> The wiki FAQ says: >> >> "Btrfs does not force all dirty data to disk on every fsync or O_SYNC >> operation, fsync is designed to be fast." >> >> Is that wording intended narrowly, to contrast with ext3's nasty habit >> of flushing *all* dirty blocks for the entire file system whenever >> anyone calls fsync() ? Or is it intended broadly, to say that btrfs's >> fsync won't necessarily flush all data blocks (just metadata) ? >> >> Is that statement still true in recent BTRFS versions (3.18, etc)? > > I don´t know, thus leave that for others to answer. I always assumed a > strong fsync() guarentee as in "its on disk" with BTRFS. So I am > interested in that as well. > > But for databases, did you consider the copy on write fragmentation BTRFS > will give? Even with autodefrag, afaik it is not recommended to use it for > large databases on rotating media at least.
I did, and any testing would need to look at the efficacy of the chattr +C option on the database directory tree. PostgreSQL is its self copy-on-write (because of multi-version concurrency control), so it doesn't make much sense to have the FS doing another layer of COW. I'm curious as to whether +C has any effect on BTRFS's durability, too. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
