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@xxxxxxxxxxx > >>>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@xxxxxxxxxxx > http://oss.sgi.com/mailman/listinfo/xfs -- --Carlos _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
