From: Leslie Rhorer <lesrhorer@att.net>
To: Linux RAID <linux-raid@vger.kernel.org>
Subject: Re: My superblocks have gone missing, can't reassemble raid5
Date: Wed, 19 May 2021 11:54:44 -0500 [thread overview]
Message-ID: <337ea246-99b0-2834-8b07-e12025d04b7d@att.net> (raw)
In-Reply-To: <e4258686-7673-9f5f-d333-fbbb95c066b1@turmel.org>
On 5/19/2021 8:41 AM, Phil Turmel wrote:
> On 5/19/21 9:20 AM, Leslie Rhorer wrote:
>>
>>
>> On 5/18/2021 1:31 PM, Reindl Harald wrote:
>
> [trim/]
>
>>> leave some margin and padding around the used space solves that
>>> problem entirely and i still need to hear a single valid reason for
>>> using unpartitioned drives in a RAID
>>
>> I can give you about a dozen. We will start with this:
>>
>> 1. Partitioning is not necessary. Doing something that is not
>> necessary is not usually worthwhile.
>
> 1a: sure. 1b: I can think of many things that aren't *necessary* but
> are certainly worthwhile. I can even throw a few out there, like
> personal hygiene, healthy diets, exercise. In this context, I would
> list drive smart monitoring, weekly scrubs, and sysadmins with a clue.
Every one of those things are not only necessary but absolutely
essential. The consequences of failing in those areas can be absolutely
devastating. What's more, I did not say, "...Never". I very
specifically said , "...Not usually". There was a reason I did that.
>> 2. Partitioning offers no advantages. Doing something unnecessary is
>> questionable. Doing something that has no purpose at all is downright
>> foolish.
>
> Who says it has no purpose. Its purpose is to segment a device into
> regions with associated metadata.
Context, please. If there is only one region with data then there is
no reason for any association with or existence of any metadata. A
system containing only one segment needs no internal identification of
any sort. A universe requires no names or labels of any sort.
A system consisting of multiple segments is a very different thing. In
any such system, partitioning or something similar is essential. That
is why my main servers all have partitioned OS arrays and
non-partitioned data arrays.
>> 3. Partitioning introduces an additional layer of activity. This
>> makes it both more complex and more wasteful of resources. And yes,
>> before you bring it up, the additional complexity and resource
>> infringement are quite small. They are not zero, however, and they
>> are in essence continuous. Every little bit counts.
>
> Hmm. A sector offset and limit check, buried deep in the kernel's
> common code. I dare you to measure the incremental impact.
You are assuming, there. The kernel can most certainly be compiled
without that code. In fact, I have done so on embedded systems. I
could measure the impact, if it were an issue for me. It isn't. The
simple fact is every bit of code takes time to run. I don't need a
quantitative measure to confirm that. I also know the run time of the
code is only a few msec for the first run and a few nanosec for
subsequent runs, assuming the blocks are kept in cache somewhere. That
is indeed minimal.
>> 4. There is no guarantee the partitioning that works today will work
>> tomorrow. It should, of course, and it probably will, but why take a
>> risk when there is absolutely no gain whatsoever?
>
> You assert "no gain", but you provide no support for your assertion.
That is because it is not possible to provide support for nothing. One
cannot prove non-existence. If you have support for the notion there is
some sort of gain, then by all means provide it. Short of that, there
is no evidence there is some gain to be had, and my statement stands.
Believe me, my feelings are not going to be hurt by being proved wrong.
>> 5. It is additional work that ultimately yields no positive result
>> whatsoever. Admittedly, partitioning one disk is not a lot of work.
>> Partitioning 50 disks is another matter. Partitioning 500 disks...
>
> You assert "no positive result whatsoever". Sounds like #4. With
> similar lack of support. Fluffing up your list, much?
No, it is the cost side of the argument, which is not the same as the
consequential side. They are the two sides of the cost / benefit
analysis. In #4, I assert the benefit is negligible, perhaps even zero.
You haven't bothered to refute this, by the way. In this point, I
highlight the fact there is some cost to the practice. Again, you have
not refuted this. An ad hominem reference to some alleged procedural
failure on my part does not support your position. Note I would be
happy for you to do so, but don't think criticizing my abilities,
whether accurate or not, in no way supports your position.
>> 6. Partitioning has an intent. That intent is of no relevance
>> whatsoever on a device whose content is singular in scope. Are you
>> suggesting we should also partition tapes? Ralph Waldo Emerson had
>> something important to say about repeatedly doing things simply
>> because they have been done before and elsewhere.
>
> No relevance? Metadata can be rather useful when operating systems
> encounter what looks like an empty disk.
I am afraid you are going to have to be more specific for me to concede
this point. I am having trouble coming up with a good example.
> Metadata that says "not
> empty!" Especially valuable when metadata is *recognized* by all
> operating systems. You know, like, a *standard*.
Please name one such case. I cannot think of even a single protocol or
standard that is universally recognized. Some are close, but then only
those that are very, very old.
> While MDraid places
> metadata on the devices it uses, only Linux *recognizes* it.
The logical extension of this is no system, anywhere, should ever use
RAID of any flavor. Nor indeed, any file system. Nor, for that matter,
any file system. Indeed, we should never use any hard drive, and
definitely not any tape drives.
>> 7. There is no downside to forfeiting the partition table. Not
>> needing to do something is an extremely good reason for not doing it.
>> This is of course a corollary to point #1.
>
> Just more fluff.
"Just" more ad hominem. Going down a short side path for a moment, the
term "just" is almost always an illegitimate attempt to belittle and
avoid an idea with the intent of being dismissive to an opponent in a
debate. All it really does is highlight the speaker's inability to
properly support the speaker's side of the debate. I would request you
please stop "justiing" and instead provide some real support for your
argument. It doesn't greatly matter to me who wins this argument, but
having to reply to unsupported rhetoric wastes my time.
> Microsoft and a number of NAS products are known to corrupt drives with
> no partition table.
Which is a pretty good argument to avoid those products, if true.
Actually, I can't speak to any particular NAS (most of which are Linux
based, and so quite unlikely to behave in such a manner), but while MS
was accused of such activity in the past. It was not true up to and
including Windows 7. I don't know about Windows 10, but I doubt it.
Notwithstanding, I still avoid Windows whenever possible. I certainly
avoid doing anything merely to accommodate Windows.
> I vaguely recall hardware raid doing it, too.
> That's a damn good reason to add a tiny (measurable?) amount of overhead.
No, it's a damn good reason to completely avoid any such products, for
reasons far deeper than just mucking around with partition tables.
Mucking around the system without the express intent and direction of
the system supervisor is not acceptable under any circumstances. It's
also a damn good reason why the supervisor needs to know what they are
doing.
> And dude, making a single partition on a disk can be /scripted/. Might
> want to learn about that, if the pain of the driving fdisk/gdisk
> occasionally is too much for your delicate fingers.
It's not too much. It's just unnecessary. So is typing <scriptname>
when it is not necessary. The fact it can be scripted is irrelevant.
You are free to do whatever you like. I am not going to try to stop
you. You asked for reasons why one may chose not to partition RAID
members. I gave you some. Accept them or reject them. I don't really
care. Show me where my statements were factually incorrect. I am
always happy to learn of my mistakes.
By the way, I don't partition non-RAID drives, either, unless they
require multiple segments. Not all of the media have any file systems,
either.
next prev parent reply other threads:[~2021-05-19 16:55 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-17 4:16 My superblocks have gone missing, can't reassemble raid5 Christopher Thomas
2021-05-17 4:23 ` Christopher Thomas
2021-05-17 6:28 ` Roman Mamedov
2021-05-17 9:30 ` Wols Lists
[not found] ` <CAAMCDec=H=6ceP9bKjSnsQyvmZ0LqTAYzJTDmDQoBOHSJV+hDw@mail.gmail.com>
2021-05-17 13:19 ` Roman Mamedov
2021-05-18 17:47 ` Phil Turmel
2021-05-18 18:31 ` Reindl Harald
2021-05-19 13:20 ` Leslie Rhorer
2021-05-19 13:41 ` Phil Turmel
2021-05-19 16:54 ` Leslie Rhorer [this message]
2021-05-20 19:37 ` Nix
2021-06-07 9:52 ` Leslie Rhorer
2021-05-19 14:20 ` Andy Smith
2021-05-19 14:59 ` Leslie Rhorer
2021-05-19 14:48 ` Leslie Rhorer
2021-05-19 16:41 ` antlists
2021-05-19 17:03 ` Leslie Rhorer
2021-05-19 17:08 ` Leslie Rhorer
2021-05-19 18:00 ` Wols Lists
2021-05-19 19:01 ` Leslie Rhorer
2021-05-19 20:01 ` antlists
2021-05-19 23:45 ` Leslie Rhorer
2021-05-20 20:49 ` Nix
2021-05-21 4:07 ` Leslie Rhorer
2021-06-07 9:55 ` Leslie Rhorer
2021-05-20 20:48 ` Nix
2021-05-21 3:56 ` Leslie Rhorer
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=337ea246-99b0-2834-8b07-e12025d04b7d@att.net \
--to=lesrhorer@att.net \
--cc=linux-raid@vger.kernel.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 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.