Re: [PATCH] Make inode64 a remountable option

[Carlos Maiolino <cmaiolino@redhat.com>]

> Reviewed-by: Brian Foster <bfoster@redhat.com>
> 
> I do have a question though... do we care about the remount from inode64
> to non-inode64 case?
> 
I thought about it, but, once we enable inode64 option, remounting it back to
inode32 may create problems to access inodes greater than (1<<32) - 1, so, I
don't think we should make inode32 a remountable option.

My point of view though.
> > ---
> >  fs/xfs/xfs_super.c | 18 +++++++++++++++++-
> >  1 file changed, 17 insertions(+), 1 deletion(-)
> > 
> > diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c
> > index bdaf4cb..4dad567 100644
> > --- a/fs/xfs/xfs_super.c
> > +++ b/fs/xfs/xfs_super.c
> > @@ -120,12 +120,13 @@ mempool_t *xfs_ioend_pool;
> >   * in the future, too.
> >   */
> >  enum {
> > -	Opt_barrier, Opt_nobarrier, Opt_err
> > +	Opt_barrier, Opt_nobarrier, Opt_inode64, Opt_err
> >  };
> >  
> >  static const match_table_t tokens = {
> >  	{Opt_barrier, "barrier"},
> >  	{Opt_nobarrier, "nobarrier"},
> > +	{Opt_inode64, "inode64"},
> >  	{Opt_err, NULL}
> >  };
> >  
> > @@ -1038,11 +1039,15 @@ xfs_fs_remount(
> >  {
> >  	struct xfs_mount	*mp = XFS_M(sb);
> >  	substring_t		args[MAX_OPT_ARGS];
> > +	xfs_sb_t		*sbp = &(mp->m_sb);
> > +	xfs_perag_t		*pag;
> >  	char			*p;
> >  	int			error;
> >  
> >  	while ((p = strsep(&options, ",")) != NULL) {
> >  		int token;
> > +		int agcount = sbp->sb_agcount;
> > +		int index = 0;
> >  
> >  		if (!*p)
> >  			continue;
> > @@ -1055,6 +1060,17 @@ xfs_fs_remount(
> >  		case Opt_nobarrier:
> >  			mp->m_flags &= ~XFS_MOUNT_BARRIER;
> >  			break;
> > +		case Opt_inode64:
> > +
> > +			for (index = 0; index < agcount; index++) {
> > +				pag = xfs_perag_get(mp, index);
> > +				pag->pagi_inodeok = 1;
> > +				xfs_perag_put(pag);
> > +			}
> > +			mp->m_flags &= ~XFS_MOUNT_32BITINODES;
> > +			mp->m_flags &= ~XFS_MOUNT_SMALL_INUMS;
> > +			mp->m_maxagi = index;
> > +			break;
> >  		default:
> >  			/*
> >  			 * Logically we would return an error here to prevent
> > 
> 

-- 
--Carlos

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs