4c468fd7485: +7.8% blogbench.write_score, -5.1% turbostat.Pkg_W
Hi Chris,
FYI, we noticed increased performance and reduced power consumption on
commit 4c468fd74859d901c0b78b42bef189295e00d74f ("btrfs: disable strict file flushes for renames and truncates")
test case: lkp-sb02/blogbench/1HDD-btrfs
0954d74f8f37a47 4c468fd74859d901c0b78b42b
--------------- -------------------------
1094 ± 1% +7.8% 1180 ± 2% TOTAL blogbench.write_score
1396 ±19% -100.0% 0 ± 0% TOTAL slabinfo.btrfs_delalloc_work.active_objs
1497 ±17% -100.0% 0 ± 0% TOTAL slabinfo.btrfs_delalloc_work.num_objs
426 ±45% -100.0% 0 ± 0% TOTAL proc-vmstat.nr_vmscan_write
1.02 ±38% +193.1% 2.99 ±37% TOTAL turbostat.%pc6
0.12 ±48% +113.8% 0.25 ±29% TOTAL turbostat.%pc3
0.38 ±18% +117.7% 0.84 ±34% TOTAL turbostat.%pc2
19377 ±14% -50.9% 9520 ±20% TOTAL proc-vmstat.workingset_refault
44 ±41% +68.8% 75 ±28% TOTAL cpuidle.POLL.usage
31549 ± 1% +95.7% 61732 ± 1% TOTAL softirqs.BLOCK
4547 ±10% -38.3% 2804 ± 9% TOTAL slabinfo.btrfs_ordered_extent.active_objs
4628 ±10% -37.1% 2913 ± 9% TOTAL slabinfo.btrfs_ordered_extent.num_objs
17597 ± 8% -30.2% 12291 ±14% TOTAL proc-vmstat.nr_writeback
70335 ± 8% -30.1% 49174 ±14% TOTAL meminfo.Writeback
3606 ± 6% -29.1% 2556 ±10% TOTAL slabinfo.mnt_cache.active_objs
14763 ±12% -29.9% 10350 ± 8% TOTAL proc-vmstat.nr_dirty
3766 ± 5% -27.8% 2720 ±10% TOTAL slabinfo.mnt_cache.num_objs
3509 ± 6% -28.5% 2510 ±11% TOTAL slabinfo.kmalloc-4096.active_objs
59201 ±11% -30.1% 41396 ± 8% TOTAL meminfo.Dirty
479 ±13% -30.5% 333 ±10% TOTAL slabinfo.kmalloc-4096.num_slabs
479 ±13% -30.5% 333 ±10% TOTAL slabinfo.kmalloc-4096.active_slabs
3636 ± 6% -26.6% 2669 ±10% TOTAL slabinfo.kmalloc-4096.num_objs
6040 ± 8% -28.6% 4314 ± 6% TOTAL slabinfo.kmalloc-96.num_objs
5358 ± 5% -25.1% 4011 ± 7% TOTAL slabinfo.kmalloc-96.active_objs
757208 ± 4% -22.1% 589874 ± 4% TOTAL meminfo.MemFree
189508 ± 4% -22.2% 147518 ± 4% TOTAL proc-vmstat.nr_free_pages
762781 ± 4% -21.1% 601525 ± 4% TOTAL vmstat.memory.free
10491 ± 2% -16.8% 8725 ± 2% TOTAL slabinfo.kmalloc-64.num_objs
2513 ± 4% +16.3% 2923 ± 4% TOTAL slabinfo.kmalloc-128.active_objs
9768 ± 3% -15.1% 8298 ± 1% TOTAL slabinfo.kmalloc-64.active_objs
2627 ± 4% +14.0% 2995 ± 4% TOTAL slabinfo.kmalloc-128.num_objs
96242 ± 2% +15.5% 111120 ± 2% TOTAL slabinfo.btrfs_path.active_objs
3448 ± 2% +15.1% 3968 ± 2% TOTAL slabinfo.btrfs_path.num_slabs
3448 ± 2% +15.1% 3968 ± 2% TOTAL slabinfo.btrfs_path.active_slabs
96580 ± 2% +15.1% 111132 ± 2% TOTAL slabinfo.btrfs_path.num_objs
2526 ± 2% +13.5% 2867 ± 1% TOTAL slabinfo.btrfs_extent_state.num_slabs
2526 ± 2% +13.5% 2867 ± 1% TOTAL slabinfo.btrfs_extent_state.active_slabs
106133 ± 2% +13.5% 120434 ± 1% TOTAL slabinfo.btrfs_extent_state.num_objs
104326 ± 2% +12.3% 117189 ± 1% TOTAL slabinfo.btrfs_extent_state.active_objs
110759 ± 2% +13.4% 125640 ± 2% TOTAL slabinfo.btrfs_inode.active_objs
110759 ± 2% +13.4% 125642 ± 2% TOTAL slabinfo.btrfs_delayed_node.active_objs
4261 ± 2% +13.4% 4832 ± 2% TOTAL slabinfo.btrfs_delayed_node.num_slabs
4261 ± 2% +13.4% 4832 ± 2% TOTAL slabinfo.btrfs_delayed_node.active_slabs
110797 ± 2% +13.4% 125663 ± 2% TOTAL slabinfo.btrfs_delayed_node.num_objs
110815 ± 2% +13.4% 125669 ± 2% TOTAL slabinfo.btrfs_inode.num_objs
6926 ± 2% +13.4% 7853 ± 2% TOTAL slabinfo.btrfs_inode.num_slabs
6926 ± 2% +13.4% 7853 ± 2% TOTAL slabinfo.btrfs_inode.active_slabs
5607 ± 3% -11.0% 4991 ± 3% TOTAL slabinfo.kmalloc-256.active_objs
6077 ± 2% -9.9% 5476 ± 3% TOTAL slabinfo.kmalloc-256.num_objs
11153 ± 1% -7.7% 10295 ± 2% TOTAL proc-vmstat.nr_slab_unreclaimable
547824 ± 3% +16.5% 638368 ± 8% TOTAL meminfo.Inactive(file)
112124 ± 2% +11.6% 125105 ± 2% TOTAL slabinfo.radix_tree_node.active_objs
112169 ± 2% +11.6% 125134 ± 2% TOTAL slabinfo.radix_tree_node.num_objs
4005 ± 2% +11.6% 4468 ± 2% TOTAL slabinfo.radix_tree_node.num_slabs
4005 ± 2% +11.6% 4468 ± 2% TOTAL slabinfo.radix_tree_node.active_slabs
551119 ± 3% +16.4% 641663 ± 8% TOTAL meminfo.Inactive
285596 ± 2% +11.4% 318160 ± 2% TOTAL meminfo.SReclaimable
156 ± 3% +118.0% 340 ± 2% TOTAL iostat.sda.w/s
282 ± 3% -43.2% 160 ± 3% TOTAL iostat.sda.avgrq-sz
1.45 ±12% -28.9% 1.03 ±18% TOTAL iostat.sda.rrqm/s
633 ± 2% -26.5% 465 ± 2% TOTAL iostat.sda.wrqm/s
154423 ± 5% +17.4% 181309 ± 3% TOTAL time.voluntary_context_switches
536 ± 5% -11.5% 474 ± 9% TOTAL iostat.sda.await
102.71 ± 5% +10.4% 113.36 ± 6% TOTAL iostat.sda.avgqu-sz
20842 ± 2% -6.5% 19493 ± 2% TOTAL iostat.sda.wkB/s
20856 ± 2% -6.4% 19525 ± 2% TOTAL vmstat.io.bo
75.48 ± 4% -6.9% 70.27 ± 5% TOTAL turbostat.%c0
285 ± 4% -6.6% 266 ± 5% TOTAL time.percent_of_cpu_this_job_got
34.58 ± 2% -5.5% 32.68 ± 3% TOTAL turbostat.Cor_W
39.86 ± 2% -5.1% 37.82 ± 3% TOTAL turbostat.Pkg_W
5805 ± 1% -4.3% 5558 ± 3% TOTAL vmstat.system.in
10069454 ± 1% +6.3% 10699830 ± 1% TOTAL time.file_system_outputsDisclaimer:
Results have been estimated based on internal Intel analysis and are provided for informational purposes only. Any difference in system hardware or software design or configuration may affect actual performance.
Thanks,
Fengguang
echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor echo performance > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor echo performance > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor mkfs -t btrfs /dev/sda2
mount -t btrfs /dev/sda2 /fs/sda2
./blogbench -d /fs/sda2
A message that is not in the archive (sent off-list or not yet received): CAKHchJwQcH326Z8otiaXtKoKs6fH9s+e9BqJDi=H1bWKiuybAw@mail.gmail.com
Hi Abhay,
Quoted 3 lines · Abhay Sachan
Hi Fengguag,
Sorry for the out of topic question, but what benchmark is this? I have heard about blogbench, but it doesn't give output in this format AFAIK.
It is blogbench run in the lkp-tests framework.
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/
It will collect various system stats when blogbench runs. Then it presents you the collected blogbench stats together with slabinfo, meminfo, proc-vmstat, turbostat, softirqs etc. stats.
The basic steps to reproduce this report are
$ split-job jobs/blogbench.yaml
jobs/blogbench.yaml => ./blogbench-1HDD-ext4.yaml
jobs/blogbench.yaml => ./blogbench-1HDD-xfs.yaml
jobs/blogbench.yaml => ./blogbench-1HDD-btrfs.yaml # requires debian/ubuntu for now
$ bin/setup-local --hdd /dev/sdaX ./blogbench-1HDD-btrfs.yaml$ bin/run-local ./blogbench-1HDD-btrfs.yaml
The report is generated by the "sbin/compare" script.
Thanks,
Fengguang
Quoted 97 lines · Fengguang Wu
Quoted 91 lines
Hi Chris,
FYI, we noticed increased performance and reduced power consumption on
commit
4c468fd74859d901c0b78b42bef189295e00d74f("btrfs: disable strict file flushes for renames and truncates")test case: lkp-sb02/blogbench/1HDD-btrfs
0954d74f8f37a474c468fd74859d901c0b78b42b
--------------- -------------------------1094 ± 1% +7.8% 1180 ± 2% TOTAL blogbench.write_score 1396 ±19% -100.0% 0 ± 0% TOTAL slabinfo.btrfs_delalloc_work.active_objs 1497 ±17% -100.0% 0 ± 0% TOTAL slabinfo.btrfs_delalloc_work.num_objs 426 ±45% -100.0% 0 ± 0% TOTAL proc-vmstat.nr_vmscan_write 1.02 ±38% +193.1% 2.99 ±37% TOTAL turbostat.%pc6 0.12 ±48% +113.8% 0.25 ±29% TOTAL turbostat.%pc3 0.38 ±18% +117.7% 0.84 ±34% TOTAL turbostat.%pc2 19377 ±14% -50.9% 9520 ±20% TOTAL proc-vmstat.workingset_refault 44 ±41% +68.8% 75 ±28% TOTAL cpuidle.POLL.usage 31549 ± 1% +95.7% 61732 ± 1% TOTAL softirqs.BLOCK 4547 ±10% -38.3% 2804 ± 9% TOTAL slabinfo.btrfs_ordered_extent.active_objs 4628 ±10% -37.1% 2913 ± 9% TOTAL slabinfo.btrfs_ordered_extent.num_objs 17597 ± 8% -30.2% 12291 ±14% TOTAL proc-vmstat.nr_writeback 70335 ± 8% -30.1% 49174 ±14% TOTAL meminfo.Writeback 3606 ± 6% -29.1% 2556 ±10% TOTAL slabinfo.mnt_cache.active_objs 14763 ±12% -29.9% 10350 ± 8% TOTAL proc-vmstat.nr_dirty 3766 ± 5% -27.8% 2720 ±10% TOTAL slabinfo.mnt_cache.num_objs 3509 ± 6% -28.5% 2510 ±11% TOTAL slabinfo.kmalloc-4096.active_objs 59201 ±11% -30.1% 41396 ± 8% TOTAL meminfo.Dirty 479 ±13% -30.5% 333 ±10% TOTAL slabinfo.kmalloc-4096.num_slabs 479 ±13% -30.5% 333 ±10% TOTAL slabinfo.kmalloc-4096.active_slabs 3636 ± 6% -26.6% 2669 ±10% TOTAL slabinfo.kmalloc-4096.num_objs 6040 ± 8% -28.6% 4314 ± 6% TOTAL slabinfo.kmalloc-96.num_objs 5358 ± 5% -25.1% 4011 ± 7% TOTAL slabinfo.kmalloc-96.active_objs 757208 ± 4% -22.1% 589874 ± 4% TOTAL meminfo.MemFree 189508 ± 4% -22.2% 147518 ± 4% TOTAL proc-vmstat.nr_free_pages 762781 ± 4% -21.1% 601525 ± 4% TOTAL vmstat.memory.free 10491 ± 2% -16.8% 8725 ± 2% TOTAL slabinfo.kmalloc-64.num_objs 2513 ± 4% +16.3% 2923 ± 4% TOTAL slabinfo.kmalloc-128.active_objs 9768 ± 3% -15.1% 8298 ± 1% TOTAL slabinfo.kmalloc-64.active_objs 2627 ± 4% +14.0% 2995 ± 4% TOTAL slabinfo.kmalloc-128.num_objs 96242 ± 2% +15.5% 111120 ± 2% TOTAL slabinfo.btrfs_path.active_objs 3448 ± 2% +15.1% 3968 ± 2% TOTAL slabinfo.btrfs_path.num_slabs 3448 ± 2% +15.1% 3968 ± 2% TOTAL slabinfo.btrfs_path.active_slabs 96580 ± 2% +15.1% 111132 ± 2% TOTAL slabinfo.btrfs_path.num_objs 2526 ± 2% +13.5% 2867 ± 1% TOTAL slabinfo.btrfs_extent_state.num_slabs 2526 ± 2% +13.5% 2867 ± 1% TOTAL slabinfo.btrfs_extent_state.active_slabs 106133 ± 2% +13.5% 120434 ± 1% TOTAL slabinfo.btrfs_extent_state.num_objs 104326 ± 2% +12.3% 117189 ± 1% TOTAL slabinfo.btrfs_extent_state.active_objs 110759 ± 2% +13.4% 125640 ± 2% TOTAL slabinfo.btrfs_inode.active_objs 110759 ± 2% +13.4% 125642 ± 2% TOTAL slabinfo.btrfs_delayed_node.active_objs 4261 ± 2% +13.4% 4832 ± 2% TOTAL slabinfo.btrfs_delayed_node.num_slabs 4261 ± 2% +13.4% 4832 ± 2% TOTAL slabinfo.btrfs_delayed_node.active_slabs 110797 ± 2% +13.4% 125663 ± 2% TOTAL slabinfo.btrfs_delayed_node.num_objs 110815 ± 2% +13.4% 125669 ± 2% TOTAL slabinfo.btrfs_inode.num_objs 6926 ± 2% +13.4% 7853 ± 2% TOTAL slabinfo.btrfs_inode.num_slabs 6926 ± 2% +13.4% 7853 ± 2% TOTAL slabinfo.btrfs_inode.active_slabs 5607 ± 3% -11.0% 4991 ± 3% TOTAL slabinfo.kmalloc-256.active_objs 6077 ± 2% -9.9% 5476 ± 3% TOTAL slabinfo.kmalloc-256.num_objs 11153 ± 1% -7.7% 10295 ± 2% TOTAL proc-vmstat.nr_slab_unreclaimable 547824 ± 3% +16.5% 638368 ± 8% TOTAL meminfo.Inactive(file) 112124 ± 2% +11.6% 125105 ± 2% TOTAL slabinfo.radix_tree_node.active_objs 112169 ± 2% +11.6% 125134 ± 2% TOTAL slabinfo.radix_tree_node.num_objs 4005 ± 2% +11.6% 4468 ± 2% TOTAL slabinfo.radix_tree_node.num_slabs 4005 ± 2% +11.6% 4468 ± 2% TOTAL slabinfo.radix_tree_node.active_slabs 551119 ± 3% +16.4% 641663 ± 8% TOTAL meminfo.Inactive 285596 ± 2% +11.4% 318160 ± 2% TOTAL meminfo.SReclaimable 156 ± 3% +118.0% 340 ± 2% TOTAL iostat.sda.w/s 282 ± 3% -43.2% 160 ± 3% TOTAL iostat.sda.avgrq-sz 1.45 ±12% -28.9% 1.03 ±18% TOTAL iostat.sda.rrqm/s 633 ± 2% -26.5% 465 ± 2% TOTAL iostat.sda.wrqm/s 154423 ± 5% +17.4% 181309 ± 3% TOTAL time.voluntary_context_switches 536 ± 5% -11.5% 474 ± 9% TOTAL iostat.sda.await 102.71 ± 5% +10.4% 113.36 ± 6% TOTAL iostat.sda.avgqu-sz 20842 ± 2% -6.5% 19493 ± 2% TOTAL iostat.sda.wkB/s 20856 ± 2% -6.4% 19525 ± 2% TOTAL vmstat.io.bo 75.48 ± 4% -6.9% 70.27 ± 5% TOTAL turbostat.%c0 285 ± 4% -6.6% 266 ± 5% TOTAL time.percent_of_cpu_this_job_got 34.58 ± 2% -5.5% 32.68 ± 3% TOTAL turbostat.Cor_W 39.86 ± 2% -5.1% 37.82 ± 3% TOTAL turbostat.Pkg_W 5805 ± 1% -4.3% 5558 ± 3% TOTAL vmstat.system.in 10069454 ± 1% +6.3% 10699830 ± 1% TOTAL time.file_system_outputsDisclaimer:
Results have been estimated based on internal Intel analysis and are provided for informational purposes only. Any difference in system hardware or software design or configuration may affect actual performance.Thanks,
FengguangSignature · 1 line
Abhay
[btrfs] 8d875f95: xfstests.generic.226.fail
In reply to Fengguang WuHi Chris,
We noticed an xfstests failure on commit
8d875f95da43c6a8f18f77869f2ef26e9594fecc ("btrfs: disable strict file flushes for renames and truncates")
It's 100% reproducible in the 5 test runs.
test case: snb-drag/xfstests/4HDD-btrfs-generic-mid
27b9a8122ff71a8 8d875f95da43c6a8f18f77869
--------------- -------------------------
%change %stddev
| /
0 +Inf% 1 ± 0% TOTAL xfstests.generic.226.fail
Thanks,
Fengguang
Re: [btrfs] 8d875f95: xfstests.generic.226.fail
Quoted 5 lines · Fengguang Wu
We noticed an xfstests failure on commit
8d875f95da43c6a8f18f77869f2ef26e9594fecc("btrfs: disable strict file flushes for renames and truncates")It's 100% reproducible in the 5 test runs.
Same here, different mkfs configurations.
generic/226 28s ... [16:11:52] [16:12:55] - output mismatch (see /root/xfstests/results//generic/226.out.bad)
--- tests/generic/226.out 2013-05-29 17:16:03.000000000 +0200
+++ /root/xfstests/results//generic/226.out.bad 2014-08-19 16:12:55.000000000 +0200
@@ -1,6 +1,8 @@
QA output created by 226
--> mkfs 256m filesystem
--> 16 buffered 64m writes in a loop
-1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
+1 2 3 4 pwrite64: No space left on device
+5 6 7 8 9 10 11 12 pwrite64: No space left on device
+13 14 15 16enospc on a small filesystem (256M)
# btrfs fi df /mnt/a2 System, single: total=4.00MiB, used=4.00KiB Data+Metadata, single: total=252.00MiB, used=31.09MiB GlobalReserve, single: total=4.00MiB, used=0.00B
$ df -h /mnt/a2 Filesystem Size Used Avail Use% Mounted on /dev/sda9 256M 16M 241M 6% /mnt/a2
Re: [btrfs] 8d875f95: xfstests.generic.226.fail
Quoted 21 lines · David Sterba
Quoted 5 lines · Fengguang Wu
We noticed an xfstests failure on commit
8d875f95da43c6a8f18f77869f2ef26e9594fecc("btrfs: disable strict file flushes for renames and truncates")It's 100% reproducible in the 5 test runs.
Same here, different mkfs configurations.
generic/226 28s ... [16:11:52] [16:12:55] - output mismatch (see
/root/xfstests/results//generic/226.out.bad)--- tests/generic/226.out 2013-05-29 17:16:03.000000000 +0200 +++ /root/xfstests/results//generic/226.out.bad 2014-08-19 16:12:55.000000000 +0200 @@ -1,6 +1,8 @@ QA output created by 226 --> mkfs 256m filesystem --> 16 buffered 64m writes in a loop -1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 +1 2 3 4 pwrite64: No space left on device +5 6 7 8 9 10 11 12 pwrite64: No space left on device +13 14 15 16
Quoted 1 line
enospc on a small filesystem (256M)
I'm calling filemap flush more often, but otherwise everything else is the same. I'll take a look.
-chris
Re: [btrfs] 8d875f95: xfstests.generic.226.fail
Quoted 22 lines · Chris Mason
Quoted 21 lines · David Sterba
Quoted 5 lines · Fengguang Wu
We noticed an xfstests failure on commit
8d875f95da43c6a8f18f77869f2ef26e9594fecc("btrfs: disable strict file flushes for renames and truncates")It's 100% reproducible in the 5 test runs.
Same here, different mkfs configurations.
generic/226 28s ... [16:11:52] [16:12:55] - output mismatch (see
/root/xfstests/results//generic/226.out.bad)--- tests/generic/226.out 2013-05-29 17:16:03.000000000 +0200 +++ /root/xfstests/results//generic/226.out.bad 2014-08-19 16:12:55.000000000 +0200 @@ -1,6 +1,8 @@ QA output created by 226 --> mkfs 256m filesystem --> 16 buffered 64m writes in a loop -1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 +1 2 3 4 pwrite64: No space left on device +5 6 7 8 9 10 11 12 pwrite64: No space left on device +13 14 15 16
Quoted 4 lines
Quoted 1 line
enospc on a small filesystem (256M)
I'm calling filemap flush more often, but otherwise everything else is the same. I'll take a look.
The above patch also introduced a performance regression(~70%DOWN). We can reproduce this regression by fio, here is the config:
[global]
ioengine=falloc
iodepth=1
direct=0
buffered=0
directory=<mnt>
nrfiles=1
filesize=100mgroup_reporting
[sequential aio-dio write]
stonewall
ioengine=posixaio
numjobs=1
iodepth=128
buffered=0
direct=0
rw=write
bs=64k
filename=fragmented_file
I found the problem is caused by the following function:
int btrfs_release_file(struct inode *inode, struct file *filp)
{
...
filemap_flush(inode->i_mapping);
return 0;
}I don't think we need flush file at most situation. Ext4 flushes the file only after someone truncate the file to be zero-length, I don't know the real reason why ext4 flush the file only after the file is truncated, someone said it is to reduce the risk that the users find a zero-length file after a crash, which happens after truncate-write-close process.
If we change btrfs_release_file by ext4's implementation, both the failure of xfstests's generic/226 and performance regression can be fixed.
Thanks
Miao
Quoted 8 lines
-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [btrfs] 8d875f95: xfstests.generic.226.fail
Quoted 37 lines · Miao Xie
Quoted 22 lines · Chris Mason
Quoted 21 lines · David Sterba
Quoted 5 lines · Fengguang Wu
We noticed an xfstests failure on commit
8d875f95da43c6a8f18f77869f2ef26e9594fecc("btrfs: disable strict file flushes for renames and truncates")It's 100% reproducible in the 5 test runs.
Same here, different mkfs configurations.
generic/226 28s ... [16:11:52] [16:12:55] - output mismatch (see
/root/xfstests/results//generic/226.out.bad)--- tests/generic/226.out 2013-05-29 17:16:03.000000000 +0200 +++ /root/xfstests/results//generic/226.out.bad 2014-08-19 16:12:55.000000000 +0200 @@ -1,6 +1,8 @@ QA output created by 226 --> mkfs 256m filesystem --> 16 buffered 64m writes in a loop -1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 +1 2 3 4 pwrite64: No space left on device +5 6 7 8 9 10 11 12 pwrite64: No space left on device +13 14 15 16Quoted 4 lines
Quoted 1 line
enospc on a small filesystem (256M)
I'm calling filemap flush more often, but otherwise everything else is the same. I'll take a look.
I found the problem is caused by the following function:
int
btrfs_release_file(struct inode *inode, struct file *filp){ ... filemap_flush(inode->i_mapping); return 0; }
Quoted 9 lines
I don't think we need flush file at most situation. Ext4 flushes the file only after someone truncate the file to be zero-length, I don't know the real reason why ext4 flush the file only after the file is truncated, someone said it is to reduce the risk that the users find a zero-length file after a crash, which happens after truncate-write-close process.
If we change
btrfs_release_fileby ext4's implementation, both the failure of xfstests's generic/226 and performance regression can be fixed.
You're completely right, my original had more checks here and I stripped them out by accident. Fixing, thanks!
-chris
PATCH 1/1 Btrfs: fix filemap_flush call in btrfs_file_release
In reply to Miao XieWe should only be flushing on close if the file was flagged as needing it during truncate. I broke this with my ordered data vs transaction commit deadlock fix.
Thanks to Miao Xie for catching this.
fs/btrfs/file.c +9 -1
@@ -1840,7 +1840,15 @@ int btrfs_release_file(struct inode *inode, struct file *filp) {if (filp->private_data)btrfs_ioctl_trans_end (filp); -filemap_flush (inode->i_mapping); +/* +* ordered_data_close is set by settattr when we are about to truncate +* a file from a non-zero size to a zero size. This tries to +* flush down new bytes that may have been written if the +* application were using truncate to replace a file in place. +*/ +if (test_and_clear_bit (BTRFS_INODE_ORDERED_DATA_CLOSE , + &BTRFS_I (inode)->runtime_flags)) +filemap_flush (inode->i_mapping);return 0 ; }