On Fri, 2006-08-04 at 14:36 -0700, Joel Becker wrote:
> [Thanks for copying me on this]
>
> On Fri, Aug 04, 2006 at 01:53:45PM -0700, Matt Helsley wrote:
> > On Fri, 2006-08-04 at 13:11 -0700, Chandra Seetharaman wrote:
> > > On Fri, 2006-08-04 at 13:00 -0700, Andrew Morton wrote:
> > > > On Fri, 04 Aug 2006 12:14:23 -0700
> > > > Chandra Seetharaman <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > On Fri, 2006-08-04 at 00:20 -0700, Paul Menage wrote:
> ...snip...
> > > > > This is the plan. But, the configfs maintainer was not happy with that
> > > > > feature addition as it will make the file system more complex.
> > > >
> > > > In a contest between "complex" and "having some pathetic limitation",
> > > > we'll
> > > > take "complex".
> > > >
> > > > Did the configfs maintainer (was it Mark?) have some other proposed fix?
>
> I don't disagree with your "complex" vs "pathetic limitation"
> argument, but I don't see it that way. My proposed fix was that long
> data dumps belong in sysfs or procfs, not configfs. configfs is about
> creating objects and modifying attributes. It's not "configfs ||
> sysfs", it's "configfs && sysfs".
> Certainly creating groups via subdirs or even symlinks is also a
> valid configfs method. I'm not familiar with the ckrm requirements
> enough to be sure this is what they are talking about, but if they had a
> list of "things":
Joel,
Thanks for your reply.
I am confused with the usage model description.
>
>
> config/ckrm/things/
> 1
> 2
> 3
When is "things" created (at registration of subsystem or when user
creates a directory) ?
when are 1, 2, 3 created ?
Are 1,2 and 3 attributes that has a value associated ?
Are 1,2 and 3 attributes of "things" ?
>
> and a list of groups:
>
> config/ckrm/groups/
> family1
> family2
Are family1 and family2 "items" or attributes ?
How is family1 and family2 created ?
>
> then configfs' symlink is a great way to join them:
>
> ln -s config/ckrm/things config/ckrm/groups/family1
I am not able to come out file my basic filesystem usage to understand
this. I 'll look at configfs docs to understand this clearer.
> The callback for links allows access checks, and allows the ckrm code to
> do whatever internal linkage it wants. The symlink is internally a
> direct link (list_head) htat will lock family1 into place until the link
> is removed.
> I make this point because I got the impression from the bits
> below that you want to add things to these groups. Which makes sense.
> If your groups needed attributes, you could even have
>
> configfs/ckrm/groups
> family1
> attr1
> attr2
> members
>
> but you probably already guessed that.
Here is how RG/CKRM uses configfs:
- A Resource group is a group of tasks that uses specified amount of
resources.
- A Resource group is represented by a directory in configfs filesystem.
- Each directory has few attributes
- shares, list the amount of resource that group is allowed (rw)
- stats, usage statistics of the group (ro)
- members, list of tasks that are member of this group (rw)
- There can be subdirectories. they have same characteristics.
- Directories/subdirectories are created by user.
- By default, there is a high level directory, which also has the
same above mentioned characteristics.
The problem we have with is the members file, whose content could exceed
PAGE_SIZE when more than ~1000 tasks are in a group.
>
> > > > If not, a seq_file-based fix sounds OK to me. We don't have to actually
> > > > merge it until something which needs it is also in-tree, but a 1000-item
>
> Please, help me be VERY CAREFUL about this. configfs is not and
> was never designed to be a catch-all filesystem. It is purposely small
> and simple, so that it doesn't become the next sysfs or procfs. The
> more windows you allow people, the more they can screw up lifetimes &tc.
> If you need to dump a lot of data, sysfs and procfs can do this just
> fine. GFS2-DLM and OCFS2 both make use of configfs AND sysfs, doing
> config-y things in configfs and other things in sysfs.
> I've had the issue of large configuration bits in the back of my
> mind for a while, really. In general, I do not want to expose any
> generic "add some generic thing to the tree" functionality EVER, because
> that leads to the abuses we see in procfs and sysfs. The
> file-as-attribute mechanism it uses (and sysfs uses in the simpler
> cases) is a nicely locked down, purpose-based interface.
We choose configfs instead of sysfs after following the guidance in the
doc.
Basically we wanted a "file-system based manager of kernel object"
rather than a "file-system based view of a kernel object".
I think we could implement in sysfs also. But, doesn't sysfs also have
the PAGE_SIZE limitation.
> When I think about "Who else could take advantage of configfs?",
> the number one candidate I can think of is device-mapper. Something
> like:
>
> # mkdir config/dm/dm-0
> # echo linear > config/dm/dm-0/type
> # echo '0 2000 /dev/sda1 0' > config/dm/dm-0/table
> # echo 1 > config/dm/dm-0/live
>
> but this runs into the large attribute problem as well. device-mapper
> tables can easily be bigger than 4K, so config/dm/dm-N/table wouldn't be
> big enough.
> I'm open to suggestions as to how to create a "large attribute"
> type, but it really should be something that is purpose-based. configfs
> is for userspace to create a kernel object and get or set attributes on
> that object. That object might create its own interfaces in sysfs, it
> might do other things, who knows. "Large attribute" support should not
> be an open-ended chance to create another sysfs. If it belongs in
> sysfs, it belongs in sysfs, not configfs.
>
> > > > limit (depends on PAGE_SIZE, too?) is silly.
>
> PAGE_SIZE is a holdover from the sysfs attr code I ripped off.
> Perhaps MIN_PAGE_SIZE is better. 4K is as much as one should need for
> this. It's not right that an ia64 can put more data in than an x86.
> We should have a common size for an attr value across all platforms.
>
> Joel
>
--
----------------------------------------------------------------------
Chandra Seetharaman | Be careful what you choose....
- [EMAIL PROTECTED] | .......you may get it.
----------------------------------------------------------------------
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
ckrm-tech mailing list
https://lists.sourceforge.net/lists/listinfo/ckrm-tech
