On Thu, Jul 13, 2017 at 8:24 PM, Sargun Dhillon <sargun@xxxxxxxxx> wrote: > We've been running Btrfs with Docker at appreciable scale for a few > months now (100-200k containers / day ). Is this on a single Btrfs file system? Or is it distributed among multiple Btrfs file systems? I'm curious how many containers or more specifically how many snapshots you've typically accumulated before doing cleanups (deleting containers and their snapshots). > Since containers are ephemeral, they really shouldn't fsync. One of > the biggest (recent) problems has been workloads that use O_SYNC, or > sync after a large number of operations -- this stalls out all of the > containers (subvolumes) on the machine because the transaction lock is > under hold. This, in turn, manifests itself in soft lockups, and > operational trouble. Our plan to work around it is patch the VFS > layer, and stub out sync for certain cgroups. This could even be useful for out of band OS updates. That use case is a much smaller scale, so it's not such a big problem. But I see heavy fsyncing for OS/application updates in the RPM world, and it's just not necessary if the update is happening on its own tree. If there's a problem with the update, just blow away the partially updated snapshot and start over. The fsyncing throughout gains nothing but slow downs. -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
