>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/