On Sat, 4 Aug 2007 09:17:44 -0700 (PDT) Linus Torvalds [off-list ref] wrote:

On Sat, 4 Aug 2007, Ingo Molnar wrote:

quoted

quoted

[ my personal interest in this is the following regression: every time 
  i start a large kernel build with DEBUG_INFO on a quad-core 4GB RAM 
  box, i get up to 30 seconds complete pauses in Vim (and most other 
  tasks), during plain editing of the source code. (which happens when 
  Vim tries to write() to its swap/undo-file.) ]

hm, it turns out that it's due to vim doing an occasional fsync not only 
on writeout, but during normal use too. "set nofsync" in the .vimrc 
solves this problem.

Yes, that's independent. The fact is, ext3 *sucks* at fsync. I hate hate 
hate it. It's totally unusable, imnsho.

The whole point of fsync() is that it should sync only that one file, and 
avoid syncing all the other stuff that is going on, and ext3 violates 
that, because it ends up having to sync the whole log, or something like 
that. So even if vim really wants to sync a small file, you end up waiting 
for megabytes of data being written out.

I detest logging filesystems. 

Well it's not a problem with journalling per-se.  Other journalling designs
may well not have this problem.

It's an unfortunate coupling:

- the ext3 journal contains metadata from all altered files

- ordered-mode needs to write back data for a file before committing its
  metdata to the journal.

- fsync of one file requires a commit for its metadata, which will commit
  metadata for all files

- hence we need to write back all data for all files which have metadata
  in the journal.


It's pretty much unfixable given the ext3 journalling design, and the
guarantees which data-ordered provides.

The easy preventive is to mount with data=writeback.  Maybe that should
have been the default.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>