On 9.03.2018 21:05, Alex Adriaanse wrote: > Am I correct to understand that nodatacow doesn't really avoid CoW when > you're using snapshots? In a filesystem that's snapshotted
Yes, so nodatacow won't interfere with how snapshots operate. For more information on that topic check the following mailing list thread: https://www.spinics.net/lists/linux-btrfs/msg62715.html every 15 minutes, is there a difference between normal CoW and nodatacow when (in the case of Postgres) you update a small portion of a 1GB file many times per minute? Do you anticipate us seeing a benefit in stability and performance if we set nodatacow for the So regarding this, you can check : https://btrfs.wiki.kernel.org/index.php/Gotchas#Fragmentation Essentially every bit of small, random postgres update in the db file will cause a CoW operation + checksum IO which cause, and I quote, " thrashing on HDDs and excessive multi-second spikes of CPU load on systems with an SSD or large amount a RAM." So for OLTP workloads you definitely want nodatacow enabled, bear in mind this also disables crc checksumming, but your db engine should already have such functionality implemented in it. entire FS while retaining snapshots? Does nodatacow increase the chance of corruption in a database like Postgres, i.e. are writes still properly ordered/sync'ed when flushed to disk? Well most modern DB already implement some sort of a WAL, so the reliability responsibility is shifted on the db engine. -- 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
