* [PATCH] xfs: Update mount options documentation @ 2012-10-18 15:28 Carlos Maiolino 2012-10-18 15:50 ` Mark Tinguely 0 siblings, 1 reply; 8+ messages in thread From: Carlos Maiolino @ 2012-10-18 15:28 UTC (permalink / raw) To: xfs 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 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH] xfs: Update mount options documentation 2012-10-18 15:28 [PATCH] xfs: Update mount options documentation Carlos Maiolino @ 2012-10-18 15:50 ` Mark Tinguely 2012-10-18 16:00 ` Dave Howorth 0 siblings, 1 reply; 8+ messages in thread From: Mark Tinguely @ 2012-10-18 15:50 UTC (permalink / raw) To: Carlos Maiolino; +Cc: xfs 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] xfs: Update mount options documentation 2012-10-18 15:50 ` Mark Tinguely @ 2012-10-18 16:00 ` Dave Howorth 2012-10-18 16:05 ` Mark Tinguely 0 siblings, 1 reply; 8+ messages in thread From: Dave Howorth @ 2012-10-18 16:00 UTC (permalink / raw) To: xfs 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] xfs: Update mount options documentation 2012-10-18 16:00 ` Dave Howorth @ 2012-10-18 16:05 ` Mark Tinguely 2012-10-18 17:04 ` Carlos Maiolino 0 siblings, 1 reply; 8+ messages in thread From: Mark Tinguely @ 2012-10-18 16:05 UTC (permalink / raw) To: Dave Howorth; +Cc: xfs 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] xfs: Update mount options documentation 2012-10-18 16:05 ` Mark Tinguely @ 2012-10-18 17:04 ` Carlos Maiolino 2012-10-18 17:15 ` Mark Tinguely 0 siblings, 1 reply; 8+ messages in thread From: Carlos Maiolino @ 2012-10-18 17:04 UTC (permalink / raw) To: xfs 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] xfs: Update mount options documentation 2012-10-18 17:04 ` Carlos Maiolino @ 2012-10-18 17:15 ` Mark Tinguely 2012-10-18 18:40 ` Carlos Maiolino 0 siblings, 1 reply; 8+ messages in thread From: Mark Tinguely @ 2012-10-18 17:15 UTC (permalink / raw) To: xfs 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] xfs: Update mount options documentation 2012-10-18 17:15 ` Mark Tinguely @ 2012-10-18 18:40 ` Carlos Maiolino 2012-11-08 17:47 ` Ben Myers 0 siblings, 1 reply; 8+ messages in thread From: Carlos Maiolino @ 2012-10-18 18:40 UTC (permalink / raw) To: xfs 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] xfs: Update mount options documentation 2012-10-18 18:40 ` Carlos Maiolino @ 2012-11-08 17:47 ` Ben Myers 0 siblings, 0 replies; 8+ messages in thread From: Ben Myers @ 2012-11-08 17:47 UTC (permalink / raw) To: xfs 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2012-11-08 17:45 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-10-18 15:28 [PATCH] xfs: Update mount options documentation Carlos Maiolino 2012-10-18 15:50 ` Mark Tinguely 2012-10-18 16:00 ` Dave Howorth 2012-10-18 16:05 ` Mark Tinguely 2012-10-18 17:04 ` Carlos Maiolino 2012-10-18 17:15 ` Mark Tinguely 2012-10-18 18:40 ` Carlos Maiolino 2012-11-08 17:47 ` Ben Myers
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox