Messages in this thread Patch in this message | | | Date | Fri, 14 May 1999 02:22:22 +0200 (CEST) | From | Andrea Arcangeli <> | Subject | Re: 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/
| |