[ Sunday, September 19, 1999 ] CJones wrote:
> Gadi Oxman wrote:
> > On Sat, 18 Sep 1999, James Manning wrote:
> > > Well, I tried booting and it died with some SYSCTL() errors (figures :)
> > > so if it looks like the patch at least has the right idea, let me know
> > > and I'll try fixing up the problems... otherwise lemme know how you'd
> > > like to see a settable raid1 balance implemented :)
> > >
> > > James
> >
> > I originally planned to store the "sect_limit" value for each array
> > at its RAID superblock (along with other array specific parameters),
> > and write some utility which will allow viewing and changing the RAID
> > superblock parameters.
> >
> > Gadi
>
> Storing information like this in the superblock is an excellent idea.
> But wouldn't that require stopping and restarting the array to change
> the parameters? Perhaps sysctl should change the values dynamically,
> then write the changes to the superblock to preserve them for the next
> boot (or can it do that).
>
> Clay
I like sysctl since it only relies on echo/cat being around to deal
with it... the raid superblock as a cross-boot storage location sure
seems like a great idea, but just to play devil's advocate (and show
my ignorance wrt the raid superblock code) doesn't this leave us more
vulnerable to corruption? Perhaps it doesn't matter, as it's just
performance tuning values which we can do range checking on rather than
anything effecting correctness...
Also, sysctl takes up no real "space" wrt the array so I can add as many
tuning parameters as I wish... of course, such superblock additions don't
prevent the use of sysctl either :)
In terms of possible future legacy problems, if you have any data slots
in your superblock for such tuning parameters, future raid patches
will have to respect that slot as taken from here on out... if param
"foo" was taking bytes x..x+7 in the superblock, we can't put "bar"
there in the next patch (where we figure out "foo" wasn't really needed,
or that there's a setting that's always the Right Thing To Do), as
superblocks created by previous raid patches won't recognize that...
That's about all I can think of at the moment :)
James
--
Miscellaneous Engineer --- IBM Netfinity Performance Development
