From: "Peter J. Braam" <braam@clusterfs.com>
To: <torvalds@osdl.org>, <akpm@osdl.org>, <linux-kernel@vger.kernel.org>
Cc: "'Phil Schwan'" <phil@clusterfs.com>
Subject: [PATCH/RFC] Lustre VFS patch
Date: Mon, 24 May 2004 19:39:50 +0800 [thread overview]
Message-ID: <20040524114009.96CE13100E2@moraine.clusterfs.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 5392 bytes --]
Hi Linus, Andrew & others,
Many people have asked me to have this patched reviewed, and
considered for inclusion in 2.6 after some reworking. At the kernel
summit last summer we discussed these issues.
This patch is not the Lustre file system, with client file system,
Lustre RPC, server code etc. This patch would enable people to run
Lustre with modules loading into unmodified kernels and this appears
to be something vendors really would like to see. FYI, at the moment
Lustre is a just a little bit larger than NFS, comparing clients,
servers, and rpc code for each (60K vs 80K lines of code).
This patch was written quite defensively: file systems not using
intents should really be completely unaffected.
I attach a little tar ball with patches and a series file which
describes the order of the patches. Below is a short description of
each of the patches. I also want to tell you a few things we have
worked on that are not present in this patch:
- deal with "pinning" directories that are CWD or mount points. They
should not be removable/unlinkable by remote nodes, and the FS needs
some indication of that.
- in Lustre d_parent is not necessarily valid, so sys_getcwd needs to
be careful. In Ottawa we discussed adding an optional hook.
- changes to NFSD to allow it to run on top of Lustre
- per file system locking operations (refinining i_sem) to allow
parallel updates in one directory.
It goes without saying that many people in CFS have made contributions
to this patch and that the ideas were heavily influenced by discussions
with the kernel community.
Please give me your thoughts about how we can move forward with this.
Regards,
- Peter -
dev_read_only-vanilla-2.6.patch
This introduces an ioctl on block devices to stop doing I/O. The
only purpose of the patch is automated recovery regression testing,
it is very convenient to have this available.
export-vanilla-2.6.patch
Export symbols used by Lustre.
header_guards-vanilla-2.6.patch
Small bug fix to avoid double inclusion of headers
lustre_version.patch
A tiny header to check that the kernel patch and Lustre modules are
compatible.
vfs-dcache_locking-vanilla-2.6.patch
A trivial patch to make functions available to lustre that do
d_move, d_rehash, without taking/dropping the dcache lock.
vfs-dcache_lustre_invalid-vanilla-2.6.patch
This allows dentries to be d_invalidate'd if a bit is set in the
FLAGS. This is required when dentries that are busy on the local
node are invalidated on another client system.
vfs-intent_api-vanilla-2.6.patch
Introduce intents for other operations. Add a file system hook to
release intent data. Make a few "intent versions" of functions such
as "lookup_one_len_it" and "user_walk_it" available through headers.
Arrange that the open intent is visible in the open methods. Add a
few missing intent_init calls.
vfs-intent_exec-vanilla-2.6.patch
Add intents for open in the context of execution.
vfs-intent_init-vanilla-2.6.patch
Add intent_init for all operations, not just for open.
vfs-intent_lustre-vanilla-2.6.patch
Add a pointer to per fs intent_data structure to the struct lookup_intent.
vfs-raw_ops-vanilla-2.6.patch
This adds raw operations for setattr, mkdir, rmdir, mknod, unlink,
symlink, link and rename. The raw operations look up the parent
directories (but not leaf nodes) involved in the operation and then
ask the file system to execute the operation. These methods allow
us to delegate the execution of these functions to the server, and
instantiate no dentries for leaf nodes, leaf nodes will only enter
the dcache on subsequent lookups. This patch dramatically
simplifies the client/server lock management, particularly for
rename.
In Ottawa Linus suggested that we could maybe do this with intents
instead. I feel that both are ugly, both are possible but intents
looked akward.
vfs-revalidate_counter-vanilla-2.6.patch
We found that dentries could be invalidated multiple times through
activity on remote nodes, but this shoudl not lead to failure in
Lustre. The revalidation path real_lookup was adapted to take a few
more iterations through the revalidation before giving up. This
revalidation takes the form of first revalidating, then looking up
if it fails, and possibly revalidating a few more times (see above)
until there is success.
vfs-revalidate_special-vanilla-2.6.patch
We add nameidata flags to indicate that a link sits in the middle of
the path and a flag that inidicates we are looking at the last
component of a path. [If someone knows if the existing flags could
detect this, that would be welcome.] To pass intents when the last
pathname component is a "." we insert a "special" revalidation
function that calls revalidate dentry when such a pathname is
traversed.
vfs_intent-flags_rename-vanilla-2.6.patch
As Linus requested in Ottawa last summer, rename intent.open.flags
to intent. it_flags and intent.open.create_mode to
intent.it_create_mode. Remove the union of "intents", which only
contained an open_intent, and replace it with a single struct
lookup_intent included in the nameidata.
vfs-do_truncate.patch
We added a parameter to do_truncate so that the FS can now if it is
being called from open or not.
[-- Attachment #2: linux-2.6.6-v1.0-lustre.tar.gz --]
[-- Type: application/x-gzip, Size: 14512 bytes --]
next reply other threads:[~2004-05-24 11:40 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-24 11:39 Peter J. Braam [this message]
2004-05-24 11:46 ` Jens Axboe
2004-05-25 1:48 ` braam
2004-05-25 6:47 ` Jens Axboe
2004-05-25 8:21 ` braam
2004-05-25 8:27 ` Jens Axboe
2004-05-25 10:52 ` Lars Marowsky-Bree
2004-05-25 11:45 ` braam
2004-05-25 13:35 ` Kevin Corry
2004-05-25 13:55 ` Jens Axboe
2004-05-24 12:00 ` hch
2004-05-24 12:01 ` hch
2004-05-24 12:03 ` hch
2004-05-24 15:33 ` Horst von Brand
2004-05-25 20:43 ` hch
2004-05-24 12:05 ` hch
2004-05-24 18:06 ` Trond Myklebust
2004-05-25 8:21 ` braam
2004-05-24 12:08 ` hch
2004-05-24 13:44 ` Arjan van de Ven
2004-05-24 13:53 ` viro
2004-05-28 16:56 ` braam
2004-05-28 17:00 ` Christoph Hellwig
2004-05-24 14:19 ` viro
2004-05-28 23:18 ` Maneesh Soni
2004-05-29 17:53 ` Anton Blanchard
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=20040524114009.96CE13100E2@moraine.clusterfs.com \
--to=braam@clusterfs.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=phil@clusterfs.com \
--cc=torvalds@osdl.org \
/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
all inboxes | Powered by JetHome®