From: Steve Lord <lord@sgi.com>
To: "David A. Gatwood" <dgatwood@deepspace.mklinux.org>
Cc: flar@allandria.com, Andi Kleen <ak@suse.de>,
Steve Lord <lord@sgi.com>, Matthew Wilcox <matthew@wil.cx>,
Halfmann Klaus <khalfmann@libra.de>,
Roman Zippel <roman@augan.com>,
linuxppc-dev@lists.linuxppc.org, linux-fsdevel@vger.kernel.org
Subject: Re: Btree directories (Re: Status of HFS+ support)
Date: Wed, 30 Aug 2000 15:45:07 -0500 [thread overview]
Message-ID: <200008302045.PAA01483@jen.americas.sgi.com> (raw)
In-Reply-To: Message from "David A. Gatwood" <dgatwood@deepspace.mklinux.org> of "Wed, 30 Aug 2000 13:49:49 PDT." <Pine.LNX.3.96.1000830133511.10035C-100000@deepspace.mklinux.org>
> In my mind, this really screams the need for a pure vnode API in addition
> to keeping the current API for more traditional filesystems. You could
> then keep track of these complex keys with either a table or hashing
> method into slots/buckets with 32 bit identifiers, then provide these to
> the vnode layer. Sounds much easier than trying to make this look like a
> more traditional fs.
>
> Maybe someone could create a filesystem of type vnodefs that simply
> provides, through the current VFS, a pure vnode API that could be used by
> sub-filesystems (which would then absolutely be required to definitively
> probe for fs type automatically...). Thoughts?
>
It is not that clean at the moment, but we already have a vnode based system
hiding inside XFS, the linux inode has a vnode in the fs specific portion,
the linux inode ops call the VOPs. We still have as a work item to go back and
clean up this layer - it knows too much about XFS right now.
Not really sure if it maps onto what you are suggesting, but it is out there.
Steve
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2000-08-30 20:45 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-08-30 12:06 Btree directories (Re: Status of HFS+ support) Steve Lord
2000-08-30 15:07 ` Andi Kleen
2000-08-30 16:07 ` flar
2000-08-30 20:49 ` David A. Gatwood
2000-08-30 20:45 ` Steve Lord [this message]
2000-08-30 21:05 ` Alexander Viro
2000-08-30 21:51 ` David A. Gatwood
2000-08-30 21:49 ` Alexander Viro
2000-08-30 22:13 ` David A. Gatwood
2000-08-30 22:17 ` Alexander Viro
2000-08-30 23:11 ` David A. Gatwood
2000-08-31 0:10 ` Alexander Viro
2000-08-31 5:49 ` flar
2000-08-31 10:33 ` Alexander Viro
2000-08-31 17:48 ` flar
2000-08-31 19:54 ` Alexander Viro
2000-08-31 22:09 ` flar
2000-09-01 2:40 ` Alexander Viro
2000-09-01 3:52 ` flar
2000-09-02 4:04 ` Tony Mantler
-- strict thread matches above, loose matches on Subject: below --
2000-09-01 17:05 Halfmann, Klaus
2000-09-01 17:40 ` flar
2000-08-29 16:40 Status of HFS+ support (was hfs support for blocksize != 512) Halfmann, Klaus
2000-08-29 17:18 ` Btree directories (Re: Status of HFS+ support) Matthew Wilcox
2000-08-29 18:45 ` Steve Lord
2000-08-29 21:25 ` Matthew Wilcox
2000-08-30 2:22 ` flar
2000-08-30 8:35 ` Andi Kleen
2000-08-30 14:25 ` Chris Mason
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=200008302045.PAA01483@jen.americas.sgi.com \
--to=lord@sgi.com \
--cc=ak@suse.de \
--cc=dgatwood@deepspace.mklinux.org \
--cc=flar@allandria.com \
--cc=khalfmann@libra.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linuxppc-dev@lists.linuxppc.org \
--cc=matthew@wil.cx \
--cc=roman@augan.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).