mirror of
https://github.com/versity/scoutfs.git
synced 2026-04-14 19:07:00 +00:00
e8f87ff90a
This will give us concurrency yet still allow our ioctls to drive cache syncing/invalidation on other nodes. Our lock_coverage() checks evolve to handle direct dlm modes, allowing us to verify correct usage of CW locks. As a test, we can run createmany on two nodes at the same time, each working in their own directory. The following commands were run on each node: $ mkdir /scoutfs/`uname -n` $ cd /scoutfs/`uname -n` $ /root/createmany -o ./file_$i 100000 Before this patch that test wouldn't finish in any reasonable amount of time and I would kill it after some number of hours. After this patch, we make swift progress through the test: [root@fstest3 fstest3.site]# /root/createmany -o ./file_$i 100000 - created 10000 (time 1509394646.11 total 0.31 last 0.31) - created 20000 (time 1509394646.38 total 0.59 last 0.28) - created 30000 (time 1509394646.81 total 1.01 last 0.43) - created 40000 (time 1509394647.31 total 1.51 last 0.50) - created 50000 (time 1509394647.82 total 2.02 last 0.51) - created 60000 (time 1509394648.40 total 2.60 last 0.58) - created 70000 (time 1509394649.06 total 3.26 last 0.66) - created 80000 (time 1509394649.72 total 3.93 last 0.66) - created 90000 (time 1509394650.36 total 4.56 last 0.64) total: 100000 creates in 35.02 seconds: 2855.80 creates/second [root@fstest4 fstest4.fstestnet]# /root/createmany -o ./file_$i 100000 - created 10000 (time 1509394647.35 total 0.75 last 0.75) - created 20000 (time 1509394647.89 total 1.28 last 0.54) - created 30000 (time 1509394648.46 total 1.86 last 0.58) - created 40000 (time 1509394648.96 total 2.35 last 0.49) - created 50000 (time 1509394649.51 total 2.90 last 0.55) - created 60000 (time 1509394650.07 total 3.46 last 0.56) - created 70000 (time 1509394650.79 total 4.19 last 0.72) - created 80000 (time 1509394681.26 total 34.66 last 30.47) - created 90000 (time 1509394681.63 total 35.03 last 0.37) total: 100000 creates in 35.50 seconds: 2816.76 creates/second Signed-off-by: Mark Fasheh <mfasheh@versity.com>