An ext3 update for Alan's latest kernel is at http://www.uow.edu.au/~andrewm/linux/ext3/ The version of ext3 in -ac kernels currently stands at 0.9.6, so this is a fairly large diff. However most of this code has had a decent amount of external testing via the 0.9.9 patch. The changelog since 0.9.6 is below. Please test it if you can, and all being well we shall ask Alan to merge it a few days hence. Most ext3 work at present is concentrating on -ac kernels. The change rate in Linus' kernels seems to have slowed now, so we'll try to get a 2.4.11 version of ext3 ready for next week. There is a core kernel change in this diff which should be described: generic_file_write() has been altered so that it always calls commit_write(), even if the copy_from_user() faulted. This change is already present in Linus' kernel - it is a generic bugfix which prevents leakage of stale disk data in rare circumstances. lo_send() has also been changed so that it too calls commit_write() if prepare_write() succeeded. The net result is that all prepare_write()/commit_write() calls are now balanced, so the abort_write() a_op (which was introduced to cope with the perpare-but-no-commit error case) has been removed. This is an internal kernel API change! All callers of prepare_write() must now call commit_write() if the prepare_write() succeeded. 0.9.7 ----- - Merge in a large batch of changes to allow ext3 to recover gracefully from fatal errors. If the fs is set to remount-readonly on error, then we should still be able to unwind cleanly and unmount the filesystem. - Performance: don't write superblocks synchronously. This reduces a bottleneck in the VM. Load the ext3 module with the parameter "do_sync_supers=1" to restore the previous behaviour. - Performance: don't force a new transaction every time we sync (should prevent the writes previously happening every 5 seconds, allowing laptop drives to spin down again.) 0.9.8 ----- - Fix an NFS oops when doing a local delete on an active, nfs-exported file. - Add proper log levels to a lot of kernel warnings when mounting a bad filesystem or a fs with errors - Make sure we set the error flag both in the journal and fs superblocks on error (unless we're doing panic-on-error) 0.9.9 ----- - Fix the buffer-already-revoked assertion failure by looking up an aliased buffercache buffer and clearing the revoke bits in there as well as in the journalled data buffer. - Reorganise page truncation code so we don't take the address of block_flushpage(). This is to simplify merging with Andrea's O_DIRECT patch, which turns block_flushpage() into a macro. 0.9.10 ------ - Fix an oops which could occur at unmount time due to non-empty orphan list. This could be triggered by an earlier error during a truncate. - Merge Ted's directory scan speedup heuristic. - Remove the abort_write() address_space_operation() by ensuring that all prepare_write() callers always call commit_write(). - A number of changes to suit the new 2.4.10 VM and buffer-layer design. 0.9.11 ------ - Fix CONFIG_BUFFER_DEBUG builds - Fix truncate deadlock - Fix bmap oops on data-journaled filesystems - Add MODULE_LICENSE tags - Cleanup some error messages 0.9.12 ------ - Fix oops in directory readahead on empty (ie. deleted) directories - Handle new S_NOQUOTA flag for 2.4.10+ quota code - Revert i_truncate_sem vs i_sem lock ordering to original design. This fixes an obscure deadlock, but will deadlock 2.4.11's shmem.c. It's safe with 2.4.10-ac11's shmem.c
Andrew, Any chance of 0.9.12 for Linus' 2.4.10 tree? Also, where can I get information on these ac builds? We are currently heavily based on Linus' tree on PowerPC. We also require EXT3, so it would be really nice to keep up to date with both. Is the -ac kernel close enough to Linus' tree, in which I may be able to muck with the -ac patch to work on Linus' tree? Thanks, Paul W. On Wed, 10 Oct 2001, Andrew Morton wrote:> An ext3 update for Alan's latest kernel is at > > http://www.uow.edu.au/~andrewm/linux/ext3/ > > The version of ext3 in -ac kernels currently stands at 0.9.6, so > this is a fairly large diff. However most of this code has had a > decent amount of external testing via the 0.9.9 patch. The changelog > since 0.9.6 is below. > > Please test it if you can, and all being well we shall ask Alan > to merge it a few days hence. > > Most ext3 work at present is concentrating on -ac kernels. The > change rate in Linus' kernels seems to have slowed now, so we'll > try to get a 2.4.11 version of ext3 ready for next week. > > There is a core kernel change in this diff which should be > described: > > generic_file_write() has been altered so that it always calls > commit_write(), even if the copy_from_user() faulted. This change > is already present in Linus' kernel - it is a generic bugfix which > prevents leakage of stale disk data in rare circumstances. > > lo_send() has also been changed so that it too calls commit_write() > if prepare_write() succeeded. > > The net result is that all prepare_write()/commit_write() calls > are now balanced, so the abort_write() a_op (which was introduced > to cope with the perpare-but-no-commit error case) has been > removed. > > This is an internal kernel API change! All callers of prepare_write() > must now call commit_write() if the prepare_write() succeeded. > > > 0.9.7 > ----- > > - Merge in a large batch of changes to allow ext3 to recover gracefully > from fatal errors. If the fs is set to remount-readonly on error, then > we should still be able to unwind cleanly and unmount the filesystem. > > - Performance: don't write superblocks synchronously. This reduces a > bottleneck in the VM. > > Load the ext3 module with the parameter "do_sync_supers=1" to restore > the previous behaviour. > > - Performance: don't force a new transaction every time we sync (should > prevent the writes previously happening every 5 seconds, allowing laptop > drives to spin down again.) > > 0.9.8 > ----- > > - Fix an NFS oops when doing a local delete on an active, nfs-exported > file. > > - Add proper log levels to a lot of kernel warnings when mounting a bad > filesystem or a fs with errors > > - Make sure we set the error flag both in the journal and fs superblocks > on error (unless we're doing panic-on-error) > > 0.9.9 > ----- > > - Fix the buffer-already-revoked assertion failure by looking up an > aliased buffercache buffer and clearing the revoke bits in there as > well as in the journalled data buffer. > > - Reorganise page truncation code so we don't take the address of > block_flushpage(). This is to simplify merging with Andrea's > O_DIRECT patch, which turns block_flushpage() into a macro. > > 0.9.10 > ------ > > - Fix an oops which could occur at unmount time due to non-empty > orphan list. This could be triggered by an earlier error during a > truncate. > > - Merge Ted's directory scan speedup heuristic. > > - Remove the abort_write() address_space_operation() by ensuring that > all prepare_write() callers always call commit_write(). > > - A number of changes to suit the new 2.4.10 VM and buffer-layer design. > > 0.9.11 > ------ > > - Fix CONFIG_BUFFER_DEBUG builds > > - Fix truncate deadlock > > - Fix bmap oops on data-journaled filesystems > > - Add MODULE_LICENSE tags > > - Cleanup some error messages > > 0.9.12 > ------ > > - Fix oops in directory readahead on empty (ie. deleted) directories > > - Handle new S_NOQUOTA flag for 2.4.10+ quota code > > - Revert i_truncate_sem vs i_sem lock ordering to original design. This > fixes an obscure deadlock, but will deadlock 2.4.11's shmem.c. It's safe > with 2.4.10-ac11's shmem.c > > > > _______________________________________________ > Ext3-users mailing list > Ext3-users@redhat.com > https://listman.redhat.com/mailman/listinfo/ext3-users >
Hi> > Most ext3 work at present is concentrating on -ac kernels. The > change rate in Linus' kernels seems to have slowed now, so we'll > try to get a 2.4.11 version of ext3 ready for next week.What a shame! I just migrated to ext3 when the patch for 2.4.10 came out and am really pleased with it. Does this mean I can't upgrade to 2.4.11 until sometimes next week? Personally I don't understand why there is more concentration on the -ac trees, since concentrating on the official kernel would mean sooner integration of ext3 in the main kernel and much less hassle for users. I guess it's a some kind of political thing (Red Hat using -ac kernels and ext3 development payed by Red Hat?). After all it's called Linux and not Coxux (try to say that a few times really fast...). Bye Tim
On Thu, 11 Oct 2001 00:17:54 -0700 Andrew Morton <akpm@zip.com.au> wrote:> Tim Tassonis wrote: > > > > Hi > > > > > > Most ext3 work at present is concentrating on -ac kernels. The > > > change rate in Linus' kernels seems to have slowed now, so we'll > > > try to get a 2.4.11 version of ext3 ready for next week. > > > > What a shame! I just migrated to ext3 when the patch for 2.4.10 cameout> > and a quite pleased with it. Does this mean I can't upgrade to 2.4.11 > > until sometimes next week? > > 'fraid so. It's safer that way. We're really careful. > > > Personally I don't understand why there is more > > concentration on thnixe -ac trees, since concentrating on the official > > kernel would mean sooner integration of ext3 in the main kernel andmuch> > less hassle for users. I guess it's a some kind of political thing(Red> > Hat using -ac kernels and ext3 development payed by Red Hat?). > > > > No.... > > Alan is a lot more careful and conservative than Linus, > and frankly, he gets a lot more work done.I think not even Alan would agree on this. I remember him writing that he sees the -ac Kernels as some kind of testbed for new patches, but maybe that changed again. He sure does get a lot of work done though.> His 2.4 kernels > have traditionall had a *lot* of bugs fixed which Linus's > ones haven't. THere's a reason why all commercial distros > base off -ac kernels...Well, this surprises me a bit, since after "stabilizing", Alan is normally the maintainer of the stable series. Why is then there a need for another -ac tree (apart from the "testbed" theory)?> Plus Linus tends to go off on wild experimental stuff and breaks > things, as he did with 2.4.10. Supporting -ac is a *lot* easier. > The recent linus changes have put into question months of testing > and performance tuning.Well, if you're talking about the VM changes, I think that was the best thing happening for a long time. My 2.4.10 (with ext3 and vmtweaks) runs really stable, and better than the previous kernels. The next best thing would be ext3, but that seems a bit unlikely at the moment. Of course I can use a Red Hat kernel, but I really never do, I prefer the official ones and am quite happy with it. Bye Tim
Andrew Morton wrote:> Really, there's no point in working against 2.4.10 - the VM > and block device changes in that kernel were quite immature > and it has numerous problems. If you're currently using > 2.4.10 I'd heartily recommend that you find a way to stop it.I'm. Well, what you suggest ? -ac11 ?> I expect 2.4.11 to be a lot better.linux-2.4.11-dontuse ? :) Anyway, I think I'll just move to -ac and pray. But it'd be nice to have more ext3 updates with the -ac releases. It moved from 0.9.6 to 0.9.12... Thank you ext3 developers. I didn't compile 2.4.11 because there was no patch for ext3. And now it was renamed :) BTW, last I heard from Andrew on the list ext3 would possibly be integrated in 2.4.10-pre1 or 2, and Linus said he would merge it. What happened ? Will it happen in 2.4 ? -- 0@pervalidus.{net, {dyndns.}org} Tel: 55-21-2717-2399 (Niteri-RJ BR)