Just to keep people in the loop...

I'm progressing through various issues which Kirk, Robert and I
feel should not be part of the actual UFS2 commit since they are
more cleanups and preparation than part of UFS2.

The next major commit is the 64ification of daddr_t and friends.

But don't get carried away now.  Since newfs/fsck will have to use
lseek(2) to access the diskdevice, UFS2 filesystems will be restricted
to 2^63 bytes, or "8M TeraBytes" whatever they are called (until
at least we make off_t larger than s64).

After this, disk-driver writers can start to teach drivers how to access
more than 2^31 x 512 bytes.

Having looked at a lot of very similar code in userland I am also
exploring if adding an internal libffs would be a good idea.

We are also working to divorce EXT2FS from UFS (Thanks Ian!) and
exploring of we need to deal with IFS or not.

The current patchset does not result in a split of UFS into a version
one and a version two, so we don't grow a new complement of tools
or kernel files for this.  In practice newfs will grow the "-O
[1|2]" option, defaulting to 1 for now, but hopefully defaulting
to 2 in 5.0-R.

We hope to commit the UFS2 patch to -current before the end of May.

Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to