Re: [ GEOM tests ] vinum drives lost
On Sun, Oct 06, 2002 at 07:44:56AM +0930, Greg 'groggy' Lehey [EMAIL PROTECTED] wrote: Some time ago Scott Long pointed out to me that ccd has less overhead than vinum It does? The actual tests showed a very little improvement in a few cases, so I must admit that it made really no difference for bare striping. I have no evidence (not being a programmer), but I believe that ccd is lightweight compared to vinum, even considering only striping. That, and the time of ccd being around compared to vinum, means probably fewer bugs and better suitability for bare striping. That's my personal opinion and I will rely also on other far more knowledgeable person opinion in this particular case. To be fair I believe that vinum striping and mirroring capabilities are fully usable and proven also. I have personal experience which backs this, not that it'll matter much to anybody else. Vinum R5 is broken and I've lost interest over the years of trying to make use of it. No complaints to you, I do understand that paid work is what makes living. and is better suited for bare striping. It is? I'd be interested in details. See above. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] vinum drives lost
Yes, ccd is fairly light weight. 'man tuning' and 'man ccd' has a lot of information on how to use it. I generally recommend using a stripe size of 1152 for multitasking loads. Only use a small/tiny stripe size if you need single-tasking sequential performance (and even then you can take tune the stripe to the drive's own caching capability). The biggest mistake most people make when using striping is that they use too small a stripe size which causes nearly every read() or write() to have to be split across multiple drives, which multiplies the overhead, or causes sequential reads of medium sized files to constantly seek multiple drives, destroying the effectiveness of having two seekable heads in the first place. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] vinum drives lost
On Fri, 4 Oct 2002, Poul-Henning Kamp wrote: Worst case you will have the option to use: options NOGEOM options vinum A NOGEOM option would be as acceptable as a NOFFS option for turning off forcing of the one true file system down everyone's throats. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] vinum drives lost
On Fri, Oct 04, 2002 at 12:45:59PM -0700, Lars Eggert [EMAIL PROTECTED] wrote: Well, the showstopper is in vinum. The fact that ccd(4) works seamlessly with GEOM is testament to this. For some reason I was under the (mis?)impression that ccd was no longer being maintained... If it works with geom, we can probably move our machines over to ccd. They're all no-frills stripes, so ccd functionality is good enough. Some time ago Scott Long pointed out to me that ccd has less overhead than vinum and is better suited for bare striping. The actual case involved two fake disks using asr(4) and 2400A. I had no choice because hardware doesn't support spanning. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] vinum drives lost
Bruce Evans wrote: On Fri, 4 Oct 2002, Poul-Henning Kamp wrote: Worst case you will have the option to use: options NOGEOM options vinum A NOGEOM option would be as acceptable as a NOFFS option for turning off forcing of the one true file system down everyone's throats. Part of the problem there is a weakness in config that I've threatened to fix on more than one occasion. We do not have a way to have options default to on and let people turn the option off. Negative options (options NOFOO) are a poor substitute. In the past, a couple of things were unifdefed that might have been better served as being 'default to on' options or drivers. This of course is ignoring the issue of geom vs the disklabel code. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] vinum drives lost
On Sat, 5 Oct 2002, Peter Wemm wrote: Bruce Evans wrote: On Fri, 4 Oct 2002, Poul-Henning Kamp wrote: Worst case you will have the option to use: options NOGEOM options vinum A NOGEOM option would be as acceptable as a NOFFS option for turning off forcing of the one true file system down everyone's throats. Part of the problem there is a weakness in config that I've threatened to fix on more than one occasion. We do not have a way to have options default to on and let people turn the option off. Negative options (options NOFOO) are a poor substitute. In the past, a couple of things were unifdefed that might have been better served as being 'default to on' options or drivers. Hmm. Negative options implemented as negoptions FOO would work OK for this. Options could be defaulted to on by putting them in an included config file, and then turned off using negoptions. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] vinum drives lost
In message [EMAIL PROTECTED], Bruce Evans writes: On Sat, 5 Oct 2002, Peter Wemm wrote: Bruce Evans wrote: On Fri, 4 Oct 2002, Poul-Henning Kamp wrote: Worst case you will have the option to use: options NOGEOM options vinum A NOGEOM option would be as acceptable as a NOFFS option for turning off forcing of the one true file system down everyone's throats. Part of the problem there is a weakness in config that I've threatened to fix on more than one occasion. We do not have a way to have options default to on and let people turn the option off. Negative options (options NOFOO) are a poor substitute. In the past, a couple of things were unifdefed that might have been better served as being 'default to on' options or drivers. Hmm. Negative options implemented as negoptions FOO would work OK for this. Options could be defaulted to on by putting them in an included config file, and then turned off using negoptions. This could actually decrease the size and complexity of our kernel config files considerably, just think of all the theoretically-but-not-in-practice options like INET. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] vinum drives lost
On Fri, Oct 04, 2002 at 12:44:30PM -0700, Julian Elischer wrote: No, it is established principal tha the importer of new features has the responsibility to make older subsystems work. So when is a KSE person going to fix the libc_r and releng4 binaries problem?? That certainly is old functionality that is broken. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] vinum drives lost
On Saturday, 5 October 2002 at 15:55:05 +0300, Vallo Kallaste wrote: On Fri, Oct 04, 2002 at 12:45:59PM -0700, Lars Eggert [EMAIL PROTECTED] wrote: Well, the showstopper is in vinum. The fact that ccd(4) works seamlessly with GEOM is testament to this. For some reason I was under the (mis?)impression that ccd was no longer being maintained... If it works with geom, we can probably move our machines over to ccd. They're all no-frills stripes, so ccd functionality is good enough. Some time ago Scott Long pointed out to me that ccd has less overhead than vinum It does? and is better suited for bare striping. It is? I'd be interested in details. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] vinum drives lost
On Sat, 5 Oct 2002, David O'Brien wrote: On Fri, Oct 04, 2002 at 12:44:30PM -0700, Julian Elischer wrote: No, it is established principal tha the importer of new features has the responsibility to make older subsystems work. So when is a KSE person going to fix the libc_r and releng4 binaries problem?? That certainly is old functionality that is broken. Firstly, I'm not sure, as it's I can only take Dan's eworkd on it, but releng-4 binaries should be working again now. Secondly The person who broke it (not me BTW) has been chastised severely and has had a life-long learning experience. He is working hard on fixing it properly (But is not being helped by the fact hat his job changed and he has to move towns). Dan, (Mr libc_r) is working in it too, and AS THE MAIN MAINTAINER of libc_r he is not someone that I can beat on when it comes to libc_r. If he says it's fixed I have to believe him. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] vinum drives lost
On 04.10-18:27, Poul-Henning Kamp wrote: In message n0go013 writes : On 04.10-15:40, fergus wrote: On 04.10-14:20, Poul-Henning Kamp wrote: [...] I suspect vinum uses this sysctl to get an inventory of disks in the system, so can I get you to try again making sure you have rev. 1.20 of src/sys/geom/geom_disk.c ? [...] i'll let you know the test results when i have some. same results -- can't initialise any drives. i think the example below points more directly to the issue but i'm pretty sure it is because the direct read from the disk does not return a valid disklabel. without a 'vinum' partition entry vinum spews. I have no idea how vinum does this or something else, but clearly something is not done the right way in vinum... apparently by allocating a bio header via 'geteblk' and calling the DEV_STRATEGY macro. not that it means anything to me but probably to you it does (well i get the idea but . . .). what is the correct way to read the disklabel ? i'll hack around and see if i can't clean up this and the other pieces of direct IO. -- t t z To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] vinum drives lost
In message [EMAIL PROTECTED], n0go013 writes : On 04.10-18:27, Poul-Henning Kamp wrote: In message n0go013 writes : On 04.10-15:40, fergus wrote: On 04.10-14:20, Poul-Henning Kamp wrote: [...] I suspect vinum uses this sysctl to get an inventory of disks in the system, so can I get you to try again making sure you have rev. 1.20 of src/sys/geom/geom_disk.c ? [...] i'll let you know the test results when i have some. same results -- can't initialise any drives. i think the example below points more directly to the issue but i'm pretty sure it is because the direct read from the disk does not return a valid disklabel. without a 'vinum' partition entry vinum spews. I have no idea how vinum does this or something else, but clearly something is not done the right way in vinum... apparently by allocating a bio header via 'geteblk' and calling the DEV_STRATEGY macro. not that it means anything to me but probably to you it does (well i get the idea but . . .). what is the correct way to read the disklabel ? i'll hack around and see if i can't clean up this and the other pieces of direct IO. I would need to look at the code to be able to tell, I don't have time for that. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] vinum drives lost
Poul-Henning Kamp wrote: I would need to look at the code to be able to tell, I don't have time for that. I'd consider not having vinum work under geom a show-stopper... at least until geom can stripe. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: [ GEOM tests ] vinum drives lost
In message [EMAIL PROTECTED], Lars Eggert writes: This is a cryptographically signed message in MIME format. --ms040706010906030302070807 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Poul-Henning Kamp wrote: I would need to look at the code to be able to tell, I don't have time for that. I'd consider not having vinum work under geom a show-stopper... at least until geom can stripe. Well, the showstopper is in vinum. The fact that ccd(4) works seamlessly with GEOM is testament to this. There are numerous architectural issues which have never been fixed in vinum, and one or more of these bits now. Whoever loves vinum will have to chase it/them down and fix it. If I receive patches or requests for changes to GEOM as result of this, they will be evaluated in good faith. Worst case you will have the option to use: options NOGEOM options vinum -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] vinum drives lost
Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Lars Eggert writes: I'd consider not having vinum work under geom a show-stopper... at least until geom can stripe. Well, the showstopper is in vinum. The fact that ccd(4) works seamlessly with GEOM is testament to this. For some reason I was under the (mis?)impression that ccd was no longer being maintained... If it works with geom, we can probably move our machines over to ccd. They're all no-frills stripes, so ccd functionality is good enough. Thanks for clearing that up! Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: [ GEOM tests ] vinum drives lost
On Fri, 4 Oct 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Lars Eggert writes: This is a cryptographically signed message in MIME format. --ms040706010906030302070807 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Poul-Henning Kamp wrote: I would need to look at the code to be able to tell, I don't have time for that. I'd consider not having vinum work under geom a show-stopper... at least until geom can stripe. Well, the showstopper is in vinum. The fact that ccd(4) works seamlessly with GEOM is testament to this. There are numerous architectural issues which have never been fixed in vinum, and one or more of these bits now. Whoever loves vinum will have to chase it/them down and fix it. No, it is established principal tha the importer of new features has the responsibility to make older subsystems work. If I receive patches or requests for changes to GEOM as result of this, they will be evaluated in good faith. Worst case you will have the option to use: options NOGEOM options vinum -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] vinum drives lost
On 04-Oct-2002 Julian Elischer wrote: On Fri, 4 Oct 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Lars Eggert writes: This is a cryptographically signed message in MIME format. --ms040706010906030302070807 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Poul-Henning Kamp wrote: I would need to look at the code to be able to tell, I don't have time for that. I'd consider not having vinum work under geom a show-stopper... at least until geom can stripe. Well, the showstopper is in vinum. The fact that ccd(4) works seamlessly with GEOM is testament to this. There are numerous architectural issues which have never been fixed in vinum, and one or more of these bits now. Whoever loves vinum will have to chase it/them down and fix it. No, it is established principal tha the importer of new features has the responsibility to make older subsystems work. Oh, you mean like KSE on Alpha? -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] vinum drives lost
In message [EMAIL PROTECTED], Ju lian Elischer writes: No, it is established principal tha the importer of new features has the responsibility to make older subsystems work. I'm _so_ glad to hear _you_ say that: When will you have made KSE work on sparc64 and ia64 ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] vinum drives lost
Lars Eggert wrote: For some reason I was under the (mis?)impression that ccd was no longer being maintained... If it works with geom, we can probably move our machines over to ccd. They're all no-frills stripes, so ccd functionality is good enough. From the man page of ccd: ccd has an option for a parity disk, but does not currently implement it. and In an event of a disk failure, you can use dd(1) to recover the failed disk. As I understand vinum ccd (please correct me if I am wrong), this will keep ccd from ever achieving the performance and ease of use of vinum. I use vinum for a simple mirror, and found it easier to configure than ccd. Keeping it from running in 5.0 would probably kill a lot of setups. Thanks, Dan -- Daniel D Holmes, N7NKR I'net: [EMAIL PROTECTED] Standard disclaimers apply wherever you can find a sticky spot. I'm betting that I'm just abnormal enough to survive. -- The Tick To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] vinum drives lost
In message [EMAIL PROTECTED], Daniel Holmes write s: As I understand vinum ccd (please correct me if I am wrong), this will keep ccd from ever achieving the performance and ease of use of vinum. I don't think anybody advocated ccd as a wholesale replacement for vinum. That being said, I have lost more data on vinum RAID5 volumes than on striped ccd parititions, and not becaue of hardware failures. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] vinum drives lost
On Fri, 4 Oct 2002, John Baldwin wrote: On 04-Oct-2002 Julian Elischer wrote: On Fri, 4 Oct 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Lars Eggert writes: This is a cryptographically signed message in MIME format. --ms040706010906030302070807 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Poul-Henning Kamp wrote: I would need to look at the code to be able to tell, I don't have time for that. I'd consider not having vinum work under geom a show-stopper... at least until geom can stripe. Well, the showstopper is in vinum. The fact that ccd(4) works seamlessly with GEOM is testament to this. There are numerous architectural issues which have never been fixed in vinum, and one or more of these bits now. Whoever loves vinum will have to chase it/them down and fix it. No, it is established principal tha the importer of new features has the responsibility to make older subsystems work. Oh, you mean like KSE on Alpha? What existing functionality on the alpha does KSE stop? -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] vinum drives lost
On Fri, 4 Oct 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Ju lian Elischer writes: No, it is established principal tha the importer of new features has the responsibility to make older subsystems work. I'm _so_ glad to hear _you_ say that: When will you have made KSE work on sparc64 and ia64 ? Those are Tier2 platforms :-) -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] vinum drives lost
On 04-Oct-2002 Julian Elischer wrote: On Fri, 4 Oct 2002, John Baldwin wrote: On 04-Oct-2002 Julian Elischer wrote: On Fri, 4 Oct 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Lars Eggert writes: This is a cryptographically signed message in MIME format. --ms040706010906030302070807 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Poul-Henning Kamp wrote: I would need to look at the code to be able to tell, I don't have time for that. I'd consider not having vinum work under geom a show-stopper... at least until geom can stripe. Well, the showstopper is in vinum. The fact that ccd(4) works seamlessly with GEOM is testament to this. There are numerous architectural issues which have never been fixed in vinum, and one or more of these bits now. Whoever loves vinum will have to chase it/them down and fix it. No, it is established principal tha the importer of new features has the responsibility to make older subsystems work. Oh, you mean like KSE on Alpha? What existing functionality on the alpha does KSE stop? So you agree that requiring vinum users to turn off GEOM is ok? Part of adding a new feature is providing proof of concept that it works for more than just one tiny case. Also, if you actually have to make it work on multiple cases, then you have to learn enough about other cases to better enable you to make better-informed design decisions that take other cases into account. One KSE works on i386, what are multithreaded ports like, oh, X, supposed to do when compiling with -lpthread doesn't work? -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] vinum drives lost
On Fri, 4 Oct 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Ju lian Elischer writes: No, it is established principal tha the importer of new features has the responsibility to make older subsystems work. I'm _so_ glad to hear _you_ say that: When will you have made KSE work on sparc64 and ia64 ? When it works on i386. In case you haven't noticed, KSE is not a legacy facility. love you too. XXX -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] vinum drives lost
In message [EMAIL PROTECTED], Daniel E ischen writes: On Fri, 4 Oct 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Ju lian Elischer writes: No, it is established principal tha the importer of new features has the responsibility to make older subsystems work. I'm _so_ glad to hear _you_ say that: When will you have made KSE work on sparc64 and ia64 ? Those are Tier2 platforms :-) And ? Vinum is a tier2 feature. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] vinum drives lost
On Fri, 4 Oct 2002, John Baldwin wrote: Oh, you mean like KSE on Alpha? What existing functionality on the alpha does KSE stop? So you agree that requiring vinum users to turn off GEOM is ok? Part of adding a new feature is providing proof of concept that it works for more than just one tiny case. Also, if you actually have to make it work on multiple cases, then you have to learn enough about other cases to better enable you to make better-informed design decisions that take other cases into account. One KSE works on i386, what are multithreaded ports like, oh, X, supposed to do when compiling with -lpthread doesn't work? I'm not making KSE the default. The discussion is about default settings. The ports of KSE to other architectures will be rather minor but it's pointless to do it until the MI parts settle down. It's not worth more discussion than this. If we ned to turn off GEOM to run vinum then ok, it's not a major problem. I think it's the GEOM author's job to make it work, but if core doesn't tjink he needs to bother, that's just a reflection on FreeBSD, not me. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] vinum drives lost
Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Ju lian Elischer writes: No, it is established principal tha the importer of new features has the responsibility to make older subsystems work. I'm _so_ glad to hear _you_ say that: When will you have made KSE work on sparc64 and ia64 ? What does KSE break, which used to work on these platforms? It's not like CAM (to pick an older example that has less emotion bound up in it), where every SCSI driver that hadn't already been CAM-ified at the time of the import, broke. When KSE doesn't work, you lose only new features, not old ones, right? Isn't complaining about this on sparc64/ia64/alpha kind of like complaining about someone adding 4M page support to i386, but not adding the same thing to other platforms? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] vinum drives lost
On Fri, 4 Oct 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Daniel E ischen writes: On Fri, 4 Oct 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Ju lian Elischer writes: No, it is established principal tha the importer of new features has the responsibility to make older subsystems work. I'm _so_ glad to hear _you_ say that: When will you have made KSE work on sparc64 and ia64 ? Those are Tier2 platforms :-) And ? Vinum is a tier2 feature. I make no judgement about vinum. Just the comment about KSE working on sparc64 and ia64. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] vinum drives lost
At 9:02 PM +0200 10/4/02, Poul-Henning Kamp wrote: There are numerous architectural issues which have never been fixed in vinum, and one or more of these bits now. Whoever loves vinum will have to chase it/them down and fix it. If I receive patches or requests for changes to GEOM as result of this, they will be evaluated in good faith. Worst case you will have the option to use: options NOGEOM options vinum I know nothing about vinum and only a little about GEOM, so I have no opinion on which should be fixed to work with the other, and I'm reluctant to get drawn into that battle anyway. However, I do think that if it isn't easy to get the two of them to work together nicely, then we should enforce the above options in the source code. Ie, if someone tries to compile a kernel with both GEOM and vinum turned on, then the compile should fail with some suitable error message. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
