Subject: port-macppc/23926: kernel APPLE_UFS support needs review
To: None <gnats-bugs@gnats.netbsd.org>
From: Darrin B. Jewell <dbj@netbsd.org>
List: netbsd-bugs
Date: 12/29/2003 00:17:23
>Number:         23926
>Category:       port-macppc
>Synopsis:       kernel APPLE_UFS support needs review
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-macppc-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Dec 29 05:18:01 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     Darrin B. jewell
>Release:        -current, updated via cvs ~20031227T2330Z
>Organization:
>Environment:
$ uname -a 
    Darwin Quiteria 7.2.0 Darwin Kernel Version 7.2.0: Thu Dec 11 16:20:23 PST 2003;
    root:xnu/xnu-517.3.7.obj~1/RELEASE_PPC  Power Macintosh powerpc
>Description:

Fortunately, most kernel compatibility issues have been
addressed in recent work by manuel bouyer.  This pr is just
a reminder and note collection for review of these issues
with specific respect for APPLE_UFS.

Based on user and developer discussion and code inspection,
kernel support for APPLE_UFS needs to be reviewed.

Current versions of MacOS X still use FS_DYNAMICPOSTBLFMT,
although it will perform the following check in ffs_alloc.c
  if (fs->fs_nrpos <= 1 || fs->fs_cpc == 0)
This check was introduced by mckusick on 1995/05/03
Before that, the check was:
   if (fs->fs_cpc == 0)
and was introced by mckusick on 1982/01/06

NeXTSTEP used FS_POSTBLFMT, which probably needs the older
check.

fvdl instoduced a change to netbsd ffs_vfsops.c in revision 1.115
which forces nrpos to 0 when using apple ufs.  This should
probably be changed to zero cpc instead.  It is possible
that this change should not be restricted to APPLE_UFS.

SUPPORT_FS_42POSTBLFMT_WRITE may be unnecessary if the above change is
performed; Otherwise, we may wish consider maintaining the the
rotational allocation tables correctly.  This decision should be
re-reviewed after related APPLE_UFS fsck issues in a separate PR are
addressed.

We should also possibly consider always maintaining the old
flags, or never letting apple ufs set any unusual new flags.

See also:

  revision 1.115 of src/sys/ufs/ffs/ffs_vfsops.c

  kern/17345 "Apple UFS filesystem support, patches included"

  kern/21404 "new kernel breaks file system for old kernels"
  kern/21283 "current FFS (not v2) incompatible with older NetBSD releases"

  I also have related prs pending submission for fsck and newfs.

>How-To-Repeat:
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: