From: Ben Myers <bpm@sgi.com>
To: Carlos Maiolino <cmaiolino@redhat.com>
Cc: xfs@oss.sgi.com
Subject: Re: inode64 superblock flag is still worth
Date: Fri, 22 Feb 2013 10:17:13 -0600 [thread overview]
Message-ID: <20130222161713.GV22182@sgi.com> (raw)
In-Reply-To: <20130222132721.GA10079@andromeda.usersys.redhat.com>
Hi Carlos,
On Fri, Feb 22, 2013 at 10:27:21AM -0300, Carlos Maiolino wrote:
> I was looking the "Ideas for XFS" wiki page, and noticed a topic about the
> implementation of a flag in superblock to identify the filesystem is using
> 64-bit inodes. Once we use it by default now, is this idea still worth? I can
> work on it, but I don't think this is still worth to be implemented.
> If still looks worth, I'd suggest a flag set when 32-bit inodes only is used not
> 64, but I really dunno how this might be useful for kernel. From a user
> perspective, it might help, but `mount` command or mtab already shows inode32
> option when it's used.
So the inode32 allocation policy becomes persistent and no longer need to be
set at mount time. This is definately worth working on, IMO.
Setting a bit in the superblock would work fine for inode32. We should think
about something more general before making on-disk changes for this. For
example, Rich recently posted the agskip data allocation policy which (like
inode32) was implemented as a mount option. If agskip=5 were to be made
persistent we'd need space in the superblock to keep track of the 5.
I think an xattr on the root inode could be a good solution as long as it is
invisible to the user. The interface for changing alloc policies should
probably be in xfs_io or xfs_mkfs.
-Ben
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-02-22 16:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-22 13:27 inode64 superblock flag is still worth Carlos Maiolino
2013-02-22 16:17 ` Ben Myers [this message]
2013-02-22 17:37 ` Carlos Maiolino
2013-02-23 0:55 ` Dave Chinner
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=20130222161713.GV22182@sgi.com \
--to=bpm@sgi.com \
--cc=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 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.