Date:	Fri, 5 Jan 2001 21:35:57 +0000
From:	"Stephen C. Tweedie" <sct@redhat.com>
To:	ext3-users@redhat.com, linux-fsdevel@vger.kernel.org
Subject: Announcing ext3-0.0.5e

Hi all,

OK, here is ext3-0.0.5e.  Changes since 5d are summarised below.  The
major changes are the barrier support: this infrastructure should be
sufficient to allow the snapshotting interface which LVM is wanting
for ext3.  The journal initialisation fix will also help people adding
ext3 to an existing filesystem.  Look for ext3-0.0.5e.tar.gz on:

	ftp.*.kernel.org:/pub/linux/kernel/people/sct/ext3/
and	ftp.uk.linux.org:/pub/linux/sct/fs/jfs/

This is probably it for the 0.0.5 series.  There's one major fix which
I was going to postpone until after a codefreeze of the ext3 branch
for 1.0, but it looks like it is important to get it done earlier, so
I'll now be working for a 0.0.6 release which reworks the handling of
dirty flags in the jfs layer: I'll have to maintain a separate dirty
bit to indicate which buffers have modified data, but keep the normal
buffer_dirty() flag clear while buffers are journaled.

The plan is to go to a kernel-style numbering scheme once we have
codefreeze: 0.9 will be the codefreeze for a 1.0 release, but I'll
fork a 1.1 branch for developments such as a 2.4 port while 1.0 is
kept stable and supported as the baseline 2.2 version.

That is the last major change pending for ext3.  There are a couple of
other minor changes, in particular to clear up a small race in quotas,
and I need to go over the ultra-paranoid debugging checks to change
the panics into warnings whenever we have checks which can trigger in
real life if the disk gets corrupted.

I want to move to a freeze of this development code a week or so after
0.0.6.  I'll move to a 0.9 numbering at that point to indicate that
this is to be stabilised for an ext3-1.0 as soon as possible, which
means basically that as much testing as possible would be appreciated,
so I'll be doing RPMs for the kernel as of 0.0.6.  

Once the dirty-buffer, quota and IO checking is in, consider this a
functionality freeze for 1.0.  If anybody has other functionality
wanting added, yell now.  The only other things I'm considering at the
moment are:

 * Support for truly readonly mounts if the media is not physically
   writable
 * Support for per-filesystem limits on transaction sizes

In addition, I'll do patches for large file support, but since LFS is
a separate kernel patch anyway, that will probably be an extra on top
of the base ext3 release.

The only significant bug reports still outstanding against 5e (as far
as I know!) are a few instances of "buffer already locked" assertion
failures when running ext3 on loop or raid0 devices, and the
dirty-buffer changes in 0.0.6 are intended to address that.

Cheers,
 Stephen

Changes in this release
-----------------------

0.0.5e:

Added barrier support: it is now possible to suspend all journal
activity on a filesystem temporarily, forcing the journal into a clean
state.

Added support for forcing data-journaling on a per-inode basis.  Enable
this on the quota files.

Fix O_SYNC for the writeback data journaling mode.

In ext3_orphan_del, lock the superblock _before_ testing the orphan list
to make the entire operation atomic.

When rename overwrites and deletes a file, make sure that file gets put
on the orphan list.

Fix the initialisation of a new journal: make sure that the journal
superblock is pre-zeroed along with the rest of the journal.

Don't mount or remount a journal with unrecognised features.

{ For older changes, see the file CHANGES. }

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org