All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Myers <bpm@sgi.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: Josef 'Jeff' Sipek <jeffpc@josefsipek.net>, xfs-oss <xfs@oss.sgi.com>
Subject: Re: [PATCH] default to 64 bit inodes & add feature flag
Date: Thu, 8 Mar 2012 09:37:21 -0600	[thread overview]
Message-ID: <20120308153721.GS7762@sgi.com> (raw)
In-Reply-To: <4F5813D8.8070305@sandeen.net>

On Wed, Mar 07, 2012 at 08:05:12PM -0600, Eric Sandeen wrote:
> On 3/7/12 7:34 PM, Dave Chinner wrote:
> > On Wed, Mar 07, 2012 at 11:20:57AM -0600, Eric Sandeen wrote:
> >> From: Dave Chinner <dchinner@redhat.com>
> >>
> >> Default to allowing 64-bit inodes on the filesystem.
> >>
> >> Add a feature bit to the the superblock to record whether 64 bit inodes have
> >> been allocated on the filesystem or not. This allows us to reject mounting the
> >> filesytem with inode32 if 64 bit inodes are present.
> >>
> >> Once a 64 bitinode is allocated, the inode64 superblock feature bit will be set.
> >> Once the superblock feature bit is set, the filesystem will default to 64 bit
> >> inodes regardless of whether inode64 is specified as a mount option.
> >>
> >> To ensure only 32 bit inodes are created, the inode32 mount option must be
> >> used. If there are already 64 bit inodes as flagged by the superblock feature
> >> bit, then the inode32 mount will be refused.
> >>
> >> Signed-off-by: Dave Chinner <dchinner@redhat.com>
> >> ---
> >>
> >> Passing this along to revive the old discussion ... 
> > 
> > I have no objections to do this. However, the kernel patch is just
> > the tip of the iceberg when it comes to implementing this.
> > 
> > Were there patches for userspace support of the feature bit? I don't
> > recall if there were. I'm thinking that xfs_info needs to output
> > whether this is set, which means the flag needs to be added to the
> > xfs geometry ioctls in the kernel.
> 
> Nope, you just put this patch out as a suggestion, and pointed out
> that userspace needed updates too.
> 
> If people are in agreement about this then we can proceed with the rest...

Please do.  I too have been burned by mounting a filesystem with big
inos without the correct mount option.  This is a great idea.

-Ben

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

  reply	other threads:[~2012-03-08 15:37 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-07 17:20 [PATCH] default to 64 bit inodes & add feature flag Eric Sandeen
2012-03-07 17:33 ` Josef 'Jeff' Sipek
2012-03-07 18:07   ` Arkadiusz Miśkiewicz
2012-03-08  1:34 ` Dave Chinner
2012-03-08  2:05   ` Eric Sandeen
2012-03-08 15:37     ` Ben Myers [this message]
2012-03-08 15:42       ` Eric Sandeen
2012-03-08 16:14         ` Josef 'Jeff' Sipek
2012-03-08 16:38         ` Ben Myers
2012-03-08 23:39           ` Dave Chinner
2012-03-08 23:41             ` Eric Sandeen
2012-03-09  2:08             ` 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=20120308153721.GS7762@sgi.com \
    --to=bpm@sgi.com \
    --cc=jeffpc@josefsipek.net \
    --cc=sandeen@sandeen.net \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.