[Ocfs2-devel] Bug in ocfs_file_entry struct for 2.6

[Ocfs2-devel] Bug in ocfs_file_entry struct for 2.6

[Villalovos, John L]

I was looking at the ocfs_file_entry struct in inc/ocfs.h

I noticed that it defines:

    __u16 dev_major;                  // NUMBER RANGE(0,65535)
    __u16 dev_minor;                  // NUMBER RANGE(0,65535)

So dev_major is not going to have a problem because they use 12 bits to
hold the major number.

But the dev_minor entry will be a problem because they use 20 bits to
hold the minor number in the 2.6.x kernel.

From a quick look at the code I'm not sure that this is an easy fix.  It
doesn't look like we can just change the structure (unless they have
__u20 and __u12 type variables??).  I'm saying that it doesn't look like
an easy fix because I think that this structure is put as is on the
disk, but maybe I am mistaken.

John



typedef struct _ocfs_file_entry         // CLASS
{
        ocfs_disk_lock disk_lock;       // DISKLOCK
        __u8 signature[8];              // CHAR[8]
        bool local_ext;                 // BOOL
        __u8 next_free_ext;             // NUMBER
RANGE(0,OCFS_MAX_FILE_ENTRY_EXTENTS)
        __s8 next_del;                  // DIRNODEINDEX
        __s32 granularity;              // NUMBER RANGE(-1,3)
        __u8 filename[OCFS_MAX_FILENAME_LENGTH];  //
CHAR[OCFS_MAX_FILENAME_LENGTH]
        __u16 filename_len;               // NUMBER
RANGE(0,OCFS_MAX_FILENAME_LENGTH)
        __u64 file_size;                  // NUMBER
RANGE(0,ULONG_LONG_MAX)
        __u64 alloc_size;                       // NUMBER
RANGE(0,ULONG_LONG_MAX)
        __u64 create_time;                // DATE
        __u64 modify_time;              // DATE
        ocfs_alloc_ext extents[OCFS_MAX_FILE_ENTRY_EXTENTS];  //
EXTENT[OCFS_MAX_FILE_ENTRY_EXTENTS]
        __u64 dir_node_ptr;               // NUMBER
RANGE(0,ULONG_LONG_MAX)
        __u64 this_sector;                // NUMBER
RANGE(0,ULONG_LONG_MAX)
        __u64 last_ext_ptr;               /* NUMBER
RANGE(0,ULONG_LONG_MAX)
                                             Points to the last
                                             allocated extent */
        __u32 sync_flags;                 // NUMBER RANGE(0,0)
        __u32 link_cnt;                   // NUMBER RANGE(0,UINT_MAX)
        __u32 attribs;                    // ATTRIBS
        __u32 prot_bits;                  // PERMS
        __u32 uid;                        // UID
        __u32 gid;                        // GID
        __u16 dev_major;                  // NUMBER RANGE(0,65535)
        __u16 dev_minor;                  // NUMBER RANGE(0,65535)
/* 32-bit: sizeof(fe) = 484 bytes */
/* 64-bit: sizeof(fe) = 488 bytes */
/* Need to account for that fact when the struct is extended. */
}
ocfs_file_entry;                          /

[Ocfs2-devel] Bug in ocfs_file_entry struct for 2.6

[Mark Fasheh]

On Fri, Mar 19, 2004 at 03:15:11PM -0800, Villalovos, John L wrote:
> I was looking at the ocfs_file_entry struct in inc/ocfs.h
> 
> I noticed that it defines:
> 
>     __u16 dev_major;                  // NUMBER RANGE(0,65535)
>     __u16 dev_minor;                  // NUMBER RANGE(0,65535)
> 
> So dev_major is not going to have a problem because they use 12 bits to
> hold the major number.
> 
> But the dev_minor entry will be a problem because they use 20 bits to
> hold the minor number in the 2.6.x kernel.
> 
> >From a quick look at the code I'm not sure that this is an easy fix.  It
> doesn't look like we can just change the structure (unless they have
> __u20 and __u12 type variables??).  I'm saying that it doesn't look like
> an easy fix because I think that this structure is put as is on the
> disk, but maybe I am mistaken.
Yeah, that's a bug. The quick consensus 'round here is that nobody uses
char/block devices on ocfs at the moment, so it's ok to just mash those two
__u16's together as a __u32 (preferably in the code which requres it) and
just treat it as such (un-mashing them when we need to put it back into the
fe). As long as the behavior is documented, I think we're OK.
	--Mark

--
Mark Fasheh
Software Developer, Oracle Corp
mark.fasheh@oracle.com

[Ocfs2-devel] Bug in ocfs_file_entry struct for 2.6

[Joel Becker]

On Fri, Mar 19, 2004 at 03:58:52PM -0800, Mark Fasheh wrote:
> > I noticed that it defines:
> > 
> >     __u16 dev_major;                  // NUMBER RANGE(0,65535)
> >     __u16 dev_minor;                  // NUMBER RANGE(0,65535)

	The write answer is to make it __u32 rdev, and then use the
proper MAJOR/MINOR/major/minor/to_kdev_t routines on it.  This is what
all other filesystems do.

Joel

-- 

Life's Little Instruction Book #15

	"Own a great stereo system."

Joel Becker
Senior Member of Technical Staff
Oracle Corporation
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127