lkml.org 
[lkml]   [2002]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: PATCH - change to blkdev->queue calling triggers BUG in md.c
Hi,

On Tue, 3 Sep 2002, Hacksaw wrote:
> > But why have a partition table on each of these 16 pseudo disks?
>
> If not a partition table, then some positive indication that there is
> nothing more.

And waste a block? With correct raid organization the controller takes up
the job of your partition table. (Yes, regardless of where it' storing
data.)

> Because changing hardware is often quite annoying, and proprietary, and
> hard or impossible to script.

Anyway, that's news to me. Where?

> I had one RAID that could only be set up by changing things using four
> buttons on the front panel.

Well, I'm talking about a vision of replacing partition tables with
sensible and gentle disk handling, where possible. Old technics definitely
need some other kind of hammer, or to get replaced.

> But more importantly, I want controllers that survive total power down.

You can't get that with partition tables either. And by the way, we
succeeded doing that at Magdeburg. Pull out the power supply, batteries,
etc., then run away.

Yes, we need better materia. Mind the biotechnical approach. Still doesn't
qualify as a statement for partition tables.

> Restoring a 4TiB RAID is not what I want to be doing with a department of idle
> developers

That's why sensible raid systems do that on their own. In the meanwhile
you can get around with the data. Mostly it's nothing more than a "find
disk order", which is not too bad.

> Another factor is usage. I've had users who were assigned a slice of a
> RAID who asked me to divide the slice up, so that one experiment
> couldn't hose another by filling the whole logical disk.

Then give them two logical disks. Just a matter of management.

> Admittedly. But it's important to indicate the lack of a partition
> table, so the software can get on with life, rather than trying to
> determine if the partition table got scribbled on.

Yes, that's cool in case we'd possibly need one. But in the raid cases we
should get to a position where partition tables are not just theoretically
meaningless.

> Again, searching a huge RAID to determine the old partition is not
> something I want to spend an afternoon doing, not when I can spend a few
> blocks out of millions and have backups.

I've still not said you'd have to do that. You can have a perl script do
your job scribbling the table together.

Thunder
--
--./../...-/. -.--/---/..-/.-./..././.-../..-. .---/..-/.../- .-
--/../-./..-/-/./--..-- ../.----./.-../.-.. --./../...-/. -.--/---/..-
.- -/---/--/---/.-./.-./---/.--/.-.-.-
--./.-/-.../.-./.././.-../.-.-.-

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:28    [W:0.071 / U:1.528 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site