All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sunil Mushran <Sunil.Mushran@oracle.com>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] OCFS2 Features RFC
Date: Tue, 02 May 2006 13:29:11 -0700	[thread overview]
Message-ID: <4457C117.5000200@oracle.com> (raw)
In-Reply-To: <1146594129.4149.74.camel@brilong-lnx>

Brian Long wrote:
> Is there any reason you wouldn't ask the ocfs2-users community for
> feedback on features as well?  I hadn't subscribed to -devel because I
> figured it was solely for folks actually developing the OCFS2 code  :)
>   
-devel is for all discussion regarding ocfs2 development. It is not limited
to developers. We could have posted this to -users too, but I guess one is
trying not to cross the "spam" line.

> In my opinion, the proposed feature about "hard read only" is the most-
> wanted.  My team is in the middle of testing 10gR2 RAC on OCFS2 for
> production deployments on RHEL 4 (hopefully your x86_64 certification is
> coming soon).  I assume Oracle RAC would like the "hard read only" more
> than the current panic.
>
> Also, while I saw one end user complain about your ideas of implementing
> ext3 code inside OCFS2, please remember the rest of us that survive just
> fine with ext3 in Red Hat's Enterprise Linux.  :)
>   
:)

> Third, is there any thoughts on integrating LVM support or using
> something like Red Hat's CLVM to allow OCFS2 to layer on top of LVs
> instead of just individual disks?
>
> The biggest drawback I see in my environment is that my storage team
> provides 34GB and 68GB metas from the EMC Frames.  I'd rather not have a
> ton of 68GB OCFS2 filesystems but rather a larger, host-controlled LV.
> Trying to get the storage team to provide a 200+GB LUN and grow it on
> the fly in the future is a tough task.  If I could control the LV on the
> host _and_ grow OCFS2 into larger LVs, that would rock.
>   
We are looking into this.

  reply	other threads:[~2006-05-02 20:29 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-02 18:22 [Ocfs2-devel] OCFS2 Features RFC Brian Long
2006-05-02 20:29 ` Sunil Mushran [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-04-25 18:35 [Ocfs2-devel] OCFS2 features RFC Mark Fasheh
2006-04-25 21:55 ` Christoph Hellwig
2006-04-25 22:24   ` Mark Fasheh
2006-04-26 16:50   ` Daniel Phillips
2006-04-26  4:11 ` Andi Kleen
2006-04-26 18:06   ` Mark Fasheh
2006-04-26 18:08     ` Andi Kleen
2006-04-26 18:34       ` Daniel Phillips
2006-04-27 20:25 ` Paul Taysom
2006-05-11 20:04 ` Jeff Mahoney
2006-05-11 20:40   ` Paul Taysom
2006-05-11 20:55     ` Joel Becker
2006-05-11 21:16   ` Daniel Phillips
2006-05-17  1:44   ` Mark Fasheh
     [not found]     ` <446BBCF5.7040903@google.com>
     [not found]       ` <20060518024638.GY21588@ca-server1.us.oracle.com>
2006-05-19  0:35         ` Daniel Phillips
2006-05-19 15:16           ` J. Bruce Fields
2006-05-20  6:11           ` Mark Fasheh
2006-05-22 19:18             ` Daniel Phillips
2006-05-22 17:01     ` Paul Taysom

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=4457C117.5000200@oracle.com \
    --to=sunil.mushran@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.