[Gllug] Raw Partitions

[Steve Nelson]

On 11/22/05, Peter Grandi <pg_gllug at gllug.for.sabi.co.uk> wrote:
> >>> On Thu, 17 Nov 2005 11:40:12 +0000, Steve Nelson
> >>> <sanelson at gmail.com> said:
>
> [ ... ]
>
> sanelson> You constant nit-picking helps no-one on the list.
>
> Well, somone's nitpicking is someone else's attempt to avoid
> ambiguities that cost dozen of lines of pointless exchange.

There was nothing ambiguous in the orginal post. Read it.

> What you clearly meant may not be so clear to someone who is a
> poor untelepath... To me, relying only on your written words,
> the mention of 'sg_dd' clouded the issue as to SGIO to SCSI
> discs or 'raw'(8), also because there was initially not enough
> mention of the context (Oracle/GFS) that would have swung the
> odds in favour of 'sg_dd' being incidential and 'raw'(8)
> essential, and not viceversa...

Peter.  Please.  For everyone's sanity, just read the original post. 
You introduced confusing and unnecessary variables into a very simple
question.

> sanelson> [ ... ] Had this question been about a GFS pool I
> sanelson> would have mentioned it.
>
> Let me say that it seems to me that your record so far as to
> asking questions with relevant context and details is a bit
> below ''clueless''.

Do provide examples from the last 3 years Peter.  I will gladly take
constructive criticism from anyone, but I think you'll find this is
another of your groundless assertions.

> And where would one do cache-bypassing for RH GFS? For pools
> usually (with 'O_DIRECT' though)...

Pools have nothing to do with it.  Read the documentation,

> sanelson> AT LAST!  Something genuinely helpful.  Thank you.
>
> But this confuses me -- this is a trivial, obvious point for
> which I was braced for ''of course I know that''.  Since it is
> so obvious I was wondering whether you had any special reasons
> for not doing it already, and that's the only reason I mentioned
> it.

I repeat.  Thank you for mentioning it.  It hadn't occurred to me, and
its a helpful and useful suggestion.  More of these wouldn't go amiss.

> sanelson> [ ... ] It is clear by now I am using RHEL 3 with a
> sanelson> 2.4 kernel. Raw devices are *not* deprecated under
> sanelson> this system.
>
> But you omitted to mention both RH and 2.4 initially, that's why
> I mentioned it was deprecated, and thanks a lot for blasting
> people because you are too clueless to give enough context.

It was irrelevant.  Read the original post.  I might make this into an
acronymn in a minute.

> Also please use "deprecated" in a less confused way, as it is
> not the same as "unsupported"; in a technical context its
> meaning is:
>
>   ''it is still in the current and previous version, but it will
>     be removed in some future version''

Thank you.  Correction received and noted.

> sanelson> [ ... ]  You however, appear to have cherry-picked
> sanelson> from it, [ ... ]
>
> No, I simply did a string search for "raw" or "quorum" in the
> GFS manual and nothing relevant came up, but "O_DIRECT", the
> direct alternative to 'raw'(8), did come up. This suggests to
> me that is the standard way to bypass the cache on GFS.

That sounds a lot like cherry-picking to me.  Try reading it instead
of doing string searches.

> But it is the case mentioned in the manual relevant to the
> products you have mentioned, and since you seem to like playing
> the ''not telling you'' game, that's all I have got.

I didn't tell you the details of my system because it had *NOTHING* to
do with the original question.  And your attempts to second guess, and
throw the results of your random googling into the thread as a
substitute for a considered answer are less than helpful

> Let's try again: practically minded people use sw that is widely
> used so that it has been thoroughly exercised (and even so...).
> Combinations of sw that are not widely used (e.g.: on several
> hundred thousand desktops) are to be regarded as ''brave''.

Agreed, but I really don't see how that is relevant.

Practically minded people also carry penknives or screwdrivers around
- what's your point?

> In particular where there are parallel accesses, and multiple
> layers of wrapping and virtualization. That's basically why only
> very specific combinations of kernel/CM/CFS/DBMS versions and
> types are ''qualified'' (which sometimes means just ''it worked
> here for 5 minutes'' :->) by vendors.

Ok... still missing the point.

> Also, RH EL 3 comes with a kernel (if you are using the standard
> kernel) which has an optimization with a well known limitation
> that usually manifests itself when there are several complicated
> software subsystems running concurrently. Unfortunately this
> limitation has different impacts on different systems and
> architectures.

Ok... again some evidence for this would be interesting, but I still
don't see the point.

For the record this is a very simple installation.  RHEL 3, using
Redhat Cluster Suite (by which I mean the suite of tools including in
this case GFS 6.0 which allow for a dynamic failover solution for an
Oracle database) and Oracle 10g.  None of that is especially
bleeding-edge, Peter.

