Problem with ufs nextstep in 2.6.18 (debian)

Problem with ufs nextstep in 2.6.18 (debian)

[Dale Amon]

I recently noticed that I can no longer read my 
images of NeXTstep floppies on certain machines.
All are running an up to date etch distribution
but the difference between where I can read or not
read seems to be the linux version. On a 2.6.18
machine:

# mount -t ufs -o ro,ufstype=nextstep,loop nextfloppy-fd0a.ufs /floppy
# ls /floppy
ls: reading directory /floppy: Input/output error

On a 2.6.13 machine it still works fine:

# mount -t ufs -o ro,ufstype=nextstep,loop nextfloppy-fd0a.ufs /floppy
# ls /floppy/
private
# ls /floppy/private
Drivers

Have there been any recent changes that would cause a 
breakage in this area?

Re: Problem with ufs nextstep in 2.6.18 (debian)

[Dale Amon]

The error also happens in 2.6.19, same as in 2.6.18. I
extracted this from syslog:

Apr 17 00:14:08 kdev kernel: loop: loaded (max 8 devices)
Apr 17 00:14:15 kdev kernel: UFS-fs error (device loop0): ufs_check_page: bad entry in directory #2: directory entry across blocks - offset=356, rec_len=668, name_len=19
Apr 17 00:14:15 kdev kernel: UFS-fs error (device loop0): ufs_readdir: bad page in #2

Re: Problem with ufs nextstep in 2.6.18 (debian)

[Evgeniy Dushistov]

>The error also happens in 2.6.19, same as in 2.6.18.
>I extracted this from syslog: 
>Apr 17 00:14:15 kdev kernel: UFS-fs error (device loop0):
>ufs_check_page: bad entry

Is this happened also with this patch:
http://lkml.org/lkml/diff/2007/2/5/75/1
?

-- 
/Evgeniy

Re: Problem with ufs nextstep in 2.6.18 (debian)

[Dale Amon]

On Mon, Apr 16, 2007 at 11:32:04AM +0400, Evgeniy Dushistov wrote:
> >The error also happens in 2.6.19, same as in 2.6.18.
> >I extracted this from syslog: 
> >Apr 17 00:14:15 kdev kernel: UFS-fs error (device loop0):
> >ufs_check_page: bad entry
> 
> Is this happened also with this patch:
> http://lkml.org/lkml/diff/2007/2/5/75/1

Thanks. I will try that out tonight GMT. Which kernel
is that against? Will it work against a 2.6.19 or should
I get a 2.6.20 and work with that?

Re: Problem with ufs nextstep in 2.6.18 (debian)

[Dale Amon]

On Mon, Apr 16, 2007 at 05:04:22PM +0100, Dale Amon wrote:
> On Mon, Apr 16, 2007 at 11:32:04AM +0400, Evgeniy Dushistov wrote:
> > >The error also happens in 2.6.19, same as in 2.6.18.
> > >I extracted this from syslog: 
> > >Apr 17 00:14:15 kdev kernel: UFS-fs error (device loop0):
> > >ufs_check_page: bad entry
> > 
> > Is this happened also with this patch:
> > http://lkml.org/lkml/diff/2007/2/5/75/1
> 
> Thanks. I will try that out tonight GMT. Which kernel
> is that against? Will it work against a 2.6.19 or should
> I get a 2.6.20 and work with that?

Hmmm... looks like that patch is already applied in 
a 2.6.20.7? I will try that.

Re: Problem with ufs nextstep in 2.6.18 (debian)

[Dale Amon]

On Mon, Apr 16, 2007 at 11:32:04AM +0400, Evgeniy Dushistov wrote:
> >The error also happens in 2.6.19, same as in 2.6.18.
> >I extracted this from syslog: 
> >Apr 17 00:14:15 kdev kernel: UFS-fs error (device loop0):
> >ufs_check_page: bad entry
> 
> Is this happened also with this patch:
> http://lkml.org/lkml/diff/2007/2/5/75/1
> ?
> 
> -- 
> /Evgeniy

I tried the patch but it would not apply to 2.6.20.7 and
appeared to already exist in that release as patch was
asking me about reversing the patch. So I just built a
vanilla version:

Linux otv2 2.6.20.7-i686 #1 SMP Tue Apr 17 02:33:19 BST 2007 i686 GNU/Linux

and then tried the mount again:

otv2:/dma/FloppyDisks-3.50# mount -t ufs -o ro,ufstype=nextstep,loop NeXT-Diagram1-fd0a.ufs /floppy
otv2:/dma/FloppyDisks-3.50# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/hda2              8649576   5141412   3068788  63% /
tmpfs                   128128         0    128128   0% /lib/init/rw
udev                     10240        60     10180   1% /dev
tmpfs                   128128         0    128128   0% /dev/shm
/dma/FloppyDisks-3.50/NeXT-Diagram1-fd0a.ufs
                          1255      1184        71  95% /media/floppy0
otv2:/dma/FloppyDisks-3.50# ls /floppy
ls: reading directory /floppy: Input/output error

I find in syslog:

Apr 19 17:34:29 localhost kernel: UFS-fs error (device loop0): ufs_check_page: bad entry in directory #2: directory entry across blocks - offset=140, rec_len=884, name_len=7
Apr 19 17:34:29 localhost kernel: UFS-fs error (device loop0): ufs_readdir: bad page in #2

