* Re: inode64 superblock flag is still worth
2013-02-22 16:17 ` Ben Myers
@ 2013-02-22 17:37 ` Carlos Maiolino
2013-02-23 0:55 ` Dave Chinner
1 sibling, 0 replies; 4+ messages in thread
From: Carlos Maiolino @ 2013-02-22 17:37 UTC (permalink / raw)
To: Ben Myers; +Cc: xfs
Right, I'll take a look on how to implement it,
thanks Ben
On Fri, Feb 22, 2013 at 10:17:13AM -0600, Ben Myers wrote
> 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
--
Carlos
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: inode64 superblock flag is still worth
2013-02-22 16:17 ` Ben Myers
2013-02-22 17:37 ` Carlos Maiolino
@ 2013-02-23 0:55 ` Dave Chinner
1 sibling, 0 replies; 4+ messages in thread
From: Dave Chinner @ 2013-02-23 0:55 UTC (permalink / raw)
To: Ben Myers; +Cc: Carlos Maiolino, xfs
On Fri, Feb 22, 2013 at 10:17:13AM -0600, Ben Myers wrote:
> 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?
IMO, no.
> > 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.
What's the point? current kernels (and anything since about 2.6.28
(IIRC) support 64 bit inodes even on 32 bit machines. All that
adding a bit to the superblock will do is prevent these filesystems
from bein usable on older kernels, even when the kernel is perfectly
capable of working with that filesystem.
It's more trouble than it's worth at this point.
> > 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.
It has nothing to do with allocation policy, so I'd advise against
trying to conflate the two.
> 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.
Definitely not. The superblock is not a dumping ground for random
allocation policy configuration data.
FWIW, if you paid attention to the allocation policy patch set that I
pointed Rich at, allocation policies have to be defined in the
kernel code and there's support for up to 2^32 different
identifiers. IIRC, it allowed for 2^16 policy templates (e.g.
inode64 is a policy template) and 2^16 policy instances (e.g.
inode32 with agskip=2 is an instance, and inode32/agskip=4 is a
second instance). There is no way the superblock is big enough to
keep this sort of information in it, so we should not be even
thinking of doing that sort of hack for allocation policy data.
Storing allocatin policy template/instance information needs a
separate tree structure that allows rapid lookup and persistent
storage. e.g. in a btree. This is where the alloc policy patch set
was going - that it would use the generic btree infrastructure for
persistent storage of alloc policy information. It just never got
there....
> The interface for changing alloc policies should
> probably be in xfs_io or xfs_mkfs.
xfs_spaceman is intended to be the interface for manipulating stuff
like allocation policies, filessytem geometry information, etc.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 4+ messages in thread