From: Dipankar Sarma <dipankar@in.ibm.com>
To: viro@parcelfarce.linux.theplanet.co.uk
Cc: Patrick Mochel <mochel@osdl.org>,
Maneesh Soni <maneesh@in.ibm.com>, Greg KH <gregkh@us.ibm.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC 0/6] Backing Store for sysfs
Date: Tue, 7 Oct 2003 01:31:10 +0530 [thread overview]
Message-ID: <20031006200110.GA9908@in.ibm.com> (raw)
In-Reply-To: <20031006193050.GT7665@parcelfarce.linux.theplanet.co.uk>
On Mon, Oct 06, 2003 at 08:30:50PM +0100, viro@parcelfarce.linux.theplanet.co.uk wrote:
> On Tue, Oct 07, 2003 at 12:57:13AM +0530, Dipankar Sarma wrote:
> > sysfs currently uses dentries to represent filesystem hierarchy.
> > We want to create the dentries on the fly and age them out.
> > So, we can no longer use dentries to represent filesystem hierarchy.
> > Now, *something* has to represent the actual filesystem
> > hierarchy, so that dentries/inodes can be created on a lookup
> > miss based on that. So, what do you do here ? kobject and
> > its associates already represent most of the information necessary
> > for a backing store. Maneesh just added a little more to complete
> > what is equivalent of a on-disk filesystem. This allows vfs to
> > create dentries and inodes on the fly and age later on. Granted
> > that there are probably ugliness in the design to be sorted out
> > and it may have taken kobjects in a slightly different direction
> > than earlier, but it is not that odd when you look at it
> > from the VFS point of view.
>
> Rot. First of all, *not* *all* *kobjects* *are* *in* *sysfs*. And these
> are pure loss in your case.
gregkh pointed out this as well and that is why I said that Maneesh's
patch may have taken kobjects in a different direction than what
it was intended earlier. I don't disagree with this and it may
very well be that dentry ageing will have to be done differently.
>
> What's more important, for leaves of the sysfs tree your overhead is also
> a loss - we don't need to pin dentry down for them even with current sysfs
> design. And that can be done with minimal code changes and no data changes
> at all. Your patch will have to be more attractive than that. What's the
> expected ratio of directories to non-directories in sysfs?
ISTR, a large number of files in sysfs are attributes which are leaves.
So, keeping a kobject tree partially connected using dentries as backing
store as opposed to having everything connected might just be enough.
It will be looked into.
Thanks
Dipankar
next prev parent reply other threads:[~2003-10-06 19:58 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-06 8:59 [RFC 0/6] Backing Store for sysfs Maneesh Soni
2003-10-06 9:00 ` [RFC 1/6] sysfs-kobject.patch Maneesh Soni
2003-10-06 9:00 ` [RFC 2/6] sysfs-mount.patch Maneesh Soni
2003-10-06 9:01 ` [RFC 3/6] sysfs-file.patch Maneesh Soni
2003-10-06 9:01 ` [RFC 4/6] sysfs-symlink.patch Maneesh Soni
2003-10-06 9:02 ` [RFC 5/6] sysfs-attr_group.patch Maneesh Soni
2003-10-06 9:03 ` [RFC 6/6] sysfs-dir.patch Maneesh Soni
2003-10-06 13:43 ` [RFC 2/6] sysfs-mount.patch viro
2003-10-07 7:17 ` Maneesh Soni
2003-10-06 13:41 ` [RFC 1/6] sysfs-kobject.patch viro
2003-10-06 16:16 ` Greg KH
2003-10-06 17:41 ` Dipankar Sarma
2003-10-06 17:44 ` Greg KH
2003-10-06 16:08 ` [RFC 0/6] Backing Store for sysfs Greg KH
2003-10-06 17:31 ` Dipankar Sarma
2003-10-06 17:38 ` Greg KH
2003-10-06 18:01 ` Dipankar Sarma
2003-10-06 18:09 ` Greg KH
2003-10-06 18:31 ` Dipankar Sarma
2003-10-06 18:34 ` Greg KH
2003-10-07 9:08 ` Andreas Jellinghaus
2003-10-06 18:44 ` Patrick Mochel
2003-10-06 19:27 ` Dipankar Sarma
2003-10-06 19:30 ` viro
2003-10-06 20:01 ` Dipankar Sarma [this message]
2003-10-06 20:34 ` viro
2003-10-07 4:47 ` Maneesh Soni
2003-10-06 19:33 ` Patrick Mochel
2003-10-06 20:26 ` Dipankar Sarma
2003-10-06 20:29 ` Patrick Mochel
2003-10-07 4:31 ` Maneesh Soni
2003-10-07 5:25 ` Nick Piggin
2003-10-07 7:17 ` Maneesh Soni
-- strict thread matches above, loose matches on Subject: below --
2003-10-06 12:34 Christian Borntraeger
2003-10-06 17:38 Christian Borntraeger
2003-10-06 17:41 ` Greg KH
2003-10-06 18:00 ` Kevin P. Fleming
2003-10-06 18:11 ` Greg KH
2003-10-06 18:23 ` Kevin P. Fleming
2003-10-06 18:30 ` Greg KH
2003-10-06 18:38 ` Kevin P. Fleming
2003-10-07 8:30 ` Maneesh Soni
2003-10-06 18:19 Christian Borntraeger
[not found] <Dzxw.1wW.3@gated-at.bofh.it>
[not found] ` <DGfG.4UY.3@gated-at.bofh.it>
[not found] ` <DHv1.5Ir.1@gated-at.bofh.it>
[not found] ` <DHEU.7ET.19@gated-at.bofh.it>
[not found] ` <DHY6.3c0.7@gated-at.bofh.it>
[not found] ` <DI7S.58w.13@gated-at.bofh.it>
2003-10-06 19:01 ` Pascal Schmidt
2003-10-06 19:10 ` Greg KH
2003-10-07 0:15 ` Pascal Schmidt
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=20031006200110.GA9908@in.ibm.com \
--to=dipankar@in.ibm.com \
--cc=gregkh@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maneesh@in.ibm.com \
--cc=mochel@osdl.org \
--cc=viro@parcelfarce.linux.theplanet.co.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox