From: Arjan van de Ven <arjan@infradead.org>
To: Karel Zak <kzak@redhat.com>
Cc: Eric Sandeen <sandeen@redhat.com>,
Christoph Hellwig <hch@infradead.org>,
linux-ext4@vger.kernel.org, tytso@mit.edu
Subject: Re: [PATCH] ext3: sreadahead hooks
Date: Sun, 19 Oct 2008 20:51:17 -0700 [thread overview]
Message-ID: <20081019205117.737e02fe@infradead.org> (raw)
In-Reply-To: <20081019214204.GA11865@nb.net.home>
On Sun, 19 Oct 2008 23:42:05 +0200
Karel Zak <kzak@redhat.com> wrote:
> On Tue, Oct 14, 2008 at 04:49:51PM -0500, Eric Sandeen wrote:
> > Eric Sandeen wrote:
> > > Christoph Hellwig wrote:
> > >> On Tue, Oct 14, 2008 at 10:17:35AM -0400, Arjan van de Ven wrote:
> > >>> >From 3d7a0ca0ee8a755251251bd9ddca0866c25acdc2 Mon Sep 17
> > >>> >00:00:00 2001
> > >>> From: Arjan van de Ven <arjan@linux.intel.com>
> > >>> Date: Tue, 14 Oct 2008 10:12:08 -0400
> > >>> Subject: [PATCH] ext3: sreadahead hooks
> > >>>
> > >>> The sreadahead program, used to make the OS boot faster, needs
> > >>> to know in the approximate order in files are used during the
> > >>> boot process. This patch adds the ext3 hook for this
> > >>> functionality, basically it stores "jiffies" into the inode at
> > >>> allocation time, and exposes it via an EXT3 ioctl (yes I know
> > >>> but ioctl seems fitting for this).
> > >> Even if it's an ioctl there's absolutely no point in making this
> > >> fileystem specific. Also the name is rather dumb and
> > >> non-descriptive.
> > >
> > > I have to agree, both the ioctl name and the new field are not
> > > very descriptive - created_when sounds an awful lot like ctime
> > > but it's not.
> > >
> > > and INODE_JIFFIES really doesn't mean anything at all w/o extra
> > > context. But I'm trying to think of some nice names. :)
> > >
> > > What about making a new struct inode field and doing this update
> > > in new_inode(), and making it a generic ioctl. Are we ready to
> > > go that far?
> >
> > Or, as I thought about/mentioned to hch, and I guess he and Arjan
> > already discussed... :) why not just use tracing infrastructure to
> > get
>
> What do you mean by "tracing infrastructure"? Audit?
ftrace
I'll be looking into making that one work soon; it'll be... interesting
and more complex than this patch, but if that's what it takes...
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
prev parent reply other threads:[~2008-10-20 3:51 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-14 14:17 [PATCH] ext3: sreadahead hooks Arjan van de Ven
2008-10-14 15:13 ` Christoph Hellwig
2008-10-14 15:51 ` Eric Sandeen
2008-10-14 21:49 ` Eric Sandeen
2008-10-19 21:42 ` Karel Zak
2008-10-20 3:51 ` Arjan van de Ven [this message]
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=20081019205117.737e02fe@infradead.org \
--to=arjan@infradead.org \
--cc=hch@infradead.org \
--cc=kzak@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=sandeen@redhat.com \
--cc=tytso@mit.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.