On Wed, May 21, 2014 at 07:48:59AM -0700, Christoph Hellwig wrote: > On Fri, May 16, 2014 at 02:12:44PM -0400, Brian Foster wrote: > > Hi all, > > > > This is an rfc to get some discussion rolling on sysfs support for XFS. > > The motivation for this work is here: > > > > http://oss.sgi.com/archives/xfs/2014-05/msg00381.html > > All the sysfs magic for this looks pretty ugly. Why can't we just > dump it into debugfs given that it's very much a debug only feature > anyway? > Yeah, it kind of is. I think it also could get a bit worse as the dataset expands and we have to embed more kobjects in the various data structures. i.e., I think creating a full on directory structure in sysfs will involve a heirarchy of ksets/kobjects that would have to be instantiated and reclaimed as the associated subsystems are. debugfs seems like a reasonable suggestion. I think it's suitable for my initial purpose here (log leak detection), at least. Taking a first look through the debugfs code and some examples, it looks like there are some templates for simple/basic types, and then more customized items/output or things that require locking would require custom handlers. It appears we can associate a file with an object in memory. The desired directory structure is created more explicitly (debugfs_create_dir()), so we can still create an arbitrary directory structure. That and the fact that debugfs probably isn't considered ABI are positives to me. I suspect the debugfs interface means we'd probably want to combine the setup and teardown into a single path (i.e., xfs_init/fini_debugfs()), otherwise this would probably get just as ugly by carrying around debugfs directories in in-memory objects such that the infrastructure is available per-subsystem. We'd also have to consider that we might require active modification of the directory structure post-initialization (i.e., Dave's example included per AG attributes, so consider growfs). That could perhaps get ugly with this model vs. one that naturally updates as objects are instantiated/freed. So to me, the right approach seems like it depends on the grand scheme of things here. The wide and encompassing model with per-AG data and controls probably favors the sysfs model where individual files are managed via the individual objects. The current/initial use case probably favors using debugfs. I'd also be happy to start this off with debugfs and we can consider converting it to sysfs when the expanded use case is more defined and justified (though if use cases are clear to others, I'd prefer to do it correctly now rather than waste time converting back and forth). Thoughts? > It would also be really nitfy to have a tool to fronted it in the style > of xfs_db and xfs_io.. Perhaps, but what's the purpose of having a tool that just reads/writes these kind of attribute files? Something like that would be great were these controls exposed via ioctl(), of course, but the existence of sysfs/debugfs with per-file controls eliminates the need for that kind of custom tool IMO. Did you have additional functionality in mind? Thanks for looking at this... Brian _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
