Re: graid3 - requirements or manpage wrong?
Brian Szymanski wrote: As for the swap: why would you want to do that? It was my understanding that the kernel load balanced swap requests across drives? You'd want to do it not for load-balancing but for fault tolerance. With a RAID 1/3/5 setup you could have a drive fail and still have swapping (and hence the system) continue to work. That's not the same as (or true of) having multiple swap partitions with the system balancing load over all of them. Cheers, Paul. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: graid3 - requirements or manpage wrong?
>> "Brian" == Brian Szymanski <[EMAIL PROTECTED]> writes: > >>> That is not completely fair for vinum >>> >>> I've been running vinum now for the better of 3-4 years, and even >>> with a set of very flaky seagate IDE drives I never lost a byte. >>> Vinum has served me well, and I trust gvinum will get there as >>> well. I just left my fileserver at 5.1, which I know is not an >>> option for everybody. > > Brian> Are you using vinum Raid5 ? I'm considering rolling back to 5.1 > Brian> myself if someone attests that things "just work" there with > Brian> R5, then waiting for gvinum to mature before getting my machine > Brian> back on stable. > > Brian> Also, when did vinum stop working in favor of gvinum? is it > Brian> with 5.3? Could I expect 5.2.1 to work? Pardon the barrage of > Brian> questions, but it would take me hours to test each case, so if > Brian> anyone knows, drop me a line. Thanks! > > In 5.3, it appears that you can load vinum or gvinum. Vinum appears > to have the functionality (and bugs) that it had back in 5.1. The > only missing function seems to be the ability to swap to a vinum > volume. Actually I experienced a number of bugs with vinum in 5.3 that proved fatal to a root vinum install (in fact, everything on the second ATA channel was marked down after every reboot if I recall correctly). As for the swap: why would you want to do that? It was my understanding that the kernel load balanced swap requests across drives? Cheers, Brian > Dave. > > -- > > |David Gilbert, Independent Contractor. | Two things can only be > | > |Mail: [EMAIL PROTECTED]| equal if and only if they > | > |http://daveg.ca | are precisely opposite. > | > =GLO > -- Brian Szymanski [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: graid3 - requirements or manpage wrong?
> "Brian" == Brian Szymanski <[EMAIL PROTECTED]> writes: >> That is not completely fair for vinum >> >> I've been running vinum now for the better of 3-4 years, and even >> with a set of very flaky seagate IDE drives I never lost a byte. >> Vinum has served me well, and I trust gvinum will get there as >> well. I just left my fileserver at 5.1, which I know is not an >> option for everybody. Brian> Are you using vinum Raid5 ? I'm considering rolling back to 5.1 Brian> myself if someone attests that things "just work" there with Brian> R5, then waiting for gvinum to mature before getting my machine Brian> back on stable. Brian> Also, when did vinum stop working in favor of gvinum? is it Brian> with 5.3? Could I expect 5.2.1 to work? Pardon the barrage of Brian> questions, but it would take me hours to test each case, so if Brian> anyone knows, drop me a line. Thanks! In 5.3, it appears that you can load vinum or gvinum. Vinum appears to have the functionality (and bugs) that it had back in 5.1. The only missing function seems to be the ability to swap to a vinum volume. Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: graid3 - requirements or manpage wrong?
Brian Szymanski wrote: That is not completely fair for vinum I've been running vinum now for the better of 3-4 years, and even with a set of very flaky seagate IDE drives I never lost a byte. Vinum has served me well, and I trust gvinum will get there as well. I just left my fileserver at 5.1, which I know is not an option for everybody. Are you using vinum Raid5 ? I'm considering rolling back to 5.1 myself if someone attests that things "just work" there with R5, then waiting for gvinum to mature before getting my machine back on stable. Also, when did vinum stop working in favor of gvinum? is it with 5.3? Could I expect 5.2.1 to work? Pardon the barrage of questions, but it would take me hours to test each case, so if anyone knows, drop me a line. Thanks! [~wjw] [EMAIL PROTECTED]> uname -a FreeBSD files.digiware.nl 5.1-RELEASE-p11 FreeBSD 5.1-RELEASE-p11 #3: Sat Dec 20 16:16:35 CET 2003 [EMAIL PROTECTED]:/mnt2/obj/usr/src51/src/sys/GENERIC i386 [~wjw] [EMAIL PROTECTED]> vinum l 4 drives: D vinumdrive1 State: up /dev/ad7s1h A: 0/58143 MB (0%) D vinumdrive0 State: up /dev/ad6s1h A: 0/58143 MB (0%) D vinumdrive3 State: up /dev/ad5s1h A: 0/58143 MB (0%) D vinumdrive2 State: up /dev/ad4s1h A: 0/58143 MB (0%) 1 volumes: V vinum0State: up Plexes: 1 Size:170 GB 1 plexes: P vinum0.p0 R5 State: up Subdisks: 4 Size:170 GB 4 subdisks: S vinum0.p0.s0 State: up D: vinumdrive0 Size: 56 GB S vinum0.p0.s1 State: up D: vinumdrive1 Size: 56 GB S vinum0.p0.s2 State: up D: vinumdrive2 Size: 56 GB S vinum0.p0.s3 State: up D: vinumdrive3 Size: 56 GB Note that this is vinum in its most simple state: - 4* whole disk in vinum. - NO root or swap or other complicating issues. This server is only doing one simple thing: NFS en SMB serving. Even SMB is still way behind on 2.2.8 And I have not tried in going to the 5.2.1 venture. I only went to 5.1 on this box, because it was the last of the mohicans in my home server park not running >= 5. So I wanted to get ride of the 4.x tree. And as you can see I have not tinkered with this box for almost a year. --WjW ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: graid3 - requirements or manpage wrong?
> That is not completely fair for vinum > > I've been running vinum now for the better of 3-4 years, and even with a > set of very flaky seagate IDE drives I never lost a byte. > Vinum has served me well, and I trust gvinum will get there as well. > I just left my fileserver at 5.1, which I know is not an option for > everybody. Are you using vinum Raid5 ? I'm considering rolling back to 5.1 myself if someone attests that things "just work" there with R5, then waiting for gvinum to mature before getting my machine back on stable. Also, when did vinum stop working in favor of gvinum? is it with 5.3? Could I expect 5.2.1 to work? Pardon the barrage of questions, but it would take me hours to test each case, so if anyone knows, drop me a line. Thanks! Brian Szymanski [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: graid3 - requirements or manpage wrong?
>>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? What's unusable about it? I've 4 250GB ATA drives, desiring capacity + redundancy, but don't care about speed, much like you, and gvinum raid 5 has suited me just fine this past few weeks. Eats a lot of system cpu when there is heavy IO to the R5, but I've booted up with a drive unplugged and it worked fine in degraded mode, so I'm content... > Vinum and now gvinum (I have not tried the latter, your words) have > never had reliable RAID-5 implementation. That is my experience only. ? This is the first I've heard of such problems? Vinum has served me well in the past, although I've never used Raid-5 before... If there are known bugs, I'd appreciate someone sending me a link to where I can read more. Cheers, Brian Szymanski [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: graid3 - requirements or manpage wrong?
Vallo Kallaste wrote: On Wed, Nov 24, 2004 at 07:33:55PM +0100, Eirik Øverby <[EMAIL PROTECTED]> wrote: 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? Submit code is the standard answer. Vinum and now gvinum (I have not tried the latter, your words) have never had reliable RAID-5 implementation. That is my experience only. Yes I am frustrated about current state of FreeBSD and because of such state I'm forced to use other OS's, for reliability reasons. For a person who's been with FreeBSD since 2.0.5 that's sad future, but nevertheless I'm unsubscribing from the remaining FreeBSD lists until things (hopefully) improve and to save you all from further rants. That is not completely fair for vinum I've been running vinum now for the better of 3-4 years, and even with a set of very flaky seagate IDE drives I never lost a byte. Vinum has served me well, and I trust gvinum will get there as well. I just left my fileserver at 5.1, which I know is not an option for everybody. --WjW ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: graid3 - requirements or manpage wrong?
On Wed, Nov 24, 2004 at 07:33:55PM +0100, Eirik Ãverby <[EMAIL PROTECTED]> wrote: > 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? Submit code is the standard answer. Vinum and now gvinum (I have not tried the latter, your words) have never had reliable RAID-5 implementation. That is my experience only. Yes I am frustrated about current state of FreeBSD and because of such state I'm forced to use other OS's, for reliability reasons. For a person who's been with FreeBSD since 2.0.5 that's sad future, but nevertheless I'm unsubscribing from the remaining FreeBSD lists until things (hopefully) improve and to save you all from further rants. -- Vallo Kallaste ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: graid3 - requirements or manpage wrong?
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]"
Re: graid3 - requirements or manpage wrong?
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. -- Pawel Jakub Dawidek http://www.FreeBSD.org [EMAIL PROTECTED] http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! pgpcglvLFqzns.pgp Description: PGP signature
