Re: [PATCH 00/23] per device dirty throttling -v8

[Andrew Morton]

On Sat, 4 Aug 2007 09:17:44 -0700 (PDT) Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:

> 
> 
> On Sat, 4 Aug 2007, Ingo Molnar wrote:
> 
> > > [ 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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/