125 lines
4.8 KiB
HTML
125 lines
4.8 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
|
|
<HTML>
|
|
<HEAD>
|
|
<META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
|
|
<TITLE>Software-RAID HOWTO: Wish List of Enhancements to MD and Related Software</TITLE>
|
|
<LINK HREF="Software-RAID-0.4x-HOWTO-10.html" REL=previous>
|
|
<LINK HREF="Software-RAID-0.4x-HOWTO.html#toc11" REL=contents>
|
|
</HEAD>
|
|
<BODY>
|
|
Next
|
|
<A HREF="Software-RAID-0.4x-HOWTO-10.html">Previous</A>
|
|
<A HREF="Software-RAID-0.4x-HOWTO.html#toc11">Contents</A>
|
|
<HR>
|
|
<H2><A NAME="s11">11. Wish List of Enhancements to MD and Related Software</A></H2>
|
|
|
|
<P>Bradley Ward Allen
|
|
<
|
|
<A HREF="mailto:ulmo@Q.Net">ulmo@Q.Net</A>>
|
|
wrote:
|
|
<BLOCKQUOTE>
|
|
Ideas include:
|
|
<UL>
|
|
<LI>Boot-up parameters to tell the kernel which devices are
|
|
to be MD devices (no more ``<CODE>mdadd</CODE>'')</LI>
|
|
<LI>Making MD transparent to ``<CODE>mount</CODE>''/``<CODE>umount</CODE>''
|
|
such that there is no ``<CODE>mdrun</CODE>'' and ``<CODE>mdstop</CODE>''</LI>
|
|
<LI>Integrating ``<CODE>ckraid</CODE>'' entirely into the kernel,
|
|
and letting it run as needed</LI>
|
|
</UL>
|
|
|
|
(So far, all I've done is suggest getting rid of the tools and putting
|
|
them into the kernel; that's how I feel about it,
|
|
this is a filesystem, not a toy.)
|
|
<UL>
|
|
<LI>Deal with arrays that can easily survive N disks going out
|
|
simultaneously or at separate moments,
|
|
where N is a whole number > 0 settable by the administrator</LI>
|
|
<LI>Handle kernel freezes, power outages,
|
|
and other abrupt shutdowns better</LI>
|
|
<LI>Don't disable a whole disk if only parts of it have failed,
|
|
e.g., if the sector errors are confined to less than 50% of
|
|
access over the attempts of 20 dissimilar requests,
|
|
then it continues just ignoring those sectors of that particular
|
|
disk.</LI>
|
|
<LI>Bad sectors:
|
|
<UL>
|
|
<LI>A mechanism for saving which sectors are bad,
|
|
someplace onto the disk.</LI>
|
|
<LI>If there is a generalized mechanism for marking degraded
|
|
bad blocks that upper filesystem levels can recognize,
|
|
use that. Program it if not.</LI>
|
|
<LI>Perhaps alternatively a mechanism for telling the upper
|
|
layer that the size of the disk got smaller,
|
|
even arranging for the upper layer to move out stuff from
|
|
the areas being eliminated.
|
|
This would help with a degraded blocks as well.</LI>
|
|
<LI>Failing the above ideas, keeping a small (admin settable)
|
|
amount of space aside for bad blocks (distributed evenly
|
|
across disk?), and using them (nearby if possible)
|
|
instead of the bad blocks when it does happen.
|
|
Of course, this is inefficient.
|
|
Furthermore, the kernel ought to log every time the RAID
|
|
array starts each bad sector and what is being done about
|
|
it with a ``<CODE>crit</CODE>'' level warning, just to get
|
|
the administrator to realize that his disk has a piece of
|
|
dust burrowing into it (or a head with platter sickness).</LI>
|
|
</UL>
|
|
</LI>
|
|
<LI>Software-switchable disks:
|
|
<DL>
|
|
<DT><B>``disable this disk''</B><DD><P>would block until kernel has completed making sure
|
|
there is no data on the disk being shut down
|
|
that is needed (e.g., to complete an XOR/ECC/other error
|
|
correction), then release the disk from use
|
|
(so it could be removed, etc.);
|
|
<DT><B>``enable this disk''</B><DD><P>would <CODE>mkraid</CODE> a new disk if appropriate
|
|
and then start using it for ECC/whatever operations,
|
|
enlarging the RAID5 array as it goes;
|
|
<DT><B>``resize array''</B><DD><P>would respecify the total number of disks
|
|
and the number of redundant disks, and the result
|
|
would often be to resize the size of the array;
|
|
where no data loss would result,
|
|
doing this as needed would be nice,
|
|
but I have a hard time figuring out how it would do that;
|
|
in any case, a mode where it would block
|
|
(for possibly hours (kernel ought to log something every
|
|
ten seconds if so)) would be necessary;
|
|
<DT><B>``enable this disk while saving data''</B><DD><P>which would save the data on a disk as-is and move it
|
|
to the RAID5 system as needed, so that a horrific save
|
|
and restore would not have to happen every time someone
|
|
brings up a RAID5 system (instead, it may be simpler to
|
|
only save one partition instead of two,
|
|
it might fit onto the first as a gzip'd file even);
|
|
finally,
|
|
<DT><B>``re-enable disk''</B><DD><P>would be an operator's hint to the OS to try out
|
|
a previously failed disk (it would simply call disable
|
|
then enable, I suppose).
|
|
</DL>
|
|
</LI>
|
|
</UL>
|
|
</BLOCKQUOTE>
|
|
<P>Other ideas off the net:
|
|
<BLOCKQUOTE>
|
|
<UL>
|
|
<LI>finalrd analog to initrd, to simplify root raid.</LI>
|
|
<LI>a read-only raid mode, to simplify the above </LI>
|
|
<LI>Mark the RAID set as clean whenever there are no
|
|
"half writes" done. -- That is, whenever there are no write
|
|
transactions that were committed on one disk but still
|
|
unfinished on another disk.
|
|
|
|
Add a "write inactivity" timeout (to avoid frequent seeks
|
|
to the RAID superblock when the RAID set is relatively
|
|
busy).
|
|
</LI>
|
|
</UL>
|
|
</BLOCKQUOTE>
|
|
<P>
|
|
<HR>
|
|
Next
|
|
<A HREF="Software-RAID-0.4x-HOWTO-10.html">Previous</A>
|
|
<A HREF="Software-RAID-0.4x-HOWTO.html#toc11">Contents</A>
|
|
</BODY>
|
|
</HTML>
|