This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 209921 - ufs broken on 64bit
ufs broken on 64bit
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
6
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Eric Sandeen
Brian Brock
:
: 212708 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-08 06:10 EDT by andiburget
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-11-12 00:48:41 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
structure alignment patch (532 bytes, patch)
2006-10-29 08:44 EST, Eric Sandeen
no flags Details | Diff
dump of dd if=/dev/sda5 of=/work/sda5.txt bs=1K count=256 (256.00 KB, application/octet-stream)
2006-11-02 11:24 EST, Rami Rosen
no flags Details

  None (edit)
Description andiburget 2006-10-08 06:10:21 EDT
Description of problem:
I migrated from FreeBSD 6.1 to FC6 Pre x86_64 and tried to mount my
UFS2-formatted drives...

here's what I did:
# mount -r -t ufs -o ufstype=ufs2 /dev/sdd1 /mnt
mount: wrong fs type, bad option, bad superblock on /dev/sdd1,
       missing codepage or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

here's what dmesg said:
ufs_read_super: bad magic number

# cat /proc/filesystems
nodev   sysfs
nodev   rootfs
nodev   bdev
nodev   proc
nodev   cpuset
nodev   binfmt_misc
nodev   debugfs
nodev   securityfs
nodev   sockfs
nodev   usbfs
nodev   pipefs
nodev   futexfs
nodev   tmpfs
nodev   inotifyfs
nodev   eventpollfs
nodev   devpts
        ext2
nodev   ramfs
nodev   hugetlbfs
        iso9660
nodev   mqueue
nodev   selinuxfs
        ext3
nodev   rpc_pipefs
nodev   autofs
        ufs 

# ./modinfo ufs
filename:       /lib/modules/2.6.18-1.2708.fc6/kernel/fs/ufs/ufs.ko
license:        GPL
srcversion:     28C144D2C43C6B79635A5AA
depends:       
vermagic:       2.6.18-1.2708.fc6 SMP mod_unload gcc-4.1


How reproducible:
just try to mount a UFS2-formatted drive on x86_64 ;)


Additional info:
i'm using FC6 Pre x86 now and mounting the drives works perfectly!
Comment 1 Eric Sandeen 2006-10-29 08:40:33 EST
The on-disk structure definition for the 3rd superblock was getting improper
alignment due to the natural alignment of 64-bit vars on x86_64.  This caused it
to look for fs_magic at the wrong offset in memory.