I would be happy to supply you with an image of the NeXT /dev/fd0a
floppy partition if you would like, or even a full image of
the floppy made via the NeXT raw device /dev/rfd0b.

Re: Problem with ufs nextstep in 2.6.18 (debian)

[Dave Bailey]

This problem has been around since kernel 2.6.16, and I see it in
2.6.23.1-10.fc7. It occurs in the ufs_check_page function of ufs/dir.c
at the Espan test, which seems unnecessary for NextStep/OpenStep
files systems. The following patch preserves the test for other file
systems and makes the mount useful for NextStep/OpenStep:
(against the 2.6.23.1-10.fc7 source tree)

dsb@Zeno-Dyn[1012]$ diff dir.c dir.c.orig
108,110d107
<       unsigned mnext = UFS_SB(sb)->s_mount_opt &
<         (UFS_MOUNT_UFSTYPE_NEXTSTEP || UFS_MOUNT_UFSTYPE_NEXTSTEP_CD ||
<          UFS_MOUNT_UFSTYPE_OPENSTEP);
131c128
<               if ((mnext == 0) & (((offs + rec_len - 1) ^ offs) & 
~chunk_mask))
---
 >               if (((offs + rec_len - 1) ^ offs) & ~chunk_mask)

Re: Problem with ufs nextstep in 2.6.18 (debian)

[Jan Kara]

> This problem has been around since kernel 2.6.16, and I see it in
> 2.6.23.1-10.fc7. It occurs in the ufs_check_page function of ufs/dir.c
> at the Espan test, which seems unnecessary for NextStep/OpenStep
> files systems. The following patch preserves the test for other file
> systems and makes the mount useful for NextStep/OpenStep:
> (against the 2.6.23.1-10.fc7 source tree)
> 
> dsb@Zeno-Dyn[1012]$ diff dir.c dir.c.orig
> 108,110d107
> <       unsigned mnext = UFS_SB(sb)->s_mount_opt &
> <         (UFS_MOUNT_UFSTYPE_NEXTSTEP || UFS_MOUNT_UFSTYPE_NEXTSTEP_CD ||
> <          UFS_MOUNT_UFSTYPE_OPENSTEP);
> 131c128
> <               if ((mnext == 0) & (((offs + rec_len - 1) ^ offs) & 
> ~chunk_mask))
> ---
> >               if (((offs + rec_len - 1) ^ offs) & ~chunk_mask)
  Thanks for your contribution but we cannot take it as is - at least
Signed-off-by line is missing and the patch should also be in unified
diff format. Please read linux/Documentation/SubmittingPatches...
Thanks.

							Honza
-- 
Jan Kara <jack@suse.cz>
SuSE CR Labs

Re: Problem with ufs nextstep in 2.6.18 (debian)

[Evgeniy Dushistov]

On Tue, Nov 20, 2007 at 12:29:03PM -0800, Dave Bailey wrote:
> This problem has been around since kernel 2.6.16, and I see it in
> 2.6.23.1-10.fc7. It occurs in the ufs_check_page function of ufs/dir.c
> at the Espan test, which seems unnecessary for NextStep/OpenStep
> files systems. The following patch preserves the test for other file
> systems and makes the mount useful for NextStep/OpenStep:
> (against the 2.6.23.1-10.fc7 source tree)
>
> dsb@Zeno-Dyn[1012]$ diff dir.c dir.c.orig
> 108,110d107
> <       unsigned mnext = UFS_SB(sb)->s_mount_opt &
> <         (UFS_MOUNT_UFSTYPE_NEXTSTEP || UFS_MOUNT_UFSTYPE_NEXTSTEP_CD ||
> <          UFS_MOUNT_UFSTYPE_OPENSTEP);
> 131c128
> <               if ((mnext == 0) & (((offs + rec_len - 1) ^ offs) & 
> ~chunk_mask))
> ---
> >               if (((offs + rec_len - 1) ^ offs) & ~chunk_mask)

This fixes only symptom, not illness.
This check represent what code think about filesystem layout.
On what actually kind of UFS system did you test this patch?
When I sometime ago fixed similar issue for openstep ufs,
actully this was darwin's ufs which has the same layout,
I just set s_dirblksize to right value, may be for 
UFS_MOUNT_UFSTYPE_NEXTSTEP, UFS_MOUNT_UFSTYPE_NEXTSTEP_CD you need
do the same, see TODO items in fs/ufs/super.c.

-- 
/Evgeniy

Re: Problem with ufs nextstep in 2.6.18 (debian)

[Dave Bailey]

This fixes only symptom, not illness.
This check represent what code think about filesystem layout.
On what actually kind of UFS system did you test this patch?
When I sometime ago fixed similar issue for openstep ufs,
actully this was darwin's ufs which has the same layout,
I just set s_dirblksize to right value, may be for 
UFS_MOUNT_UFSTYPE_NEXTSTEP, UFS_MOUNT_UFSTYPE_NEXTSTEP_CD you need
do the same, see TODO items in fs/ufs/super.c.

-- 
/Evgeniy

Your right; I was using the NextStep ufstype on an OpenStep HD.
I have now checked an old (pre NS 3.3) floppy and a NS 3.3 CDROM
and they both need a  s_dirblksize  of 1024, just as the OpenStep
filesystem does. For the floppies, one can just use the OpenStep
option, but for a NextStep CDROM, the right s_dirblksize is
crucial. I would suggest changing both.

Thanks for the response,