Am Sonntag, 19. April 2015, 22:31:02 schrieb Craig Ringer: > 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.
You will loose the ability to snapshot that directory tree then. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- 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
