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