Re: PATCH - change to blkdev->queue calling triggers BUG in md.c

From: Thunder from the hill (thunder@lightweight.ods.org)
Date: Tue Sep 03 2002 - 16:51:13 EST


Hi,

On Tue, 3 Sep 2002, Hacksaw wrote:
> > Disk-backed raid config storage can do that just as well. I don't
> > really think a partition table is the thing you'll want in order to
> > store your raid config.
>
> Additionally, I want the OS to be able to do what it wants with the
> disk, which may well mean logically dividing the disks presented by the
> RAID into logical partitions.

We're going cyclic. All over. I think I've made my point, and you've made
yours. Yet I could live with my raid(s). IMO you can handle it all at the
level of clueful hardware presenting virtual hardware to your OS.

> In fact, the two systems (RAID controller and OS) should not have
> anything to do with each other. The OS should just see disks, and the
> controller should just see raw data for it to put where ever the OS says
> to put it.

I agree for more than a hundred percent. And I think the OS shouldn't have
to bother with disk slicing where it's not necessary.

> And yes you can resize disks, especially if you don't mind hosing the
> data thereon.

I've meant to say "physical disks". I'm happily aware of raid virtual disk
resizing.

> > (I still wonder how often you resize your partitions, per second.)
>
> Not often. I probably changed disk setup once a week. Even still, I want it to
> take me almost zero time, and the RAID as a whole must remain up at all times,
> 24/7.

Enough time to back up the stuff.

> The theory doesn't match my experience. Maybe ten years from now it
> will. But I doubt it seriously.

I'm not talking about all the stuff that's on the market right now. I'm
talking about the good stuff which we should evolve within the next few
years in order to get proper support for our requirements.

> In ten years I think we'll have PC's shipping with 4TiB disks that are
> still damned slow.

I'm still talking about raid here.

> And my time could include every developer. At $250 an hour, 70 idle
> developers = $17,500 for an hour of down time.

My response is: don't watch the script work.

                        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/



This archive was generated by hypermail 2b29 : Sat Sep 07 2002 - 22:00:19 EST