Hi, As it turns out, running with low memory is a really easy way to shake out undesirable behavior in Btrfs. This can be especially bad when considering that a memory limit is really easy to hit in a container (e.g., by using cgroup memory.limit_in_bytes). Here's a simple script that can hit several problems: ---- #!/bin/sh cgcreate -g memory:enomem MEM=$((64 * 1024 * 1024)) echo $MEM > /sys/fs/cgroup/memory/enomem/memory.limit_in_bytes cgexec -g memory:enomem ~/xfstests/ltp/fsstress -p128 -n999999999 -d /mnt/test & trap "killall fsstress; exit 0" SIGINT SIGTERM while true; do cgexec -g memory:enomem python -c ' l = [] while True: l.append(0)' done ---- Ignoring for now the cases that drop the filesystem into read-only mode with relatively little fuss, here are a few patches that fix some of the low-hanging fruit. They apply to Linus' tree as of today. Thanks! Omar Sandoval (3): btrfs: handle ENOMEM in btrfs_alloc_tree_block btrfs: handle race on ENOMEM in alloc_extent_buffer btrfs: check io_ctl_prepare_pages return in __btrfs_write_out_cache fs/btrfs/extent-tree.c | 41 ++++++++++++++++++++++++++++------------- fs/btrfs/extent_io.c | 20 ++++++++++++++++---- fs/btrfs/free-space-cache.c | 10 ++++++---- 3 files changed, 50 insertions(+), 21 deletions(-) -- 2.3.0 -- 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
