From: Mark Fasheh <mark.fasheh@oracle.com>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] Extended Attribute Support?
Date: Thu, 8 Jun 2006 21:08:24 -0700 [thread overview]
Message-ID: <20060609040824.GT3082@ca-server1.us.oracle.com> (raw)
In-Reply-To: <355a4e960606072143q11e8a055vef0dca48b423a4bc@mail.gmail.com>
On Wed, Jun 07, 2006 at 09:43:47PM -0700, EKC wrote:
> I have a fourteen node cluster of dual dual-core opterons with local
> SATA disks that I was using for Lustre. My plan is to use aoe with
> DRBD mirroring between pairs of nodes (each node has two disks) for
> OCFS2.
Ok, so what's the maximum node count per shared disk here? 2 or 14? Either
value is easily within the range of what we test with here. Total nodes in
the cluster shouldn't really your performance.
> I am using the cluster to distribute the load for self-contained
> database-backed (mysql, Berkeley db, and o_append/mmap flat-file
> "databases") applications, each of which is hosted in its own vserver.
So one thing we don't support yet is shared writeable mmap. It looks like we
might have that going soon though, as David Howells has a patch in -mm which
makes that alot easier to implement in OCFS2.
> This use case becomes complicated because I need to quickly "clone"
> vservers. I've looked at layering unionfs or cowloop ontop of a
> cluster fs. However, my preference is to use vserver's COW support
> (hard-link two files and flag them as 'immutable' and 'unlink'; break
> the link and copy the files on write,chmod,chown).
After having read the vserver home page, their COW support seems promising,
but I'm unaware of how they implement that so I couldn't comment on OCFS2
interaction.
> My compute and storage needs are closely correlated. Filesystem reads
> dominate (80%) over writes. Directories are shared between nodes only
> in COW cases. Metadata operations and read/writes have a a lot of
> spatial locality. Cache coherency becomes an issue with the COW
> (hardlinking) requirement.
Ok, so mostly reads and with COW, writes look like they'll be mostly node
local. This is an optimum load for OCFS2 as you will not have many inodes
which have to be passed between nodes.
So taking into account node numbers and your expected load it seems like you
probably have a fair chance of making that work, assuming we get those
features you're missing.
Well, you certainly have an interesting use case, and I hope that OCFS2 can
accomodate your needs.
--Mark
--
Mark Fasheh
Senior Software Developer, Oracle
mark.fasheh at oracle.com
prev parent reply other threads:[~2006-06-09 4:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-07 11:35 [Ocfs2-devel] Extended Attribute Support? EKC
2006-06-07 16:45 ` Mark Fasheh
2006-06-08 0:47 ` EKC
2006-06-08 3:46 ` Mark Fasheh
2006-06-08 4:43 ` EKC
2006-06-09 4:08 ` Mark Fasheh [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=20060609040824.GT3082@ca-server1.us.oracle.com \
--to=mark.fasheh@oracle.com \
--cc=ocfs2-devel@oss.oracle.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.