> [ ... detailed questions ... ]
>
> sanelson> Yes - if I was asking for help with troubleshooting my
> sanelson> cluster - which, incidentally, I am not.
>
> But you are asking with help in setting up a troubleshooting
> environment for crashes related to 'raw'(8), and how 'raw'(8) is
> used and by which app and in which context is highly relevant.

Ok agreed.  The question was related to crases related to raw. 
However, that was not what I was asking.  Had I wanted to ask about
that (and I might have done) I would.  But I didn't.  I already had
several avenues of enquiry aside from this list, and decided not to
mention the specific question on this list.  Had I wanted to, you can
be assured that I would have provided detailed context.  Had I not, I
would expect to be corrected.

> In particular, many issues happen only because of combinations
> of usage patterns, and in order to troubleshoot devices one
> should try to recreate an environment as similar as possible
> to the production one.

I agree.

>   Naturally you can believe oherwise, as you indeed seem to, but
>   then ''clueless is as clueless does'' :-).

Ok Peter.

> And how it is used and in which context might suggest fallbacks,
> because if 'raw'(8)' crashes, the product using it might well be
> able to use alternatives or not use 'raw'(8) at all, and not
> using something that crashes is also a way to fix it, and to
> sidestep any issues as to setting up 'raw'(8) troubleshooting.

A good point.

> No, it is rather that you seem foolishly keen to show off just
> how thoroughly confused you are, as this is the first time you
> mention that product, while so far you have been stating
> unambiguosly (yet confusedly) that you have had problems with
> GFS 6.0 raw devices and/or with Oracle:

Peter - please please just stop.  This is a tiring a trivial argument
that is just making you look more and more foolish.  GFS is a cluster
filesystem.  I am using it as part of / alongside the suite of
clustering tools commonly referred to as Redhat Cluster Suite.

> The combination of these statements and the lack of previous
> mention of RH CS seems fairly unambiguous to me...

That, Peter, is probably because you've either never seen or
administered such a system, or simply not read the documentation, or
not engaged your brain.   Or all of the above.

> Well, RH CS is yet another cluster-related package, but it is a
> completely different product from RH GFS, as you could have
> gleaned from reading its presentation here:

Peter, I know what it is.  I am using it.  It really isn't necessary
for you to be patronising and assume people do not know what they are
talking about.  The fact they are different does not mean they cannot
be used together.

>    «For applications that require maximum uptime, a Red Hat
>     Enterprise Linux cluster with Red Hat Cluster Suite is the
>     answer. Specifically designed for Red Hat Enterprise Linux,
>     Red Hat Cluster Suite provides two distinct types of
>     clustering:
>
>     * Application/Service Failover - Create n-node server clusters
>       for failover of key applications and services

Yes, Peter.  And one element of this is a cluster filesystem.  I am using GFS.

> Now, I understand that to someone really clueless it is easy to
> confuse thingies that are all called ''cluster-something'' even
> if they do completely different things like RH CS (network app
> load balancing and failover service), RH GFS (network file
> system) and Oracle Cluster (semi-distributed DBMS).

You only serve to make yourself look more foolish and thus become more
unpopular (and increasingly redircected to /dev/null) by such
comments.  Feel free to continue - you harm no-one but yourself.

>   Looking back it seems that the confusion has been in this
>   thread for a while, and I should have noticed that while
>   initially you mentioned 'clumanager' (from RH CM) you switched
>   immediately thereafter, as if they were related, to talking
>   about RH GFS and raw devices.

They are not mutually exclusive.  Read the documentation.

> But these are indeed completely different packages, independent
> of each other, and it can make a big difference exactly which
> one is being used, because if you are trying to create a raw
> device troubleshooting setup what kind of usage patterns they
> get subjected to matters a great deal; and working around a raw
> device problem, if any, requires different configuration for
> each.

No Peter.  They are used together.  Read the documentation, then come back.

> So while I don't like nit-picking, your confusions of ideas and
> terminology have wasted quite a bit of your and my time.

You've wasted my time, because I cannot possibly believe that someone
I have met, and found to be interesting, intelligent and charming;
someone whose blog I have read with interest; someone who occasionally
makes very helpful comments on this list - could produce a reply such
as this.  I was tempted simply not to dignify it with a response, but
it contains so much mis-information, I felt I couldn't leave it lie.

> However, going back to the ''combination of factors'' note
> above, I would not be surprised about mishaps on a system that
> has got all three of RH CM, Oracle DBMS and RH GFS running (and
> who knows what else), as several of them may be using raw
> devices concurrently, especially if not exactly the combination
> of versions and system setup that has been ''qualified''.

At this stage, Peter, I'm bailing out.  I don't want or need your
suggestions, and I never asked for them.  Feel free to reply to my
comments, but for the sake of the others on the list, feel free to
email me off list.

I'm disappointed Peter.  I thought you were better than the above indicates.

S.
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug