[OpenAFS] Strange Behavior of Openafs-1.1.1

[Steven N. Hirsch]

On Tue, 7 Aug 2001, Derrick J Brashear wrote:

> On Tue, 7 Aug 2001, Steven N. Hirsch wrote:
>
>
> > I _think_ that the ext3 patch is causing problems.  I've been through
> > exactly the same exercise.  When I backed out ext3, it worked.  I'm just
> > getting ready to try again with ext3 to ensure that I didn't have
> > something else horked up.
>
> did you include that bit of info before?

Yes and no.  It's my impression that I had failures even without the ext3
patch.  But, I've been changing so many things it's possible I confused
myself.

> > I looked throught the ext3 patch, and I'm wondering if this change to the
> > filesystem structures isn't the cause of grief (include/linux/fs.h):
> >
> >
> > @@ -374,8 +381,11 @@ struct address_space_operations {
> >  	int (*sync_page)(struct page *);
> >  	int (*prepare_write)(struct file *, struct page *, unsigned, unsigned);
> >  	int (*commit_write)(struct file *, struct page *, unsigned, unsigned);
> > +	void (*abort_write)(struct file *, struct page *);
> >  	/* Unfortunately this kludge is needed for FIBMAP. Don't use it */
> >  	int (*bmap)(struct address_space *, long);
> > +	int (*flushpage) (struct page *, unsigned long);
> > +	int (*releasepage) (struct page *, int);
> >  };
> >
> >  struct address_space {
> > @@ -432,6 +442,7 @@ struct inode {
> >  	unsigned long		i_blocks;
> >  	unsigned long		i_version;
> >  	struct semaphore	i_sem;
> > +	struct rw_semaphore	i_truncate_sem;
> >  	struct semaphore	i_zombie;
> >  	struct inode_operations	*i_op;
> >  	struct file_operations	*i_fop;	/* former ->i_op->default_file_ops */
> > @@ -460,6 +471,7 @@ struct inode {
> >  	union {
> >  		struct minix_inode_info		minix_i;
> >  		struct ext2_inode_info		ext2_i;
> > +		struct ext3_inode_info		ext3_i;
> >  		struct hpfs_inode_info		hpfs_i;
> >  		struct ntfs_inode_info		ntfs_i;
> >  		struct msdos_inode_info		msdos_i;
> >
> > Are address_space and address_space_operations two of the structs which
> > AFS needs to be "in sync" with?
>
> struct inode is, making
> i_truncate_sem
> relevant

Derrick,

Pardon my density, but I grepped the sources for anything that looked like
it was supposed to parallel those structures and found nothing except
an inline inclusion in osi_vfs.h.  Are you saying that this is filled
through clandestine means like memcpy?  If so, I can well understand the
problem.

> i will do the necessary work

Thanks.  I'd have been glad to if I had an inkling as to how that
structure was loaded.

Steve