Theodore Ts'o ty...@mit.edu writes:
On Fri, Jun 28, 2013 at 08:37:40AM +0900, OGAWA Hirofumi wrote:
Well, anyway, it is simple. This issue was came as the performance
regression when I was experimenting to use kernel bdi flusher from own
flusher. The issue was sync(2) like I said. And this
Hi,
On the following stress, sync(2) became top of cpu load.
fsstress -s 1 -n 5 -p 3 -d `pwd`
After profile by perf, cpu load was lock contention of inode_sb_list_lock.
sync(2) is data integrity operation, so it has to make sure all dirty
data was written before sync(2) point. The
On Wed, 26 June 2013 17:45:23 +0900, OGAWA Hirofumi wrote:
fs/fs-writeback.c |5 -
include/linux/fs.h |1 +
2 files changed, 5 insertions(+), 1 deletion(-)
diff -puN include/linux/fs.h~tux3-fix-wait_sb_inodes include/linux/fs.h
---
Dave Chinner da...@fromorbit.com writes:
Optimizing wait_sb_inodes() might help lock contention, but it doesn't
help unnecessary wait/check.
You have your own wait code, that doesn't make what the VFS does
unnecesary. Quite frankly, I don't trust individual filesystems to
get it right -
Hi Dave,
On Wed, Jun 26, 2013 at 9:47 PM, Dave Chinner da...@fromorbit.com wrote:
You have your own wait code, that doesn't make what the VFS does
unnecesary. Quite frankly, I don't trust individual filesystems to
get it right - there's a long history of filesystem specific data
sync problems
