Re: about GEOM 'geoms' chain question
In message <[EMAIL PROTECTED]>, "kai ouyang" writes: >If we add a partition 'da0s1h' to the box, when we excute the g_attach() >function, >it will call redo_rank(). My viewpoint is that the 'DEV'(da0s1h) should >been added between 'Sda0' and 'Mda1'. Based my understanding on >'redo_rank', this function will change all the 'rank' of the elements on >the chain, right? >'ad1', 'ad2' and their branches is irrelevant to 'ad0', why their rank must >change? The "rank" number is used to detect loops in the topology. You may want to browse the slides from my GEOM tutorial at EuroBSDCon: http://2002.eurobsdcon.org/papers/ -- 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
about GEOM 'geoms' chain question
Hi, Poul-Henning This is my DP2 box's info about 'GEOM' when power on with 'boot -v'. GEOM: new disk da0 GEOM: new disk da1 GEOM: new disk da2 MBR Slice 1 on da0: 80 01 01 00 a5 fe ff 7b 3f 00 00 00 3d a8 da 00 |...{?...=...| [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):123/254/255 s:63 l:14329917 GEOM: Add da0s1, start 32256 length 7336917504 end 7336949759 GEOM: Configure da0c, start 0 length 36701167104 end 36701167103 GEOM: Configure da0e, start 0 length 36701167104 end 36701167103 MBR Slice 1 on da1: 80 01 01 00 a5 fe ff 7b 3f 00 00 00 3d a8 da 00 |...{?...=...| [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):123/254/255 s:63 l:14329917 GEOM: Add da1s1, start 32256 length 7336917504 end 7336949759 GEOM: Configure da1c, start 0 length 36701167104 end 36701167103 MBR Slice 1 on da2: 80 01 01 00 a5 fe bf 7c 3f 00 00 00 fe 25 9c 00 |...|?%..| [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):124/254/191 s:63 l:10233342 GEOM: Add da2s1, start 32256 length 5239471104 end 5239503359 MBR Slice 2 on da2: 80 00 81 7d a5 fe ff ff 3d 26 9c 00 3d 26 9c 00 |...}=&..=&..| [1] f:80 typ:165 s(CHS):125/0/129 e(CHS):255/254/255 s:10233405 l:10233405 GEOM: Add da2s2, start 5239503360 length 5239503360 end 10479006719 GEOM: Configure da0s1a, start 0 length 134217728 end 134217727 GEOM: Configure da0s1b, start 134217728 length 244629504 end 378847231 GEOM: Configure da0s1c, start 0 length 7336917504 end 7336917503 GEOM: Configure da0s1d, start 378847232 length 268435456 end 647282687 GEOM: Configure da0s1e, start 647282688 length 268435456 end 915718143 GEOM: Configure da0s1f, start 915718144 length 6421199360 end 7336917503 GEOM: Configure da1s1a, start 0 length 134217728 end 134217727 GEOM: Configure da1s1b, start 134217728 length 244629504 end 378847231 GEOM: Configure da1s1c, start 0 length 7336917504 end 7336917503 GEOM: Configure da1s1d, start 378847232 length 268435456 end 647282687 GEOM: Configure da1s1e, start 647282688 length 268435456 end 915718143 GEOM: Configure da1s1f, start 915718144 length 6421199360 end 7336917503 GEOM: Configure da2s1c, start 0 length 5239471104 end 5239471103 GEOM: Configure da2s1e, start 0 length 5239471104 end 5239471103 GEOM: Configure da2s2c, start 0 length 5239503360 end 5239503359 GEOM: Configure da2s2e, start 0 length 524288000 end 524287999 I am studying your geom code, let me talk my understanding firstly: 'geoms' is a globe var, from the above info and code, my point is: begin: geoms.tqh_first=NULL, geoms.tqe_prev=&geoms.tqh_first; end: geoms chain is -> -> -> ->->->->->-> -> geoms da0 da1 da2 Mda0 Sda0 Mda1 Sda1 Mda2 Sda2_1 Sda2_2- ^| <- <- <- <-<-<-<-<-<- <- | - - - - - - - - - - - - - - - - - - - - - I am not sure whether this chain is right? If we add a partition 'da0s1h' to the box, when we excute the g_attach() function, it will call redo_rank(). My viewpoint is that the 'DEV'(da0s1h) should been added between 'Sda0' and 'Mda1'. Based my understanding on 'redo_rank', this function will change all the 'rank' of the elements on the chain, right? 'ad1', 'ad2' and their branches is irrelevant to 'ad0', why their rank must change? Thank your help so much! Best Regards Ouyang Kai _ ÏíÓÃÊÀ½çÉÏ×î´óµÄµç×ÓÓʼþϵͳ¡ª MSN Hotmail¡£ http://www.hotmail.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: About DEVFS (was: Re: About GEOM...)
On 5 Jul 2002, Vladimir B. Grebenschikov wrote: > May be same mechanism as hints, like: > hint.sio.0.mode=0622 As long as we are throwing out ideas: Aside from the fact that it's broken and at the moment wouldn't exactly DTRT, I always figured a type of mount_unionfs() with the older filesystem /dev as the upper layer and devfs as the lower layer would be the way to go. -Paul. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: About DEVFS (was: Re: About GEOM...)
÷ Fri, 05.07.2002, × 06:39, Terry Lambert ÎÁÐÉÓÁÌ: > > Loader? > > ie on shutdown write a list of permissions etc into a file which the > > loader can slurp up next boot and shove into the kernel and be parsed. > > This really doesn't work very well. You end up with two sets of > data. Having done something like this in practice, and had to live > with the aftermath, I don't recommend it (at all). May be same mechanism as hints, like: hint.sio.0.mode=0622 why not ? Symantic very similar (there are some kernel-hardcoded values and some loader-supplied) > > > But overall, it seems to be a move forward. agree. > -- Terry -- Vladimir B. Grebenschikov [EMAIL PROTECTED], SWsoft, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: About GEOM...
On Thu, 4 Jul 2002, Greg 'groggy' Lehey wrote: > I don't know enough about GEOM to embrace it whole-heartedly, but I > think you'd be hard pressed to find anybody who disagrees that devfs > is a forward. It may need some improvement, but it's so much more > logical than what we had before that I really think you should explain > your objections. This has been discussed before. Basically, devfs creates work by moving problems around without any significant benefits. I expect control of devfs device visibility and persistence of devfs device attributes would end up mostly in a utility (devd?). But once you have such a utility, you don't need devfs (or MAKEDEV). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: About GEOM...
On Wed, 3 Jul 2002, Terry Lambert wrote: > Bruce Evans wrote: > > On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: > > > Some bits are missing yet, for instance the ioctls to change > > > disklabels etc. when they're done and it works also with sysinstall > > > it'll be standard. > > > > It shouldn't be standard, because then using it wouldn't be optional. > > Are you kidding?!? > > That's why it *should* be standard! I don't plan to use it, so making it standard would just get in my way. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: About GEOM...
Greg 'groggy' Lehey wrote: On Thursday, 4 July 2002 at 19:20:00 +1000, Bruce Evans wrote: On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED]"><[EMAIL PROTECTED]>, Bruce Evans writes: This is mostly because resources have been diverted away from updating working code to write a second system. Make that third system, the current slice/label code is our second system, and I don't think the resources have been diverted as much as defected. Either way, I know you don't want either of DEVFS or GEOM, I think I know where you come from, I just happen to not agree that we should stay stuck back there. I disagree that DEVFS and GEOM are forwards. I don't know enough about GEOM to embrace it whole-heartedly, but I think you'd be hard pressed to find anybody who disagrees that devfs is a forward. It may need some improvement, but it's so much more logical than what we had before that I really think you should explain your objections. DEVFS would be an improvement for me, when upgrading boxes by adding additional hardware, so I don't have to browse the dmesg, coz I will just look up /dev (since it only shows installed hardware with DEVFS). Same for GEOM, if all that will work what's described on phk's website about GEOM, then it's definitely an improvement too. I'm especially seeing forward for Copy-on-Write and encryption functionality. -mg
Re: About GEOM...
On Thursday, 4 July 2002 at 19:20:00 +1000, Bruce Evans wrote: > On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: > >> In message <[EMAIL PROTECTED]>, Bruce Evans writes: >>> This is mostly because resources have been diverted away from updating >>> working code to write a second system. >> >> Make that third system, the current slice/label code is our second >> system, and I don't think the resources have been diverted as much >> as defected. >> >> Either way, I know you don't want either of DEVFS or GEOM, I think >> I know where you come from, I just happen to not agree that we >> should stay stuck back there. > > I disagree that DEVFS and GEOM are forwards. I don't know enough about GEOM to embrace it whole-heartedly, but I think you'd be hard pressed to find anybody who disagrees that devfs is a forward. It may need some improvement, but it's so much more logical than what we had before that I really think you should explain your objections. 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: About GEOM...
On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Bruce Evans writes: > >This is mostly because resources have been diverted away from updating > >working code to write a second system. > > Make that third system, the current slice/label code is our second > system, and I don't think the resources have been diverted as much > as defected. > > Either way, I know you don't want either of DEVFS or GEOM, I think > I know where you come from, I just happen to not agree that we > should stay stuck back there. I disagree that DEVFS and GEOM are forwards. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: About GEOM...
On Wed, Jul 03, 2002 at 11:59:47AM +0200, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Jul > ian Elischer writes: > > >aren't you suppost to be honeymooning from yesterday? > > I am, I'm not working, only doing things I do for fun :-) Like reading Linux source code? 8-) -- | / o / /_ _ FreeBSD core team secretary |/|/ / / /( (_) Bulte [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: About GEOM...
Bruce Evans wrote: > On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: > > In message <[EMAIL PROTECTED]>, Mario Goebbels writes: > > >And the second is, when will it be officially activated? Seems to work > > >fine yet (toying around with it). > > > > Some bits are missing yet, for instance the ioctls to change > > disklabels etc. when they're done and it works also with sysinstall > > it'll be standard. > > It shouldn't be standard, because then using it wouldn't be optional. Are you kidding?!? That's why it *should* be standard! -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: About GEOM...
Sick sick sick :-) On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Jul > ian Elischer writes: > > >aren't you suppost to be honeymooning from yesterday? > > I am, I'm not working, only doing things I do for fun :-) > > -- > 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 > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: About GEOM...
In message <[EMAIL PROTECTED]>, Bruce Evans writes: >On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: > >> In message <[EMAIL PROTECTED]>, Bruce Evans writes: >> >On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: >> >> Some bits are missing yet, for instance the ioctls to change >> >> disklabels etc. when they're done and it works also with sysinstall >> >> it'll be standard. >> > >> >It shouldn't be standard, because then using it wouldn't be optional. >> >> It will be standard because the current code does not support at >> least two of our platforms for normal disk sizes and none of our >> platforms for big disk sizes. > >This is mostly because resources have been diverted away from updating >working code to write a second system. Make that third system, the current slice/label code is our second system, and I don't think the resources have been diverted as much as defected. Either way, I know you don't want either of DEVFS or GEOM, I think I know where you come from, I just happen to not agree that we should stay stuck back there. -- 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: About GEOM...
On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Bruce Evans writes: > >On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: > >> Some bits are missing yet, for instance the ioctls to change > >> disklabels etc. when they're done and it works also with sysinstall > >> it'll be standard. > > > >It shouldn't be standard, because then using it wouldn't be optional. > > It will be standard because the current code does not support at > least two of our platforms for normal disk sizes and none of our > platforms for big disk sizes. This is mostly because resources have been diverted away from updating working code to write a second system. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: About GEOM...
In message <[EMAIL PROTECTED]>, Bruce Evans writes: >On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: > >> In message <[EMAIL PROTECTED]>, Mario Goebbels writes: >> >And the second is, when will it be officially activated? Seems to work >> >fine yet (toying around with it). >> >> Some bits are missing yet, for instance the ioctls to change >> disklabels etc. when they're done and it works also with sysinstall >> it'll be standard. > >It shouldn't be standard, because then using it wouldn't be optional. It will be standard because the current code does not support at least two of our platforms for normal disk sizes and none of our platforms for big disk sizes. -- 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: About GEOM...
On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Mario Goebbels writes: > >And the second is, when will it be officially activated? Seems to work > >fine yet (toying around with it). > > Some bits are missing yet, for instance the ioctls to change > disklabels etc. when they're done and it works also with sysinstall > it'll be standard. It shouldn't be standard, because then using it wouldn't be optional. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: About GEOM...
On Wed, 2002-07-03 at 10:59, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Jul > ian Elischer writes: > > >aren't you suppost to be honeymooning from yesterday? > > I am, I'm not working, only doing things I do for fun :-) Isn't it a bit worrying when the two overlap? :) -- Simon Dick [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: About GEOM...
In message <[EMAIL PROTECTED]>, Jul ian Elischer writes: >aren't you suppost to be honeymooning from yesterday? I am, I'm not working, only doing things I do for fun :-) -- 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: About GEOM...
aren't you suppost to be honeymooning from yesterday? On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: About GEOM...
In message <[EMAIL PROTECTED]>, Mario Goebbels writes: >Hi! > >I have some questions about it. > >The first one is, when I compiled GEOM into the kernel, will physical >disks be controlled by it already? Or does it apply to md mounted >devices yet? all disks should be GEOM'ized. >And the second is, when will it be officially activated? Seems to work >fine yet (toying around with it). Some bits are missing yet, for instance the ioctls to change disklabels etc. when they're done and it works also with sysinstall it'll be standard. Before 5.0 if at all possible. -- 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
About GEOM...
Hi! I have some questions about it. The first one is, when I compiled GEOM into the kernel, will physical disks be controlled by it already? Or does it apply to md mounted devices yet? And the second is, when will it be officially activated? Seems to work fine yet (toying around with it). Thanks for any infos. Cheers -mg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message