This patch lets me mount a test ufs2 filesystem.  Can you try this patch on your
kernel?  I don't actually have a populated ufs2 filesystem to test further than
a simple mount.  (I'd stick with read-only!)

Index: linux-2.6.18/include/linux/ufs_fs.h
===================================================================
--- linux-2.6.18.orig/include/linux/ufs_fs.h
+++ linux-2.6.18/include/linux/ufs_fs.h
@@ -900,7 +901,7 @@ struct ufs_super_block_third {
                        __fs64   fs_csaddr;     /* blk addr of cyl grp summary
area */
                        __fs64    fs_pendingblocks;/* blocks in process of being
freed */
                        __fs32    fs_pendinginodes;/*inodes in process of being
freed */
-               } fs_u2;
+               } __attribute__ ((packed)) fs_u2;
        } fs_un1;
        union {
                struct {
Comment 2 Eric Sandeen 2006-10-29 08:44:30 EST
Created attachment 139666 [details]
structure alignment patch

Properly formatted patch... I should know better than to paste one inline :)
Comment 3 Eric Sandeen 2006-10-30 00:12:06 EST
fwiw, I think the cylinder group on-disk structure may suffer from similar
alignment issues.
Comment 4 Eric Sandeen 2006-10-31 12:06:11 EST
I take that back, the cylinder group stuff should be ok.

The patch in comment #2 is in -mm, and I have proposed it for -stable as well,
since this is a regression since 2.6.17.
Comment 5 Dave Jones 2006-10-31 12:14:00 EST
*** Bug 212708 has been marked as a duplicate of this bug. ***
Comment 6 Dave Jones 2006-10-31 12:14:15 EST
*** Bug 212708 has been marked as a duplicate of this bug. ***
Comment 7 Rami Rosen 2006-11-02 03:21:53 EST
>This patch lets me mount a test ufs2 filesystem.  Can you try this patch on your
>kernel?  I don't actually have a populated ufs2 filesystem to test further than
>a simple mount.  (I'd stick with read-only!)

I applied the patch frp, Comment #1  on Fedora Core 6 x86_64 and tried to mount 
a solaris ufs filesystem ; It did not work.
I got: 
  
mount: wrong fs type, bad option, bad superblock on /dev/hda3,
       missing codepage or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

when trying 
mount -t ufs -o ro /dev/hda3 /mnt/sol
mount -t ufs -o ro,ufstype=sunx86 /dev/hda3 /mnt/sol
mount -t ufs -o ro,ufstype=ufs2 /dev/hda3 /mnt/sol

Rami Rosen
Comment 8 Eric Sandeen 2006-11-02 09:15:34 EST
re: comment #7, and what did dmesg say after each mount failure?
Comment 9 Rami Rosen 2006-11-02 09:29:55 EST
Sorry, I should have mentioned it : the error were the same as before applying the 
patch.

Namely, dmesg showed in all three cases 
Nov  2 13:04:01 rh kernel: ufs_read_super: bad magic number

(In the first case , it also added a warning because of using the 
default "old" ufstype
Nov  2 13:04:01 rh kernel: >>>WARNING<<< Wrong ufstype may corrupt your filesystem
  , default is ufstype=old 


Rami Rosen
Comment 10 Eric Sandeen 2006-11-02 11:08:21 EST
Is there any chance you could dd out the first 256k or so of the filesystem,
and I can try a test on it here?  I don't have access to a solaris ufs image...

Otherwise maybe I can ring up a friend at Sun... :)

Thanks,
-Eric
Comment 11 Rami Rosen 2006-11-02 11:24:20 EST
Created attachment 140145 [details]
dump of dd if=/dev/sda5 of=/work/sda5.txt  bs=1K count=256
Comment 12 Eric Sandeen 2006-11-02 11:54:24 EST
It seems to work for me with the patch in place...

[root@neon tmp]# file sda5.txt
sda5.txt: Unix Fast File system (little-endian), last mounted on /mnt/solaris1,
last written at Thu Oct 26 09:45:25 2006, clean flag 253, number of blocks
20482875, number of data blocks 20172604, number of cylinder groups 417, block
size 8192, fragment size 1024, minimum percentage of free blocks 1, rotational
delay 0ms, disk rotational speed 60rps, TIME optimization
[root@neon tmp]# dd if=/dev/zero seek=167795712000 bs=1 count=1 of=ufsfile
[root@neon tmp]# dd if=sda5.txt of=ufsfile


[root@neon ufs]# mount -t ufs -o ufstype=sun,loop,ro ufsfile mnt/
[root@neon ufs]# mount | grep ufs
/src/ufs/ufsfile on /src/ufs/mnt type ufs (ro,loop=/dev/loop0,ufstype=sun)
[root@neon ufs]# umount mnt

[root@neon ufs]# mount -t ufs -o ufstype=sunx86,loop,ro ufsfile mnt/
[root@neon ufs]# umount mnt/

[root@neon ufs]# mount -t ufs -o loop,ro ufsfile mnt/
[root@neon ufs]# umount mnt/

can you point gdb at your patched ufs.ko module:

[root@neon ufs]# gdb ufs.ko
GNU gdb Red Hat Linux (6.3.0.0-1.134.fc5rh)
Copyright 2004 Free Software Foundation, Inc.
...

(gdb) print sizeof(struct ufs_super_block_third)
$1 = 356
(gdb)

and make sure that size is coming out as shown?
Comment 13 Rami Rosen 2006-11-02 13:08:47 EST
It works ! 

 My check was incorrect, sorry.

With the patch applied I am able to mount it thus:
mount -t ufs -o ro,ufstype=sunx86 /dev/sda5 /mnt/sol/


--
when mounting thus:
mount -t ufs -o ro,ufstype=sunx86 /dev/sda5 /mnt/sol/
I see in the kernel log the following:
Nov  2 20:06:52 rh kernel: ufs_read_super: can't grok fs_clean 0xfffffffd

but it is mounted nevertheless; 
mount |grep  ufs 
returns:
/dev/sda5 on /mnt/sol type ufs (ro)


Rami 

Comment 14 Eric Sandeen 2006-11-02 13:22:14 EST
Hmm.  That 0xfffffffd corresponds to the "clean flag" value of 253 (0xfd) in the
"file" output:

[root@neon ufs]# file /tmp/sda5.txt
/tmp/sda5.txt: Unix Fast File system (little-endian), last mounted on
/mnt/solaris1, last written at Thu Oct 26 09:45:25 2006, clean flag 253, number
of blocks 20482875, number of data blocks 20172604, number of cylinder groups
417, block size 8192, fragment size 1024, minimum percentage of free blocks 1,
rotational delay 0ms, disk rotational speed 60rps, TIME optimization

based on:
http://cvs.opensolaris.org/source/xref/on/usr/src/uts/common/sys/fs/ufs_fs.h

it looks like there are some solaris flag states that linux does not know:

/*
 * fs_clean values
 */
#define	FSACTIVE	((char)0)
#define	FSCLEAN		((char)0x1)
#define	FSSTABLE	((char)0x2)
#define	FSBAD		((char)0xff)	/* mounted !FSCLEAN and !FSSTABLE */
#define	FSSUSPEND	((char)0xfe)	/* temporarily suspended */
#define	FSLOG		((char)0xfd)	/* logging fs */
#define	FSFIX		((char)0xfc)	/* being repaired while mounted */

while the linux code only knows:
#define UFS_FSACTIVE  ((__s8)0x00)
#define UFS_FSCLEAN   ((__s8)0x01)
#define UFS_FSSTABLE  ((__s8)0x02)
#define UFS_FSOSF1    ((__s8)0x03)      /* is this correct for DEC OSF/1? */
#define UFS_FSBAD     ((__s8)0xff)

Looks like you have FSLOG.  But I think that is a bug for another day :)

Since you can mount now, can you close the osdl bug too?  It might be worth
logging a bug on this unknown clean state, but it is a separate issue from this bug.

Thanks!

-Eric
Comment 15 Rami Rosen 2006-11-02 15:41:13 EST
I had mentioned the message "can't grok fs_clean 0xfffffffd" only to 
draw your intention to it in order make sure it
does not cause problems elsewhere; and since it does not, this BUG is solved
and closed.
Rami 
Comment 16 Dave Jones 2006-11-12 00:48:41 EST
should be fixed in 2.6.18-1.2849.fc6 now in updates

Note You need to log in before you can comment on or make changes to this bug.