public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Carlos Maiolino <cmaiolino@redhat.com>
To: xfs@oss.sgi.com
Subject: Re: [PATCH] xfs: Update mount options documentation
Date: Thu, 18 Oct 2012 15:40:33 -0300	[thread overview]
Message-ID: <20121018184033.GA15782@andromeda.usersys.redhat.com> (raw)
In-Reply-To: <50803926.1010904@sgi.com>

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

  reply	other threads:[~2012-10-18 18:38 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2012-11-08 17:47             ` Ben Myers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20121018184033.GA15782@andromeda.usersys.redhat.com \
    --to=cmaiolino@redhat.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox