From: Theodore Tso <tytso@mit.edu>
To: Jeff Shanab <jshanab@earthlink.net>
Cc: Rik van Riel <riel@redhat.com>, linux-kernel@vger.kernel.org
Subject: Re: Starting a grad project that may change kernel VFS. Early research Re: Starting a grad project that may change kernel VFS. Early research
Date: Tue, 25 Aug 2009 21:30:43 -0400 [thread overview]
Message-ID: <20090826013043.GB17684@mit.edu> (raw)
In-Reply-To: <4A9427C7.8020009@earthlink.net>
Something which I urge you to think about is whether optimizing du -s
is really worth it; this is not at all obvious. If it's going to cost
performance; if it's going to require non-backwards compatible changes
to filesystems; if it means introducing changes to the semantics of
hard links --- please *seriously* consider whether or not it's worth
it.
In what workload or use case is "du -s" something that gets done
frequently? And is it really worth adding code complexity and slowing
down much more common operations, such as writing files?
If the goal is do a project that gets you a master's degree or a
Ph.D., ok, fine; there are plenty of academic degrees and honors which
are given for ideas that are completely impractical and/or useless in
the real world.
If your goal is to create a feature that will be accepted into
mainline, then you need to provide a lot more justification that this
is actually a good and worthwhile thing to do, and that the benefits
outweigh the costs (in code complexity, long-term maintenance,
performance regressions, etc.)
- Ted
next prev parent reply other threads:[~2009-08-26 1:30 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-25 1:46 Starting a grad project that may change kernel VFS. Early research Re: Starting a grad project that may change kernel VFS. Early research Jeff Shanab
2009-08-25 17:28 ` Rik van Riel
2009-08-25 18:04 ` Jeff Shanab
2009-08-26 1:30 ` Theodore Tso [this message]
[not found] ` <4A94BF9E.2010101@earthlink.net>
[not found] ` <20090826130513.GM32712@mit.edu>
2009-08-26 14:42 ` Jeff Shanab
2009-08-26 15:09 ` Bryan Donlan
2009-08-26 12:18 ` Stefan Richter
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=20090826013043.GB17684@mit.edu \
--to=tytso@mit.edu \
--cc=jshanab@earthlink.net \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@redhat.com \
/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.