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-hackers 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-hackers 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-hackers 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-hackers 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-hackers 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-hackers 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-hackers 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
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-hackers 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-hackers 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-hackers 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-hackers 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-hackers 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-hackers 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-hackers 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-hackers in the body of the message
Re: [ GEOM tests ] vinum drives lost
Lars Eggert wrote: Poul-Henning Kamp 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. I just replaced vinum with ccd on one machine, and it works fine with geom enabled, FYI. Performance between the two is also comparable. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
