[PATCH] xfs: Update mount options documentation

[PATCH] xfs: Update mount options documentation

[Carlos Maiolino]

Once inode64 is the default allocation mode now, kernel documentation should be
updated to match this behaviour.

Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
---
 Documentation/filesystems/xfs.txt | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/Documentation/filesystems/xfs.txt b/Documentation/filesystems/xfs.txt
index 3fc0c31..1718775 100644
--- a/Documentation/filesystems/xfs.txt
+++ b/Documentation/filesystems/xfs.txt
@@ -72,8 +72,15 @@ When mounting an XFS filesystem, the following options are accepted.
 	Indicates that XFS is allowed to create inodes at any location
 	in the filesystem, including those which will result in inode
 	numbers occupying more than 32 bits of significance.  This is
-	provided for backwards compatibility, but causes problems for
-	backup applications that cannot handle large inode numbers.
+	the default allocation option. Applications which do not handle
+	inode numbers bigger than 32 bits, should use inode32 option.
+
+  inode32
+	Indicates that XFS is limited to create inodes at locations which
+	will not result in inode numbers with more than 32 bits of
+	significance. This is provided for backwards compatibility, since
+	64 bits inode numbers might cause problems for some applications
+	that cannot handle large inode numbers.
 
   largeio/nolargeio
 	If "nolargeio" is specified, the optimal I/O reported in
-- 
1.7.11.7

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

Re: [PATCH] xfs: Update mount options documentation

[Mark Tinguely]

On 10/18/12 10:28, Carlos Maiolino wrote:
> Once inode64 is the default allocation mode now, kernel documentation should be
> updated to match this behaviour.
>
> Signed-off-by: Carlos Maiolino<cmaiolino@redhat.com>
> ---
>   Documentation/filesystems/xfs.txt | 11 +++++++++--
>   1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/filesystems/xfs.txt b/Documentation/filesystems/xfs.txt
> index 3fc0c31..1718775 100644
> --- a/Documentation/filesystems/xfs.txt
> +++ b/Documentation/filesystems/xfs.txt
> @@ -72,8 +72,15 @@ When mounting an XFS filesystem, the following options are accepted.
>   	Indicates that XFS is allowed to create inodes at any location
>   	in the filesystem, including those which will result in inode
>   	numbers occupying more than 32 bits of significance.  This is
> -	provided for backwards compatibility, but causes problems for
> -	backup applications that cannot handle large inode numbers.
> +	the default allocation option. Applications which do not handle
> +	inode numbers bigger than 32 bits, should use inode32 option.
> +
> +  inode32
> +	Indicates that XFS is limited to create inodes at locations which
> +	will not result in inode numbers with more than 32 bits of
> +	significance. This is provided for backwards compatibility, since
> +	64 bits inode numbers might cause problems for some applications
> +	that cannot handle large inode numbers.
>
>     largeio/nolargeio
>   	If "nolargeio" is specified, the optimal I/O reported in

An engineer that documents!

Would "Indicates that XFS is allowed to create inodes at locations up to
32 bits of significance .."

Do you want to add that it can still read/write/unlink the inodes 
numbered > 32 bits that were created via inode64?

--Mark Tinguely.

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

Re: [PATCH] xfs: Update mount options documentation

[Dave Howorth]

Mark Tinguely wrote:
> Would "Indicates that XFS is allowed to create inodes at locations up to
> 32 bits of significance .."

I prefer the original wording. Your suggestion says something about what
XFS can do, but nothing about what it is not allowed to do, which is
rather more important.

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

Re: [PATCH] xfs: Update mount options documentation

[Mark Tinguely]

On 10/18/12 11:00, Dave Howorth wrote:
> Mark Tinguely wrote:
>> Would "Indicates that XFS is allowed to create inodes at locations up to
>> 32 bits of significance .."
>
> I prefer the original wording. Your suggestion says something about what
> XFS can do, but nothing about what it is not allowed to do, which is
> rather more important.
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

I see your point. Sounds good to me.

--Mark.

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

Re: [PATCH] xfs: Update mount options documentation

[Carlos Maiolino]

On Thu, Oct 18, 2012 at 11:05:32AM -0500, Mark Tinguely wrote:
> On 10/18/12 11:00, Dave Howorth wrote:
> >Mark Tinguely wrote:
> >>Would "Indicates that XFS is allowed to create inodes at locations up to
> >>32 bits of significance .."
> >
> >I prefer the original wording. Your suggestion says something about what
> >XFS can do, but nothing about what it is not allowed to do, which is
> >rather more important.
> >
> >_______________________________________________
> >xfs mailing list
> >xfs@oss.sgi.com
> >http://oss.sgi.com/mailman/listinfo/xfs
> 
> I see your point. Sounds good to me.
> 
> --Mark.
> 
This means no change is needed?

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

-- 
--Carlos

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

Re: [PATCH] xfs: Update mount options documentation

[Mark Tinguely]

On 10/18/12 12:04, Carlos Maiolino wrote:
> On Thu, Oct 18, 2012 at 11:05:32AM -0500, Mark Tinguely wrote:
>> On 10/18/12 11:00, Dave Howorth wrote:
>>> Mark Tinguely wrote:
>>>> Would "Indicates that XFS is allowed to create inodes at locations up to
>>>> 32 bits of significance .."
>>>
>>> I prefer the original wording. Your suggestion says something about what
>>> XFS can do, but nothing about what it is not allowed to do, which is
>>> rather more important.
>>>
>>> _______________________________________________
>>> xfs mailing list
>>> xfs@oss.sgi.com
>>> http://oss.sgi.com/mailman/listinfo/xfs
>>
>> I see your point. Sounds good to me.
>>
>> --Mark.
>>
> This means no change is needed?
>

