On 24. Nov 2004, at 18:11, Pawel Jakub Dawidek wrote:
On Wed, Nov 24, 2004 at 10:54:07AM +0100, Eirik ?verby wrote:
+> to the best of my ability I have been investigating the 'real'
+> requirements of a raid-3 array, and cannot see that the following text
+> from graid3(8) cannot possibly be correct - and if it is, then the
+> implementation must be wrong or incomplete (emphasis added):
+>
+> label Create a RAID3 device. The last given component will contain
+> parity data, all the rest - regular data. ***Number of
+> compo-
+> nents has to be equal to 3, 5, 9, 17, etc. (2^n + 1).***
+>
+> I might be wrong, but I cannot see how a raid-3 array should require
+> (2^n + 1) drives - I am fairly certain I have seen raid-3 arrays
+> consisting of four drives, for example. This is also what I had hoped to
+> accomplish.
This requirement is because we want sectorsize to be power of 2
(UFS needs it).
In RAID3 we want to send every I/O request to all components at once,
that's why we need sector size to be N*512, where N is a power of 2 value
AND because graid3 uses one parity component we need N+1 providers.
OK I see, makes sense. So it's not really a raid3 issue, but an implementation issue.
The only problem then is - gvinum being in a completely unusable state (for raid5 anyway), what are my alternatives? I have four 160gb IDE drives, and I want capacity+redundancy. Performance is a non-issue, really. What do I do - in software?
/Eirik
-- Pawel Jakub Dawidek http://www.FreeBSD.org [EMAIL PROTECTED] http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am!
On 24. Nov 2004, at 18:11, Pawel Jakub Dawidek wrote:
On Wed, Nov 24, 2004 at 10:54:07AM +0100, Eirik ?verby wrote:
+> to the best of my ability I have been investigating the 'real'
+> requirements of a raid-3 array, and cannot see that the following text
+> from graid3(8) cannot possibly be correct - and if it is, then the
+> implementation must be wrong or incomplete (emphasis added):
+>
+> label Create a RAID3 device. The last given component will contain
+> parity data, all the rest - regular data. ***Number of
+> compo-
+> nents has to be equal to 3, 5, 9, 17, etc. (2^n + 1).***
+>
+> I might be wrong, but I cannot see how a raid-3 array should require
+> (2^n + 1) drives - I am fairly certain I have seen raid-3 arrays
+> consisting of four drives, for example. This is also what I had hoped to
+> accomplish.
This requirement is because we want sectorsize to be power of 2
(UFS needs it).
In RAID3 we want to send every I/O request to all components at once,
that's why we need sector size to be N*512, where N is a power of 2 value
AND because graid3 uses one parity component we need N+1 providers.
OK I see, makes sense. So it's not really a raid3 issue, but an implementation issue.
The only problem then is - gvinum being in a completely unusable state (for raid5 anyway), what are my alternatives? I have four 160gb IDE drives, and I want capacity+redundancy. Performance is a non-issue, really. What do I do - in software?
/Eirik
-- Pawel Jakub Dawidek http://www.FreeBSD.org [EMAIL PROTECTED] http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am!
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
