Messages in this thread | | | From | John Bradford <> | Subject | Re: 2.4.21-pre2 stalls out when running unixbench | Date | Mon, 6 Jan 2003 12:15:42 +0000 (GMT) |
| |
> > This is because of differences in how sync() is handled between 2.4.20's > > ext3 and 2.4.21-pre2's. > > > > 2.4.21-pre2: > > > > sync() will start the commit, and will wait on it. So you know that > > when it returns, everything which was dirty is now tight on disk. > > > > So yes, running a looping sync while someone else is writing stuff > > will take much longer in 2.4.21-pre2, because that kernel actually > > waits on the writeout. > > Actually, I'm wondering if we should back that particular bit out. For > a user with a hundred mounted filesystems, syncing each one in order, > sequentially, is going to suck (and we don't currently have a simple way > in 2.4 to detect which syncs are on separate spindles and so can be > parallelised.)
What!? I'm suprised that no userspace applications were broken by sync returning before the data is safely on oxide, even though it doesn't violate the POSIX spec.
What about userspace media-changers, (if such a thing exists)? Presumably they would assume that they can eject the media after a sync.
I think sync should definitely wait until it's completed before it returns.
John. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |