lkml.org 
[lkml]   [1999]   [May]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: All the problems with 2.2.8/2.3.x and bdflush/update
On Thu, 13 May 1999, Zack Weinberg wrote:

>1. Don't run update with 2.2.8. It's unnecessary and it's causing

I think that we shouldn't kill update in 2.2.x. I bet many people will
continue to run it and they will harm performances.

There is _no_ one good point in killing update other than saving some page
of memory for the update task (kernel stack and some minor thing).

>filesystem corruption for some people. This has to be a bug somewhere
>else in the kernel; update is simply calling sync() every thirty
>seconds.

I never run with your changes applyed but reading some spare email I bet
the problem is that tasks are getting stuck in mark_dirty_buffer(), I
think for some reason they don't get a wakeup correctly.

>2. If you want your disks to spin down, try mounting filesystems with
>noatime. I do not like the idea of postponing writes indefinitely at
>all.

I don't understand exactly why you talk about noatime...

>3. The appended patch should correct the buffer backlog problems
>observed by Steve Willer. It is NOT ready to go into the official

What is this backlog problem?

>4. Under some conditions, 2.2.8 will get stuck in unlink(). sysrq-P

It's due a bug in ext2fs and you triggered it. I noticed it too some time
ago and I fixed it (here it is the obviously right fix ready for
2.2.9/2.3.1).

Index: fs/ext2/truncate.c
===================================================================
RCS file: /var/cvs/linux/fs/ext2/truncate.c,v
retrieving revision 1.1.1.1
retrieving revision 1.1.2.4
diff -u -r1.1.1.1 -r1.1.2.4
--- truncate.c 1999/01/18 01:26:52 1.1.1.1
+++ linux/fs/ext2/truncate.c 1999/04/27 16:00:49 1.1.2.4
@@ -393,6 +393,7 @@
return;
ext2_discard_prealloc(inode);
while (1) {
+ run_task_queue(&tq_disk);
retry = trunc_direct(inode);
retry |= trunc_indirect (inode,
EXT2_IND_BLOCK,

>6. I am not on linux-kernel except via a web archive. Please, if you
>have anything to say about buffer.c, mail me directly.

In this your patch you have not tried to return to give a sense to
bh->flushtime. And now you'll also flush all dirty buffers every interval.

Andrea Arcangeli


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.226 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site