Re: Problem with ufs nextstep in 2.6.18 (debian)
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, - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with ufs nextstep in 2.6.18 (debian)
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) > > [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with ufs nextstep in 2.6.18 (debian)
> 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) > > [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> SuSE CR Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with ufs nextstep in 2.6.18 (debian)
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) [EMAIL PROTECTED] 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) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with ufs nextstep in 2.6.18 (debian)
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 0128128 0% /lib/init/rw udev 1024060 10180 1% /dev tmpfs 128128 0128128 0% /dev/shm /dma/FloppyDisks-3.50/NeXT-Diagram1-fd0a.ufs 1255 118471 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with ufs nextstep in 2.6.18 (debian)
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with ufs nextstep in 2.6.18 (debian)
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? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with ufs nextstep in 2.6.18 (debian)
>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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with ufs nextstep in 2.6.18 (debian)
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Problem with ufs nextstep in 2.6.18 (debian)
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? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