I am okay with what is written about creating inodes.

On a separate question, should something be mentioned that inode32 mode 
can still read/write/unlink any inode, even those number greater than 32 
bit, or will that confuse the inode creation point?

--Mark.


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

Re: [PATCH] xfs: Update mount options documentation

[Carlos Maiolino]

On Thu, Oct 18, 2012 at 12:15:18PM -0500, Mark Tinguely wrote:
> On 10/18/12 12:04, Carlos Maiolino wrote:
> >On Thu, Oct 18, 2012 at 11:05:32AM -0500, Mark Tinguely wrote:
> >>On 10/18/12 11:00, Dave Howorth wrote:
> >>>Mark Tinguely wrote:
> >>>>Would "Indicates that XFS is allowed to create inodes at locations up to
> >>>>32 bits of significance .."
> >>>
> >>>I prefer the original wording. Your suggestion says something about what
> >>>XFS can do, but nothing about what it is not allowed to do, which is
> >>>rather more important.
> >>>
> >>>_______________________________________________
> >>>xfs mailing list
> >>>xfs@oss.sgi.com
> >>>http://oss.sgi.com/mailman/listinfo/xfs
> >>
> >>I see your point. Sounds good to me.
> >>
> >>--Mark.
> >>
> >This means no change is needed?
> >
> 
> I am okay with what is written about creating inodes.
> 
> On a separate question, should something be mentioned that inode32
> mode can still read/write/unlink any inode, even those number
> greater than 32 bit, or will that confuse the inode creation point?
> 
I thought about this when modifying the documentation, but, to be honest I was
wondering if this might not cause more confusion than expected. 

For example,
afaik, one of the principal reasons we still keep an inode32 allocator is due
applications which cannot handle 64bit inodes. So, I suppose that users which
will use inode32 are those who really needs 32bit inodes for this kind of
'problem'.

Saying that inode32 mode can still read 64bit inodes might (IMHO) lead users,
*think* they won't have problems with larger inodes just by using inode32 mode,
when, AFAICT, they'll have the same problems with their applications and larger
inode numbers if they have any inode allocated beyong 32bit limit. even using
inode32 mode.

So, I believe that, not saying it will "force" users who need 32bit inodes to
use inode32 since its first inode allocation, instead of think they'll fix their
problems only switching to inode32 mode after they already had lots of 64bit
inodes allocated.



Hopefully I didn't create more confusion around it :-)

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

-- 
--Carlos

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

Re: [PATCH] xfs: Update mount options documentation

[Ben Myers]

Hey Carlos,

On Thu, Oct 18, 2012 at 03:40:33PM -0300, Carlos Maiolino wrote:
> On Thu, Oct 18, 2012 at 12:15:18PM -0500, Mark Tinguely wrote:
> > On 10/18/12 12:04, Carlos Maiolino wrote:
> > >On Thu, Oct 18, 2012 at 11:05:32AM -0500, Mark Tinguely wrote:
> > >>On 10/18/12 11:00, Dave Howorth wrote:
> > >>>Mark Tinguely wrote:
> > >>>>Would "Indicates that XFS is allowed to create inodes at locations up to
> > >>>>32 bits of significance .."
> > >>>
> > >>>I prefer the original wording. Your suggestion says something about what
> > >>>XFS can do, but nothing about what it is not allowed to do, which is
> > >>>rather more important.
> > >>>
> > >>>_______________________________________________
> > >>>xfs mailing list
> > >>>xfs@oss.sgi.com
> > >>>http://oss.sgi.com/mailman/listinfo/xfs
> > >>
> > >>I see your point. Sounds good to me.
> > >>
> > >>--Mark.
> > >>
> > >This means no change is needed?
> > >
> > 
> > I am okay with what is written about creating inodes.
> > 
> > On a separate question, should something be mentioned that inode32
> > mode can still read/write/unlink any inode, even those number
> > greater than 32 bit, or will that confuse the inode creation point?
> > 
> I thought about this when modifying the documentation, but, to be honest I was
> wondering if this might not cause more confusion than expected. 
> 
> For example,
> afaik, one of the principal reasons we still keep an inode32 allocator is due
> applications which cannot handle 64bit inodes. So, I suppose that users which
> will use inode32 are those who really needs 32bit inodes for this kind of
> 'problem'.
> 
> Saying that inode32 mode can still read 64bit inodes might (IMHO) lead users,
> *think* they won't have problems with larger inodes just by using inode32 mode,
> when, AFAICT, they'll have the same problems with their applications and larger
> inode numbers if they have any inode allocated beyong 32bit limit. even using
> inode32 mode.
> 
> So, I believe that, not saying it will "force" users who need 32bit inodes to
> use inode32 since its first inode allocation, instead of think they'll fix their
> problems only switching to inode32 mode after they already had lots of 64bit
> inodes allocated.
> 
> 
> 
> Hopefully I didn't create more confusion around it :-)

    I pulled in the original version of this on Nov 2.  That version looked fine to me. ;)

Regards,
	Ben

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