Date: Sat, 26 Aug 2000 22:53:00 -0400 From: hspio@worldnet.att.net To: hackers@FreeBSD.ORG, owner-freebsd-hackers-digest@FreeBSD.ORG Subject: UNSUBSCRIBE REMOVE Message-ID: <39A84A4C.20198.175588@localhost> In-Reply-To: <bulk.71588.20000822094744@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 22 Aug 2000, at 9:47, freebsd-hackers-digest wrote: > > freebsd-hackers-digest Tuesday, August 22 2000 Volume 04 : Number 927 > > > > In this issue: > [PATCH] 3-button microsoft-type serial mouse > Updated driver for Mylex 160/170/352/2000/3000 controllers > UNSUBSCRIBE > Re: quotas and file creditentials > Re: [PATCH] 3-button microsoft-type serial mouse > Re: quotacheck on a live filesystem; safe? (fwd) > Re: freebsd and non-preemtive threads > Re: freebsd and non-preemtive threads > Memory Mapping > Re: Memory Mapping > Advanced OS Questions only you can answer... > Re: Advanced OS Questions only you can answer... > Re: Advanced OS Questions only you can answer... > Re: Advanced OS Questions only you can answer... > IBM ServerRaid > Re: Advanced OS Questions only you can answer... > kernel debugging on 4.1-release > > ---------------------------------------------------------------------- > > Date: Mon, 21 Aug 2000 19:37:03 +0300 > From: Ruslan Ermilov <ru@FreeBSD.org> > Subject: [PATCH] 3-button microsoft-type serial mouse > > - --8t9RHnE3ZwKMSgU+ > Content-Type: text/plain; charset=us-ascii > > Hi! > > I have a 3-button microsoft-type serial mouse (I do not know the vendor, > only FCC ID if needed) which generates the `middle button down' event as > previous `button down/up' event (any). Attached are: > > 1. the script(1) output of unmodified moused(8) with comments on events. > 2. the patch that makes my mouse's 3rd button work. > > > Cheers, > - -- > Ruslan Ermilov Oracle Developer/DBA, > ru@sunbay.com Sunbay Software AG, > ru@FreeBSD.org FreeBSD committer, > +380.652.512.251 Simferopol, Ukraine > > http://www.FreeBSD.org The Power To Serve > http://www.oracle.com Enabling The Information Age > > - --8t9RHnE3ZwKMSgU+ > Content-Type: text/plain; charset=us-ascii > Content-Disposition: attachment; filename="moused.script" > > Script started on Mon Aug 21 18:55:26 2000 > perl# moused -d -f -p /dev/cuaa1 > moused: PnP COM device rev 1.0 probe... > moused: modem status 03 > moused: alternate probe... > moused: pnpwakeup2(): valid response. > moused: M 4d > moused: non-PnP mouse 'M' > moused: PnP serial mouse: 'PNP0F01' '' '' > moused: proto params: 40 40 40 00 3 dc 00 > moused: port: /dev/cuaa1 interface: serial type: microsoft model: generic > > Left button pressed: > > moused: received char 0x60 > moused: received char 0x0 > moused: received char 0x0 > moused: assembled full packet (len 3) 60,0,0,0,0,0,0,0 > moused: tv: 966873379 603859 > moused: : 966873377 3320 > moused: flags:00000001 buttons:00000001 obuttons:00000000 > moused: activity : buttons 0x00000001 dx 0 dy 0 dz 0 > moused: mstate[0]->count:1 > moused: button 1 count 1 > > Left button released: > > moused: received char 0x40 > moused: received char 0x0 > moused: received char 0x0 > moused: assembled full packet (len 3) 40,0,0,0,0,0,0,0 > moused: tv: 966873380 693550 > moused: flags:00000001 buttons:00000000 obuttons:00000001 > moused: activity : buttons 0x00000000 dx 0 dy 0 dz 0 > moused: mstate[0]->count:1 > moused: button 1 count 0 > > Right button pressed: > > moused: received char 0x50 > moused: received char 0x0 > moused: received char 0x0 > moused: assembled full packet (len 3) 50,0,0,0,0,0,0,0 > moused: tv: 966873382 523875 > moused: : 966873377 3320 > moused: flags:00000004 buttons:00000004 obuttons:00000000 > moused: activity : buttons 0x00000004 dx 0 dy 0 dz 0 > moused: mstate[2]->count:1 > moused: button 3 count 1 > > Right button released: > > moused: received char 0x40 > moused: received char 0x0 > moused: received char 0x0 > moused: assembled full packet (len 3) 40,0,0,0,0,0,0,0 > moused: tv: 966873383 493579 > moused: flags:00000004 buttons:00000000 obuttons:00000004 > moused: activity : buttons 0x00000000 dx 0 dy 0 dz 0 > moused: mstate[2]->count:1 > moused: button 3 count 0 > > Middle button pressed: > > moused: received char 0x40 > moused: received char 0x0 > moused: received char 0x0 > moused: assembled full packet (len 3) 40,0,0,0,0,0,0,0 > > Middle button released: > > moused: received char 0x40 > moused: received char 0x0 > moused: received char 0x0 > moused: assembled full packet (len 3) 40,0,0,0,0,0,0,0 > perl# exit > > Script done on Mon Aug 21 18:56:28 2000 > > - --8t9RHnE3ZwKMSgU+ > Content-Type: text/plain; charset=us-ascii > Content-Disposition: attachment; filename="moused.c.patch" > > Index: moused.c > =================================================================== > RCS file: /home/ncvs/src/usr.sbin/moused/moused.c,v > retrieving revision 1.45 > diff -u -p -r1.45 moused.c > - --- moused.c 2000/04/21 14:20:25 1.45 > +++ moused.c 2000/08/21 16:09:44 > @@ -1660,8 +1660,7 @@ r_protocol(u_char rBuf, mousestatus_t *a > ? MOUSE_BUTTON2DOWN > : butmapmss[(pBuf[0] & MOUSE_MSS_BUTTONS) >> 4]; > else > - - act->button |= (act->obutton & MOUSE_BUTTON2DOWN) > - - | butmapmss[(pBuf[0] & MOUSE_MSS_BUTTONS) >> 4]; > + act->button |= butmapmss[(pBuf[0] & MOUSE_MSS_BUTTONS) >> 4]; > > /* Send X10 btn events to remote client (ensure -128-+127 range) */ > if ((rodent.rtype == MOUSE_PROTO_X10MOUSEREM) && > @@ -1676,6 +1675,10 @@ r_protocol(u_char rBuf, mousestatus_t *a > > act->dx = (char)(((pBuf[0] & 0x03) << 6) | (pBuf[1] & 0x3F)); > act->dy = (char)(((pBuf[0] & 0x0C) << 4) | (pBuf[2] & 0x3F)); > + > + if (act->button == act->obutton && !act->dx && !act->dy) > + act->button |= MOUSE_BUTTON2DOWN; > + > break; > > case MOUSE_PROTO_GLIDEPOINT: /* GlidePoint */ > > - --8t9RHnE3ZwKMSgU+-- > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Mon, 21 Aug 2000 14:38:17 -0700 > From: Mike Smith <msmith@freebsd.org> > Subject: Updated driver for Mylex 160/170/352/2000/3000 controllers > > The next BETA version of the 'mly' driver for Mylex's current family of > PCI SCSI RAID controllers is now available from > http://people.freebsd.org/~msmith/RAID/index.html#mylex. > > The major change in this version is the addition of status monitoring; the > driver is now aware of the array status and will report drive status at > attach time in the SCSI INQUIRY data, as well as logging status events. > > I don't have a 4.x system to test on at this stage, so I'm not trying to > make the driver work on 4.x. Having said that, the issues involved in > fixing it for 4.x are probably small, and if an interested user can > provide me with a little assistance, I'm sure I can sort it out. > > Thanks as usual to Mylex for the hardware and data, and BSDi for funding > this work. > > - -- > ... every activity meets with opposition, everyone who acts has his > rivals and unfortunately opponents also. But not because people want > to be opponents, rather because the tasks and relationships force > people to take different points of view. [Dr. Fritz Todt] > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Mon, 21 Aug 2000 17:28:29 -0400 > From: hspio@worldnet.att.net > Subject: UNSUBSCRIBE > > On 19 Aug 2000, at 2:58, freebsd-hackers-digest wrote: > > > > > freebsd-hackers-digest Saturday, August 19 2000 Volume 04 : Number= > 925 > > > > > > > > In this issue: > > Re: Critical (or equivalent) section in Userland? > > Re: Critical (or equivalent) section in Userland? > > Re: 'group' in ioctl() > > RE: Bootable CD... > > Re: Critical (or equivalent) section in Userland? > > Loading font with libvgl > > Date: Fri, 18 Aug 2000 14:18:38 +0200 > > Fellow Writer > > Re: Fellow Writer > > Re: Anyone try the new dual-head G-400 drivers? > > Re: Anyone try the new dual-head G-400 drivers? > > Re: Fellow Writer > > Re: RE: what to do about /tmp > > Re: Bootable CD... > > Re: Mosix in FreeBSD. > > Re: Mosix in FreeBSD. > > Re: Bootable CD... > > Cheap 1000Gbyte machine > > Re: Cheap 1000Gbyte machine > > 64bit Ethernet Controllers > > Re: Cheap 1000Gbyte machine > > Re: Cheap 1000Gbyte machine > > Re: Cheap 1000Gbyte machine > > Re: Cheap 1000Gbyte machine > > RE: Cheap 1000Gbyte machine > > Re: Cheap 1000Gbyte machine > > Re: Cheap 1000Gbyte machine > > Re: Critical (or equivalent) section in Userland? > > Re: Cheap 1000Gbyte machine > > Re: Critical (or equivalent) section in Userland? > > Re: Cheap 1000Gbyte machine > > Re: Cheap 1000Gbyte machine > > Re: Cheap 1000Gbyte machine > > Re: Cheap 1000Gbyte machine > > Re: 64bit Ethernet Controllers > > Re: Bootable CD... > > IEEE1394 driver system for -current > > > > ---------------------------------------------------------------------- > > > > Date: Fri, 18 Aug 2000 07:49:32 +0100 > > From: Karl Pielorz <kpielorz@tdx.co.uk> > > Subject: Re: Critical (or equivalent) section in Userland? > > > > Warner Losh wrote: > > > > > Kill sendmail's root process. That's the best you can do. It won't > > > impact anything, it will prevent the reading of the queue files (and > > > the config files) and the children will just run with the old copies. > > > then you wait for all the children to die (with a reasonable > > > timeout). Then you do your change, then restart sendmail. That's the > > > best you can hope for. > > > > Unforuntately this doesn't work, as sendmails numerous children live for= > too > > long (the machine is a busy MX, and people increasingly mail 5Mb+ files > > around) > > > > Also adding to the children's lives is the fact that sendmail uses cache= > d > > connections to delivery multiple messages to the same destination MX, wh= > ich > > leads to even longer 'death' times, and can also result in Sendmail's ki= > ds > > looking up domains etc. in the config files :( [At least, that's what ap= > pears > > to be happening after a lot of observation]... > > > > However, 'killall -SIGSTOP sendmail' - appears to work very nicely... Wi= > th a > > 'killall -SIGCONT sendmail' putting things back to normal. I'm also doin= > g the > > stop twice for good measure incase anything was forking at the time. > > > > I guess only time will tell, but the signal idea seems the best so far, > > considering the other restrictions :) > > > > Regards, > > > > Karl > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > ------------------------------ > > > > Date: Fri, 18 Aug 2000 00:51:53 -0600 > > From: Warner Losh <imp@village.org> > > Subject: Re: Critical (or equivalent) section in Userland? > > > > In message <399CDC7C.F68E634@tdx.co.uk> Karl Pielorz writes: > > : However, 'killall -SIGSTOP sendmail' - appears to work very nicely... = > With a > > : 'killall -SIGCONT sendmail' putting things back to normal. I'm also do= > ing the > > : stop twice for good measure incase anything was forking at the time. > > > > No need to stop twice. > > > > : I guess only time will tell, but the signal idea seems the best so far= > , > > : considering the other restrictions :) > > > > Well, you still have the same problem as before, you've just made it > > harder to exploit. Namely, if sendmail fires up and reads one of the > > set of files, then you stop it, and start it again and reads the rest > > it is little different than the problem you had before. > > > > I would suspect it is much less likely to happen, however. > > > > Warner > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > ------------------------------ > > > > Date: Fri, 18 Aug 2000 00:53:59 -0600 > > From: Warner Losh <imp@village.org> > > Subject: Re: 'group' in ioctl() > > > > In message <20000818142650A.fujita@soum.co.jp> FUJITA Kazutoshi writes: > > : What 'group' should I use ? > > > > Pick one, it will not likely matter. Traditionally, certain groups > > have been reserved for the TTY layer, but unless you are trying to > > coexist with these sorts of interfaces, it really doesn't matter much. > > > > I would avoid the 'f' group, however, because those IOCTLs need to > > work on all file descriptors and you wouldn't want a collision. > > > > Warner > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > ------------------------------ > > > > Date: Fri, 18 Aug 2000 09:58:09 +0200 (SAST) > > From: Johan Kruger <jkruger@oskar.dev.nanoteq.co.za> > > Subject: RE: Bootable CD... > > > > Might be that you need to disklabel the image of the filesystem on > > which you copy this files, ( not talking about the mfs filesystem that > > is crunced into the kernel ) > > So, try the following. > > Mount this image by doing 'vnconfig /dev/vn0 /pathtobootimage/myimage.im= > g' > > where myimgae.img is the 2.88 M boot image. > > Now do a 'mount /dev/vn0 /mnt' > > now do a 'disklabel -B -b /mnt/boot/boot1 -s /mnt/boot/boot2 /dev/vn0 > > > > Something like above, try and see if it works. > > If it doesn't create a new filesystem, do newfs and disklabel, then copy= > all > > those files of yours onto the filesystem. > > You actually don't need all those files. > > Anyways, i think it's the bootloader itself thats not loading the kernel= > on the > > CD ( inside the 2.88 M) image. And to correct that you need to reinstall= > the > > bootloader, and the bootblocks. > > That is boot0 to boot2 > > > > > > On 17-Aug-00 Patrick Bihan-Faou wrote: > > > Hi, > > > > > > > > > I am trying to build a bootable CD... Now this sounds like something t= > rivial > > > enough to do when you know what you are doing. In my case I must admit= > that > > > I am somewhat confused. > > > > > > Until now, I think that the trick was to make the CD look like a flopp= > y and > > > boot it as such. I have created some bootable CDs in the past and they > > > seemed to work OK. > > > > > > However it looks like things have changed recently in the way CD-Roms = > are > > > booted, and I am not able to create a working CD anymore. > > > > > > What I would like to clarify is what needs to be in the "2.88 M" boota= > ble > > > image ? > > > > > > Here is what I have: > > > > > > /boot > > > /boot0 > > > /boot1 > > > /boot2 > > > /loader > > > /cdboot > > > /pxeboot > > > /loader.config > > > /loader.rc > > > /boot.config > > > /kernel.config > > > /kernel.gz > > > /modules > > > ... > > > /usr/sbin > > > ibcs2 > > > linux > > > svr4 > > > > > > > > > Now whenever I boot this image, the loader dies displaying a all whack= > hex > > > values and saying "BTX Halted". > > > > > > > > > I am a bit confused as to what to do next, and I would really apprecia= > te any > > > help. > > > > > > BTW I am working on a fresh copy of FreeBSD 4.1-STABLE (checked-out Au= > gust > > > 15). > > > > > > > > > Patrick. > > > > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-hackers" in the body of the message > > > > - ---------------------------------- > > E-Mail: Johan Kruger <jkruger@oskar.dev.nanoteq.co.za> > > Date: 18-Aug-00 > > Time: 09:49:10 > > > > This message was sent by XFMail > > - ---------------------------------- > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > ------------------------------ > > > > Date: Fri, 18 Aug 2000 07:52:17 +0000 > > From: Tony Finch <dot@dotat.at> > > Subject: Re: Critical (or equivalent) section in Userland? > > > > Karl Pielorz <kpielorz@tdx.co.uk> wrote: > > > > > >I don't think advisory locks will work - the other process is sendmail.= > .. I > > >have to keep it from opening any of it's config files, whilst I 'rename= > ' out > > >of place the old ones (keeping any fd's to them intact) and rename in t= > he new > > >ones... > > > > Why not append a serial number to the end of the filenames of the > > subsidiary configuration files, and modify sendmail.cf accordingly? > > Then the update procedure could be: > > (1) write all the new files as $filename.`date +%Y%d%m%H%M%S` > > (2) mv sendmail.cf.date sendmail.cf (or use `ln -sf` if you want to > > keep old files) > > (3) every day or so delete configuration files that are older than > > your maximum queue run time. > > > > This gives you atomic configuration updates. > > > > You don't need to rename the old sendmail.cf to another because > > existing fds will remain attached to the old file which isn't being > > altered, just unlinked. > > > > Tony. > > - -- > > en oeccget g mtcaa f.a.n.finch > > v spdlkishrhtewe y dot@dotat.at > > eatp o v eiti i d. fanf@covalent.net > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > ------------------------------ > > > > Date: Fri, 18 Aug 2000 10:43:24 +0200 (SAST) > > From: Johan Kruger <jkruger@oskar.dev.nanoteq.co.za> > > Subject: Loading font with libvgl > > > > Hmm, a few days back on the mailing list i saw there was > > problem with specifying a different font when using libvgl. > > Allthough this is not critical to my application, it would > > shurely enhance the look and feel of my app. > > > > So i am wondering ... is somebody working on this ? > > And nope , i cant work on it right now. *;-) > > > > Just curios > > - ---------------------------------- > > Unix Software Developer/Engineer > > E-Mail: Johan Kruger <jkruger@oskar.dev.nanoteq.co.za> > > Date: 18-Aug-00 > > Time: 10:37:54 > > > > This message was sent by XFMail > > - ---------------------------------- > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > ------------------------------ > > > > Date: Fri, 18 Aug 2000 14:18:38 +0200 > > From: rudy.gheysens@gemeenschapsonderwijs.be > > Subject: Date: Fri, 18 Aug 2000 14:18:38 +0200 > > > > Dear Sir, > > Madam, > > > > For the thirteenth time already our association is organi-zing a cartoon > > contest. Firstly, we would like to thank all parti-cipants of the 1999 > > contest. The large number of entries proves their confidence in our > > orga-nisation and this is a real incen-tive for us to do even better in > > 2001. > > We hope we can count on your collaboration and wish you a lot of success= > ! > > > > > > The President > > Rudy Gheysens > > ________________________________________ > > RULES > > > > 1. Theme: " THE SUPERMARKET ". > > > > 2. The number of entries is limited until 5. > > They shall not have been exhibited or publis-hed before. > > > > 3. The works have to be sent to the following address: > > > > EURO-KARTOENALE > > WAREGEMSESTEENWEG 113 > > B- 9770 KRUISHOUTEM - BELGIUM > > > > 4. The drawings shall have the following dimen-sions: 210 x 297 mm. The > > works shall not be provided by a passe-partout, neit-her be stuck on to = > a > > larger paper. > > The drawing must bear, on the reverse side, the surna-me, christian > > name and address of the participant. The drawings shall not bear subtitl= > es. > > > > 5. By virtue of their participation, the partici-pants > > autho-rize the organizers to publish some of their works that they have > > received. > > > > 6. The following prizes are foreseen: > > > > 1.GOLDEN EGG 50.000 BEF (1.239,46 euro) > > 2.SILVER EGG 30.000 BEF (743,68 euro) > > 3.BRONZE EGG 25.000 BEF (619,73 euro) > > 4.PRIZE OF THE E.U. 15.000 BEF (371,84 euro) > > 5.BEST BELGIUM CARTOON 10.000 BEF (247,89 euro) > > > > 7. By participating the participant lends his works to the organizers > > for exhibitions. > > The works received will remain at the dispo-sal of the organizers > > du-ring one year (until 01.11.2002). > > > > 8. The entries will only be sent back by the organizers on receiving a > > written request. The awarded works will become the property of the > > organi-zers. > > > > 9. EXTREME DATE OF ENTRY: 15.01.2001 !! > > Opening of the exhibition: Friday 15/4/2001 at 8 pm. > > _________________________________________ > > > > DEADLINE 15.01.2001 _______________________________ > > Note concerning the catalogue > > > > In order to receive the free catalogu-e, please attach FIVE (5) coupons = > " > > international reply " to cover the postage. > > These coupons ar available in your local post office. > > ______________________________________________ > > > > E.C.C. - EUROPEAN CARTOON CENTRE > > __________________________________________ > > > > Dear cartoonist > > > > Kruishoutem has the honnour to open the European cartoon Centre. > > > > The centre aims at: > > * displaying cartoons and caricatures of both national and international > > artists > > * extending the largest documentation centre regarding cartoons and > > caricatures in Europe. This documentation will be the disposal of every > > cartoonist in the world > > * keeping the available documentation and cartoons at the disposal of > > advertising agencies and designers in order to offer the cartoonists a > > forum. > > > > In order to accomplish this mission, the "Euro-kartoenale" will use its > > private collection of cartoon books, publications, magazines and origina= > l > > cartoons to start up the centre. However, this will not suffice. > > We also count on the support and cooperation of the cartoonists themselv= > es. > > This is why we make an urgent appeal to provide us with cartoon books an= > d > > catalogues (personal work or copies from your private collection), magaz= > ines > > (please send them regulary), dissertations and other suitable material. > > > > Much to our regrets we do not have the budget to reimburse you. > > > > We are looking forward to any support and will keep you informed of the > > European Cartoon centre. > > > > Rudy Gheysens > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > ------------------------------ > > > > Date: Fri, 18 Aug 2000 06:27:08 -0700 (PDT) > > From: juliangabrielcolado@overtimemail.com > > Subject: Fellow Writer > > > > - --=3D200008180907=3D > > Content-Type: text/plain;charset=3DUS-ASCII > > > > Dear fellow writer: > > > > I have come across a great new website for writers. They are a > > on-demand publisher, and are currently looking for new authors. > > They pay the best royalties in the industry, and the people there > > are writers like us. If you think you might be interested, email me > > and I can send you the link. I already have two titles up with > > them, and they have been very helpful. > > > > PS- if you're not interested, don't reply, and you won't hear from > > me again. I'm not a robot, and your name isn't on some list I > > bought. I'm just kind of a fanatic for writer's rights, and thought > > this might help out some of my fellow writers. > > > > Good luck with your writing, > > Julian Gabriel Colado > > > > > > - --=3D200008180907=3D-- > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > ------------------------------ > > > > Date: Fri, 18 Aug 2000 23:47:22 +1000 > > From: Andrew Kenneth Milton <akm@mail.theinternet.com.au> > > Subject: Re: Fellow Writer > > > > +-------[ juliangabrielcolado@overtimemail.com ]---------------------- > > | Dear fellow writer: > > | > > > > | They pay the best royalties in the industry, and the people there > > | are writers like us. > > > > The writers there are completely crap? Doesn't sound too good. > > > > - -- > > Totally Holistic Enterprises Internet| P:+61 7 3870 0066 | Andrew Mil= > ton > > The Internet (Aust) Pty Ltd | F:+61 7 3870 4477 | > > ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daem= > on > > PO Box 837 Indooroopilly QLD 4068 |akm@theinternet.com.au| > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > ------------------------------ > > > > Date: Fri, 18 Aug 2000 10:14:38 -0400 > > From: "Jeroen C. van Gelderen" <jeroen@vangelderen.org> > > Subject: Re: Anyone try the new dual-head G-400 drivers? > > > > "Alexander N. Kabaev" wrote: > > > > > > This driver will not run on FreeBSD most likely. It seems like the dri= > ver needs > > > Linux framebuffer device to run. > > > > Fortunately this doesn't seem to be the case. Works like a charm... > > > > Cheers, > > Jeroen > > - -- > > Jeroen C. van Gelderen o _ _ _ > > jeroen@vangelderen.org _o /\_ _ \\o (_)\__/o (_) > > _< \_ _>(_) (_)/<_ \_| \ _|/' \/ > > (_)>(_) (_) (_) (_) (_)' _\o_ > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > ------------------------------ > > > > Date: Fri, 18 Aug 2000 10:19:14 -0400 (EDT) > > From: "Alexander N. Kabaev" <ak03@gte.com> > > Subject: Re: Anyone try the new dual-head G-400 drivers? > > > > This is the case when I am certainly glad I was mistaken. The sentence f= > rom > > README about driver working only with framebuffer fooled me. Thanks for > > clearing my confusion. > > > > > > On 18-Aug-00 Jeroen C. van Gelderen wrote: > > > "Alexander N. Kabaev" wrote: > > >> > > >> This driver will not run on FreeBSD most likely. It seems like the dr= > iver > > >> needs > > >> Linux framebuffer device to run. > > > > > > Fortunately this doesn't seem to be the case. Works like a charm... > > > > > > Cheers, > > > Jeroen > > > -- > > > Jeroen C. van Gelderen o _ _ _ > > > jeroen@vangelderen.org _o /\_ _ \\o (_)\__/o (_) > > > _< \_ _>(_) (_)/<_ \_| \ _|/' \/ > > > (_)>(_) (_) (_) (_) (_)' _\o_ > > > > - ---------------------------------- > > E-Mail: Alexander N. Kabaev <ak03@gte.com> > > Date: 18-Aug-00 > > Time: 10:15:16 > > - ---------------------------------- > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > ------------------------------ > > > > Date: Fri, 18 Aug 2000 08:07:02 -0700 > > From: Chameleon <swen@wavefire.com> > > Subject: Re: Fellow Writer > > > > At 11:47 PM 8/18/00 +1000, Andrew Kenneth Milton wrote: > > >+-------[ juliangabrielcolado@overtimemail.com ]---------------------- > > >| Dear fellow writer: > > >| > > > > > >| They pay the best royalties in the industry, and the people there > > >| are writers like us. > > > > > >The writers there are completely crap? Doesn't sound too good. > > > > LOL > > thats a good one > > > > >-- > > >Totally Holistic Enterprises Internet| P:+61 7 3870 0066 | Andrew Mi= > lton > > >The Internet (Aust) Pty Ltd | F:+61 7 3870 4477 | > > >ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Dae= > mon > > >PO Box 837 Indooroopilly QLD 4068 |akm@theinternet.com.au| > > > > > > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org > > >with "unsubscribe freebsd-hackers" in the body of the message > > > > > > - ----------------------------------------------------------------------= > - ------------------------ > > > > > The human mind ordinarily operates at only ten percent of its capacity > > - -- the rest is overhead for the operating system. > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > ------------------------------ > > > > Date: Fri, 18 Aug 2000 08:47:06 -0700 (PDT) > > From: Matt Dillon <dillon@earth.backplane.com> > > Subject: Re: RE: what to do about /tmp > > > > : > > :Matt, > > : > > :I noticed /tmp and /var/tmp are used slightly differently, for example,= > the > > :contents of /tmp are not expected to survive a reboot, while /var/tmp i= > s > > :used for files you might need after a crash, like vi recovery files. > > > > This may have been true at one time in the past, but these days > > /tmp and /var/tmp tend to be used interchangeably. You can't make > > those sorts of assumptions. > > > > :One advantage of mounting /tmp with MFS is that you don't have use up a= > nother > > :disk partition. Performance-wise, I would think data moves something > > :like this: > > : > > :/tmp on MFS: > > : application data --> kernel VM --> paged to disk > > : > > :/tmp on FFS: > > : application data --> kernel file buffer --> flushed to disk > > : > > :Is that basically correct? What makes MFS less efficient than FFS? > > :What would be the implications of creating a 512 MB swap partition > > :and mounting an MFS /tmp? > > : > > :Thanks, > > : > > :Allen > > > > There are several problems with MFS: > > > > * The active data set is cached in memory TWICE rather then just > > once. That is, for each page of file data two pages is taken up > > of memory. > > > > * While it is true that MFS will swap unused data, performance under > > heavy load will go to pot because MFS does not in any way attempt > > to sequence the data to swap. > > > > MFS may appear fast under light loads, but performance degrades > > drastically (to much worse then what you get with FFS) under > > heavy memory loads. > > > > * MFS eats a 'random' amount of swap, up to the size of the MFS > > disk. Under medium loads where paging is taking place, the > > swap backing store for MFS becomes fragmented and performance > > goes to pot. > > > > There are two solutions: > > > > * First, you can use vnconfig to create a swap-backed filesystem > > and you can reserve the necessary swap wspace contiguously, > > resulting in performance which will be as good or better then > > a normal FFS filesystem (because your swap space may be striped > > across several disks). > > > > * Second, you can use a normal FFS partition. > > > > In either case enabling softupdates on the vnconfig or normal > > FFS partition should result in good overall peformance without > > the load penalty. > > > > With both solutions it is a good idea to make /var/tmp the partition > > and make /tmp a softlink to /var/tmp. > > > > Using MD instead of MFS is typically not a great choice. While it i= > s > > true that MD only caches data once, the data is not swap-backed so > > what data MD does allocate is allocated permanently. This is useful > > in certain system configurations but not useful in the general case. > > > > -Matt > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > ------------------------------ > > > > Date: Fri, 18 Aug 2000 11:48:21 -0400 > > From: "Patrick Bihan-Faou" <patrick@mindstep.com> > > Subject: Re: Bootable CD... > > > > Hi, > > > > > > > > > Might be that you need to disklabel the image of the filesystem on > > > which you copy this files, ( not talking about the mfs filesystem that > > > is crunced into the kernel ) > > > So, try the following. > > > Mount this image by doing 'vnconfig /dev/vn0 /pathtobootimage/myimage.= > img' > > > where myimgae.img is the 2.88 M boot image. > > > Now do a 'mount /dev/vn0 /mnt' > > > now do a 'disklabel -B -b /mnt/boot/boot1 -s /mnt/boot/boot2 /dev/vn0 > > > > Actually I am using the doFS.sh script from /usr/src/release. The diskla= > bel > > is done (without the -b and -s options though) by that script. Also I us= > ed > > to be able to build bootable CDs from the same procedure a few weeks ago > > (before the code in /usr/src/sys/boot was updated). > > > > The CD is recognized as bootable and starts to boot. I can stop the boot= > at > > the first "spinning bar" (I think that's boot0 or boot1) before the cont= > rol > > is passed to "loader". > > > > From there I am sort of stuck: the only thing I can boot is loader which= > in > > turn crashes immediately. I tried to load "kernel.gz" but its format is = > not > > recognized at this stage of the boot (probably because it is compressed)= > . > > > > > > > > BTW I tried you procedure above, and I get: > > > > su-2.03# vnconfig /dev/vn0 boot.cdrom.img > > su-2.03# mount /dev/vn0 /mnt > > su-2.03# disklabel -B -b /mnt/boot/boot1 -s /mnt/boot/boot2 /dev/vn0 > > disklabel: /dev/vn0: Device busy > > su-2.03# disklabel -B -b /mnt/boot/boot1 -s /mnt/boot/boot2 /mnt > > disklabel: /mnt: Is a directory > > su-2.03# umount /mnt > > su-2.03# disklabel -B -b mindbox/boot/boot1 -s mindbox/boot/boot2 /dev/v= > n0 > > disklabel: ioctl DIOCWLABEL: Operation not supported by device > > su-2.03# > > > > > > > > > > I'd rather fix the problem with the current version of the boot code, bu= > t > > time is pressing and I am tempted to revert to the code tagged with the > > FreeBSD-4.0 release. Is this something that I should do ? > > > > > > > > Patrick. > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > ------------------------------ > > > > Date: Fri, 18 Aug 2000 09:31:50 -0700 > > From: Marco Molteni <molter@sofia.csl.sri.com> > > Subject: Re: Mosix in FreeBSD. > > > > On Thu, 17 Aug 2000, Jes=3DFAs Arn=3DE1iz wrote: > > > > > I have read some information about MOSIX which is some patch for the l= > inux > > > kernel created to build super-computers from a net of PCs. > > >=3D20 > > > I want to know if is there some similar project (mosix or even cluster= > ing) > > > but for FreeBSD, if someone know some about it please let me know. > > > > Mosix started on BSD/OS, and was then rewritten for Linux. I think the B= > SD/=3D > > OS > > version has died, but you may ask the Mosix people, now that the *BSD ar= > e > > getting more attention... > > > > Marco > > - --=3D20 > > Marco Molteni "rough consensus and running code" > > SRI International, System Design Laboratory > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > ------------------------------ > > > > Date: Fri, 18 Aug 2000 12:41:54 +0000 > > From: Alan Clegg <abc@bsdi.com> > > Subject: Re: Mosix in FreeBSD. > > > > Out of the ether, Marco Molteni spewed forth the following bitstream: > > > > > Mosix started on BSD/OS, and was then rewritten for Linux. I think the= > BSD/OS > > > version has died, but you may ask the Mosix people, now that the *BSD = > are > > > getting more attention... > > > > I spoke to the author (one of the authors?) of Mosix at LinuxWorld this > > last week, and he was sorry to say that it was *NOT* available on *BSD* > > to the public any longer. > > > > However, the code is still up and running on BSD/OS at the University. > > > > AlanC > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > ------------------------------ > > > > Date: Fri, 18 Aug 2000 18:46:10 +0200 (SAST) > > From: Johan Kruger <jkruger@oskar.dev.nanoteq.co.za> > > Subject: Re: Bootable CD... > > > > Ok, here's what i did ( busy building a custom CD installation ) > > After the 'make release' , i took the boot.flp image 2.88 Meg and > > mounted it. I deleted everything except for /boot/boot0-2 an the > > bootforth loader. Then i made my own kernel allowing a MFS of 2048 x 512 > > blocks, giving me 1.44 Meg in the filesystem. > > In this i crunched 72 Megs of binary's , one of them 'chroot' > > I compiled init as not to look for 'rc' ( check the Makefile, define par= > t > > that's specifically for a release ) > > After this i use the write_mfs_in_kernel script and umount it ( remember= > to > > compress the kernel after the mfs write > > > > sh -e doFS.sh -s mfsroot ./ /mnt 2880 johan's_mfsfd_root_dir/ 8000 minim= > um2 > > ./write_mfs_in_kernel kernel mfsroot > > gzip -9vc kernel > kernel.gz > > vnconfig /dev/vn0 boot.flp > > mount /dev/vn0 /mnt > > rm /mnt/kernel.gz > > cp kernel.gz /mnt/kernel.gz > > umount /mnt > > vnconfig -u /dev/vn0 > > > > Now your boot.flp is ready for mkisofs > > > > Basically what happens now , i copy my complete live filesystem with > > installed apps to the CD's root dir, and when i do mkisofs, i use my new > > bootimage. After boot , since it can not find rc, it executes .profile i= > n > > the MFS filesystem in the kernel- BUT ONLY if you compiled init for the > > crunch with in /usr/src/sbin/init/Makefile > > > > #CFLAGS+=3D-DDEBUGSHELL -DSECURE -DLOGIN_CAP -DCOMPAT_SYSV_INIT > > CFLAGS+=3D-DSECURE -DLOGIN_CAP -DCOMPAT_SYSV_INIT > > > > > > In .profile i put 'mount_cd9660 /dev/acd0a /cdrom' ( /cdrom an extra dir= > i put > > in my filesystem ) and 'chroot /cdrom /setup' , where setup is my prog, = > and > > this works perfectly , i even load my own modules before the chroot and = > so on. > > > > The release i built is 5.0-CURRRENT , and if you want the boot.flp i can > > attach it for you. Just mail me. Right now i'm going home - it's Friday = > - - at > > last > > GOOD LUCK > > *;-) > > > > On 18-Aug-00 Patrick Bihan-Faou wrote: > > > Hi, > > > > > > > > > Actually I am using the doFS.sh script from /usr/src/release. The disk= > label > > > is done (without the -b and -s options though) by that script. Also I = > used > > > to be able to build bootable CDs from the same procedure a few weeks a= > go > > > (before the code in /usr/src/sys/boot was updated). > > > > > > The CD is recognized as bootable and starts to boot. I can stop the bo= > ot at > > > the first "spinning bar" (I think that's boot0 or boot1) before the co= > ntrol > > > is passed to "loader". > > > > > >>From there I am sort of stuck: the only thing I can boot is loader whi= > ch in > > > turn crashes immediately. I tried to load "kernel.gz" but its format i= > s not > > > recognized at this stage of the boot (probably because it is compresse= > d). > > > > > > > > > > > > BTW I tried you procedure above, and I get: > > > > > > su-2.03# vnconfig /dev/vn0 boot.cdrom.img > > > su-2.03# mount /dev/vn0 /mnt > > > su-2.03# disklabel -B -b /mnt/boot/boot1 -s /mnt/boot/boot2 /dev/vn0 > > > disklabel: /dev/vn0: Device busy > > > su-2.03# disklabel -B -b /mnt/boot/boot1 -s /mnt/boot/boot2 /mnt > > > > > > Patrick. > > > > > > > > > > - ---------------------------------- > > Unix Software Developer/Engineer > > E-Mail: Johan Kruger <jkruger@oskar.dev.nanoteq.co.za> > > Date: 18-Aug-00 > > Time: 18:28:20 > > > > All good things come to those who ... runs FreeBSD > > - ---------------------------------- > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > ------------------------------ > > > > Date: Fri, 18 Aug 2000 18:16:09 +0100 > > From: Jonathan Laventhol <jonathan.laventhol@imagination.co.uk> > > Subject: Cheap 1000Gbyte machine > > > > Hello Folks -- > > > > Anybody built a file server with approx 1000 Gbyte or more? > > Or even 200 Gbyte? > > > > I'm looking for a cheap simple way of doing this. Lots of > > IDE drives? (How many can you have?) Or SCSI? (Again, > > how many can you have?). > > > > It's for lots of 1 Mbyte files: no huge files. > > > > Thanks for any tips. > > > > Regards, > > Jonathan. > > - -- > > ____________________________________________________________________ > > Imagination 25 Store Street South Crescent London WC1E 7BL England | > > Tel +44 20 7323 3300 Fax +44 20 7323 5801 | > > _______________________________________________________| > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > ------------------------------ > > > > Date: Fri, 18 Aug 2000 19:20:31 +0200 > > From: Wilko Bulte <wkb@freebie.demon.nl> > > Subject: Re: Cheap 1000Gbyte machine > > > > On Fri, Aug 18, 2000 at 06:16:09PM +0100, Jonathan Laventhol wrote: > > > > > Anybody built a file server with approx 1000 Gbyte or more? > > > > Done routinely in the commercial world. But cheap.. > > > > > I'm looking for a cheap simple way of doing this. Lots of > > > > What is cheap? > > > > > IDE drives? (How many can you have?) Or SCSI? (Again, > > > how many can you have?). > > > > SCSI, behind RAID array controllers. Connected to the host via SCSI > > or Fibrechannel. > > > > - -- > > Wilko Bulte wilko@freebsd.org > > Arnhem, the Netherlands > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > ------------------------------ > > > > Date: Fri, 18 Aug 2000 13:52:39 -0400 > > From: Dennis <dennis@etinc.com> > > Subject: 64bit Ethernet Controllers > > > > Have any 64bit PCI ethernet controllers been tested in 4.x yet? Preferab= > ly > > quad port..I've seen a few around (adaptec has one) but no mention on th= > e > > list of specific experience. > > > > Dennis > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > ------------------------------ > > > > Date: Fri, 18 Aug 2000 19:45:43 +0200 (CEST) > > From: Soren Schmidt <sos@freebsd.dk> > > Subject: Re: Cheap 1000Gbyte machine > > > > It seems Jonathan Laventhol wrote: > > > Hello Folks -- > > > > > > Anybody built a file server with approx 1000 Gbyte or more? > > > > Not yet :) > > > > > Or even 200 Gbyte? > > > > Yup, 300G's standing here right next to me... > > > > > I'm looking for a cheap simple way of doing this. Lots of > > > IDE drives? (How many can you have?) Or SCSI? (Again, > > > how many can you have?). > > > > Take 3 or 4 Promise Ultra66/100's and 14 IBM 75G DTLA 307075 > > drives and you should be in business, for a very resonable > > pricetag. > > > > - -S=F8ren > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > ------------------------------ > > > > Date: Fri, 18 Aug 2000 10:44:21 -0700 (PDT) > > From: Matthew Jacob <mjacob@feral.com> > > Subject: Re: Cheap 1000Gbyte machine > > > > On Fri, 18 Aug 2000, Soren Schmidt wrote: > > > > > It seems Jonathan Laventhol wrote: > > > > Hello Folks -- > > > > > > > > Anybody built a file server with approx 1000 Gbyte or more? > > > > > > Not yet :) > > > > That's not quite true. We had ~900GB on a NetBSD/Alpha machine at NASA/A= > mes. > > > > > > > > > Or even 200 Gbyte? > > > > > > Yup, 300G's standing here right next to me... > > > > > > > I'm looking for a cheap simple way of doing this. Lots of > > > > IDE drives? (How many can you have?) Or SCSI? (Again, > > > > how many can you have?). > > > > > > Take 3 or 4 Promise Ultra66/100's and 14 IBM 75G DTLA 307075 > > > drives and you should be in business, for a very resonable > > > pricetag. > > > > > > > You know, I used to say ixnay on that, but, Soren, I've been looking at = > a lot > > of the features of the newer ATA drives, and now that they have bad bloc= > k > > replacement, I'd have to say that what you're proposing is not unreasona= > ble, > > although I'd suggest that Vinum/RAID5 be used. > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > ------------------------------ > > > > Date: Fri, 18 Aug 2000 19:52:42 +0200 (CEST) > > From: Soren Schmidt <sos@freebsd.dk> > > Subject: Re: Cheap 1000Gbyte machine > > > > It seems Matthew Jacob wrote: > > > On Fri, 18 Aug 2000, Soren Schmidt wrote: > > > > > > > It seems Jonathan Laventhol wrote: > > > > > Hello Folks -- > > > > > > > > > > Anybody built a file server with approx 1000 Gbyte or more? > > > > > > > > Not yet :) > > > > > > That's not quite true. We had ~900GB on a NetBSD/Alpha machine at NASA= > /Ames. > > > > Oh, I mean I havn't build one yet :) > > > > > > > Or even 200 Gbyte? > > > > > > > > Yup, 300G's standing here right next to me... > > > > > > > > > I'm looking for a cheap simple way of doing this. Lots of > > > > > IDE drives? (How many can you have?) Or SCSI? (Again, > > > > > how many can you have?). > > > > > > > > Take 3 or 4 Promise Ultra66/100's and 14 IBM 75G DTLA 307075 > > > > drives and you should be in business, for a very resonable > > > > pricetag. > > > > > > You know, I used to say ixnay on that, but, Soren, I've been looking a= > t a lot > > > of the features of the newer ATA drives, and now that they have bad bl= > ock > > > replacement, I'd have to say that what you're proposing is not unreaso= > nable, > > > although I'd suggest that Vinum/RAID5 be used. > > > > Nice to hear, and yes vinum is the way to go for redundancy, who is > > going to backup THAT amount of data, and on what :) > > > > - -S=F8ren > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > ------------------------------ > > > > Date: Fri, 18 Aug 2000 13:53:05 -0400 > > From: Nathan Vidican <webmaster@wmptl.com> > > Subject: Re: Cheap 1000Gbyte machine > > > > Soren Schmidt wrote: > > > > > > It seems Jonathan Laventhol wrote: > > > > Hello Folks -- > > > > > > > > Anybody built a file server with approx 1000 Gbyte or more? > > > > > > Not yet :) > > > > > > > Or even 200 Gbyte? > > > > > > Yup, 300G's standing here right next to me... > > > > > > > I'm looking for a cheap simple way of doing this. Lots of > > > > IDE drives? (How many can you have?) Or SCSI? (Again, > > > > how many can you have?). > > > > > > Take 3 or 4 Promise Ultra66/100's and 14 IBM 75G DTLA 307075 > > > drives and you should be in business, for a very resonable > > > pricetag. > > > > > > -S=F8ren > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-hackers" in the body of the message > > > > Try AreaSYS electronics, they make an external ATA to SCSI RAID system > > that operates independant of the O/S. I don't know how it would be in > > terms of performance, but you might be able to put a few of these > > devices on to a system, and use vinum/raid of the raid systems, (seeing > > as how FreeBSD would just see them as giant scsi drives). > > I believe they do a setup which houses 8 ATA disks, in which case you > > could get away with more than what you're looking for with just two > > units. > > > > - -- > > Nathan Vidican > > webmaster@wmptl.com > > Windsor Match Plate & Tool Ltd. > > http://www.wmptl.com/ > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > ------------------------------ > > > > Date: Fri, 18 Aug 2000 14:09:42 -0400 > > From: "Allen Pulsifer" <pulsifer@mediaone.net> > > Subject: RE: Cheap 1000Gbyte machine > > > > > > Anybody built a file server with approx 1000 Gbyte or more? > > > > > Take 3 or 4 Promise Ultra66/100's and 14 IBM 75G DTLA 307075 > > > drives and you should be in business, for a very resonable > > > pricetag. > > > > Might be doable, but it would probably take a custom cabinet to accomoda= > te > > the ATA/66 cabling limitations (2 drives per cable with an 18 inch maxim= > um > > length). And don't forget about heat and vibration... > > > > Allen > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > ------------------------------ > > > > Date: Fri, 18 Aug 2000 11:17:10 -0700 (PDT) > > From: Matthew Jacob <mjacob@feral.com> > > Subject: Re: Cheap 1000Gbyte machine > > > > > > > > Nice to hear, and yes vinum is the way to go for redundancy, who is > > > going to backup THAT amount of data, and on what :) > > > > Oh, you really still have to backups. But you hope you never have to > > restore... > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > ------------------------------ > > > > Date: Fri, 18 Aug 2000 12:06:57 -0700 > > From: Mike Smith <msmith@freebsd.org> > > Subject: Re: Cheap 1000Gbyte machine > > > > > > > I'm looking for a cheap simple way of doing this. Lots of > > > > > IDE drives? (How many can you have?) Or SCSI? (Again, > > > > > how many can you have?). > > > > > > > > Take 3 or 4 Promise Ultra66/100's and 14 IBM 75G DTLA 307075 > > > > drives and you should be in business, for a very resonable > > > > pricetag. > > > > > > You know, I used to say ixnay on that, but, Soren, I've been looking a= > t a lot > > > of the features of the newer ATA drives, and now that they have bad bl= > ock > > > replacement, I'd have to say that what you're proposing is not unreaso= > nable, > > > although I'd suggest that Vinum/RAID5 be used. > > > > Personally, I'd do it like this: > > > > 16 x IBM DTLA-307075 @ $550ea (approx) > > 2 x 3ware Escalade 6800 @ $500ea (approx) > > > > You can get 24" ATA-66 cables from 3ware (or get them custom cut), which= > > > will greatly simplify cable routing. Presto; a terabyte for under $10k. > > > > Since you need to use something to stripe the two arrays together anyway= > , > > it's really a matter of preference between the 3ware controllers at 8 > > drives each or your average addin ATA card at 4 drives a pop. > > > > - -- > > ... every activity meets with opposition, everyone who acts has his > > rivals and unfortunately opponents also. But not because people want > > to be opponents, rather because the tasks and relationships force > > people to take different points of view. [Dr. Fritz Todt] > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > ------------------------------ > > > > Date: Fri, 18 Aug 2000 12:31:49 -0700 (PDT) > > From: Mikko Tyolajarvi <mikko@dynas.se> > > Subject: Re: Critical (or equivalent) section in Userland? > > > > Karl Pielorz wrote: > > > > >Warner Losh wrote: > > > > >> If advisory locks won't work (and they almost always will for things > > >> like this), then you could walk the process tree. For all processes > > >> that aren't suspended or yourself, send a SIGSTOP, keep a list. > > > > >I don't think advisory locks will work - the other process is sendmail.= > .. I > > >have to keep it from opening any of it's config files, whilst I 'rename= > ' out > > >of place the old ones (keeping any fd's to them intact) and rename in t= > he new > > >ones... > > > > Warning, here be dragons... > > > > You could try replacing sendmail (using mailer.conf) with a script > > that sets LD_PRELOAD and then execs sendmail. Then you have to write > > a little shared lib to wrap some system calls. If you are lucky, > > wrapping open() will be sufficient. In your wrapper function, you > > should have the opportunity to use any of a number of mutual exclusion > > schemes, including advisory locking. > > > > Some sessions with truss/ktrace and some studying of the sendmail > > source may be necessary to get it right, but this is something I'd > > definitely check out. > > > > A wrapper for open could look like: > > > > #define open __hide_open_prototype > > #include <sys/types.h> > > #include <fcntl.h> > > #include <unistd.h> > > #undef open > > > > int > > open(const char *path, int flags, mode_t mode) > > { > > if (/* path is a file to be protected */) { > > /* do something */ > > /* and beware of calling open() recursively */ > > } > > return _open(path, flags, mode); > > } > > > > Compile with "cc -shared -o open.so -fpic open.c" > > > > Of course, this still may not help much when sendmail has opened some > > of its files, and you then change all of them, which might lead to > > inconsistencies. > > > > $.02, > > /Mikko > > > > - -- > > Mikko Ty=F6l=E4j=E4rvi_______________________________________mikko@rsas= > ecurity.com > > RSA Security > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > ------------------------------ > > > > Date: Fri, 18 Aug 2000 15:57:48 -0400 > > From: Robert Sexton <robert@kudra.com> > > Subject: Re: Cheap 1000Gbyte machine > > > > On Fri, Aug 18, 2000 at 06:16:09PM +0100, Jonathan Laventhol wrote: > > > Hello Folks -- > > > > > > Anybody built a file server with approx 1000 Gbyte or more? > > > Or even 200 Gbyte? > > > > Joe Greco did this for a news machine last year. He used several wide > > SCSI controllers, and a bunch of 36G drives, if I recall correctly. > > > > > I'm looking for a cheap simple way of doing this. Lots of > > > IDE drives? (How many can you have?) Or SCSI? (Again, > > > how many can you have?). > > > > Good, Fast, or Cheap. Pick any two :-) > > > > I'd suggest two Symbios based LVD SCSI Cards. Up to 14 drives per > > chain, with very reasonable cabling limitations. > > > > Can IDE drives release the bus during seeks? Historically thats been > > the big advantage of SCSI: Two IDE drives are no faster than one IDE > > drive, while SCSI scales in performance. > > > > - -- > > Robert Sexton - robert@kudra.com, Cincinnati OH, USA > > Anarchy: It's not the Law, It's just a good Idea. > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > ------------------------------ > > > > Date: Fri, 18 Aug 2000 21:45:14 +0100 > > From: Karl Pielorz <kpielorz@tdx.co.uk> > > Subject: Re: Critical (or equivalent) section in Userland? > > > > Mikko Tyolajarvi wrote: > > > > > Warning, here be dragons... > > > > But, they can be tamed! :) > > > > > You could try replacing sendmail (using mailer.conf) with a script > > > that sets LD_PRELOAD and then execs sendmail. Then you have to write > > > a little shared lib to wrap some system calls. If you are lucky, > > > wrapping open() will be sufficient. In your wrapper function, you > > > should have the opportunity to use any of a number of mutual exclusion > > > schemes, including advisory locking. > > > > I have recently been doing a lot of work with LD_PRELOAD and wrapping > > syscalls... (a strange co-incidence? :) - but, sending all the sendmail = > calls > > a SIGSTOP seems to have done the trick... > > > > > Of course, this still may not help much when sendmail has opened some > > > of its files, and you then change all of them, which might lead to > > > inconsistencies. > > > > My original idea of 'mv'ing the files seems to cope admirably with this.= > .. If > > sendmail open()'s one of the original files, it's FD is still valid _aft= > er_ > > the mv operations. > > > > The question has never been 'pulling the rug' from under sendmail, it's = > more > > been of keeping sendmail from talking to the rug, while I do the dirty..= > . > > > > SIGSTOP and SIGCONT seem to do the trick nicely... Yes, It's not ideal, = > but it > > seems to work perfectly well (which maybe, makes it as ideal as you can = > get in > > the real world... ? :) > > > > - -Kp > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > ------------------------------ > > > > Date: Fri, 18 Aug 2000 14:04:57 -0700 > > From: Parag Patel <parag@cgt.com> > > Subject: Re: Cheap 1000Gbyte machine > > > > On Fri, 18 Aug 2000 15:57:48 EDT, Robert Sexton wrote: > > > > > >Can IDE drives release the bus during seeks? Historically thats been > > >the big advantage of SCSI: Two IDE drives are no faster than one IDE > > >drive, while SCSI scales in performance. > > > > How about a single IDE (master) drive per controller, that is, no slave > > drives at all? This would halve the number of available drives per card > > (or require twice the number of cards) but essentially would use the PCI > > bus as a multiplex bus between drives instead of SCSI. > > > > You're still pretty much stuck waiting for one command to finish before > > another can be sent to a drive though, unlike SCSI drives. Still a lot > > cheaper tho'. > > > > I suppose another trick would be to arrange your vinum partitions and > > drive layout so that master and slave drives are never accessed > > simultaneously so one won't block access to the other. > > > > > > -- Parag Patel > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > ------------------------------ > > > > Date: Fri, 18 Aug 2000 17:18:38 -0400 (EDT) > > From: Mike Wade <mwade@cdc.net> > > Subject: Re: Cheap 1000Gbyte machine > > > > On Fri, 18 Aug 2000, Jonathan Laventhol wrote: > > > > > Hello Folks -- > > > > > > Anybody built a file server with approx 1000 Gbyte or more? > > > Or even 200 Gbyte? > > > > > > I'm looking for a cheap simple way of doing this. Lots of > > > IDE drives? (How many can you have?) Or SCSI? (Again, > > > how many can you have?). > > > > > > It's for lots of 1 Mbyte files: no huge files. > > > > > > Thanks for any tips. > > > > You might want to check out the Arena Industrial II Rackmount RAID syste= > m > > from "www.raidweb.com". It has 8 x UDMA controllers that connect to the > > host via Ultra2 SCSI (platform independant). Buy two (or more) of those > > and 16 x (60/80 gb Maxtor UMDA Drives or 75 gb IBM UMDA Drives). > > > > 2 x Arena Industrial II Rackmount RAID $3,975 > > 16 x Maxtor UDMA 60 gb Hard Drives $3,680 > > > > Total Cost $7,655 > > > > That comes out to about $7.98 / gb... > > > > - --- > > Mike Wade (mwade@cdc.net) > > Chief Technical Officer > > CDC Internet, Inc. > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > ------------------------------ > > > > Date: Fri, 18 Aug 2000 23:23:22 +0200 (CEST) > > From: Soren Schmidt <sos@freebsd.dk> > > Subject: Re: Cheap 1000Gbyte machine > > > > It seems Parag Patel wrote: > > > On Fri, 18 Aug 2000 15:57:48 EDT, Robert Sexton wrote: > > > > > > > >Can IDE drives release the bus during seeks? Historically thats been > > > >the big advantage of SCSI: Two IDE drives are no faster than one IDE > > > >drive, while SCSI scales in performance. > > > > > > How about a single IDE (master) drive per controller, that is, no slav= > e > > > drives at all? This would halve the number of available drives per ca= > rd > > > (or require twice the number of cards) but essentially would use the P= > CI > > > bus as a multiplex bus between drives instead of SCSI. > > > > > > You're still pretty much stuck waiting for one command to finish befor= > e > > > another can be sent to a drive though, unlike SCSI drives. Still a lo= > t > > > cheaper tho'. > > > > Not really, if the ATA drives are configured as single masters, they can= > > > run simultaniously, but you will still have the PCI bus speed limit :) > > Which BTW is around 120MB/s as some overhead goes to keep the system > > running (yes I have measured that :) ) > > > > And if you have modern ATA disks, they support tagged queuing as well, > > have had that running in my lab too... > > > > > I suppose another trick would be to arrange your vinum partitions and > > > drive layout so that master and slave drives are never accessed > > > simultaneously so one won't block access to the other. > > > > Endeed, that would be the easiest solution... > > > > - -S=F8ren > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > ------------------------------ > > > > Date: Fri, 18 Aug 2000 14:33:58 -0700 (PDT) > > From: Matthew Jacob <mjacob@feral.com> > > Subject: Re: Cheap 1000Gbyte machine > > > > On Fri, 18 Aug 2000, Soren Schmidt wrote: > > > > > It seems Parag Patel wrote: > > > > On Fri, 18 Aug 2000 15:57:48 EDT, Robert Sexton wrote: > > > > > > > > > >Can IDE drives release the bus during seeks? Historically thats be= > en > > > > >the big advantage of SCSI: Two IDE drives are no faster than one ID= > E > > > > >drive, while SCSI scales in performance. > > > > > > > > How about a single IDE (master) drive per controller, that is, no sl= > ave > > > > drives at all? This would halve the number of available drives per = > card > > > > (or require twice the number of cards) but essentially would use the= > PCI > > > > bus as a multiplex bus between drives instead of SCSI. > > > > > > > > You're still pretty much stuck waiting for one command to finish bef= > ore > > > > another can be sent to a drive though, unlike SCSI drives. Still a = > lot > > > > cheaper tho'. > > > > > > Not really, if the ATA drives are configured as single masters, they c= > an > > > run simultaniously, but you will still have the PCI bus speed limit :) > > > Which BTW is around 120MB/s as some overhead goes to keep the system > > > running (yes I have measured that :) ) > > > > > > And if you have modern ATA disks, they support tagged queuing as well, > > > have had that running in my lab too... > > > > Yes. I've seen tag depths of 32. Still not as much as SCSI, but 32 will > > saturate most spindles still (I've been having to work on some non-FBSD = > ATA > > and S.M.A.R.T. stuff lately....) > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > ------------------------------ > > > > Date: Fri, 18 Aug 2000 17:52:28 -0400 > > From: "Louis A. Mamakos" <louie@TransSys.COM> > > Subject: Re: 64bit Ethernet Controllers > > > > > Have any 64bit PCI ethernet controllers been tested in 4.x yet? Prefer= > ably > > > quad port..I've seen a few around (adaptec has one) but no mention on = > the > > > list of specific experience. > > > > This may not be exactly what you meant, but the Alteon Gigabit ethernet > > controllers (the ti device) are 64 bit PCI cards. The ones I'm using ha= > ve > > optical connections, but they do have a twisted pair version with suppor= > t > > for a 10/100-Base-T phy in addition to the gigabit phy. > > > > louie > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > ------------------------------ > > > > Date: Fri, 18 Aug 2000 18:13:20 -0400 > > From: "Patrick Bihan-Faou" <patrick@mindstep.com> > > Subject: Re: Bootable CD... > > > > Hi, > > > > > > Now I am trying to use the boot.flp image that comes with the 4.1-Releas= > e > > CD. > > My alteration on that boot.flp is to replace the kernel.gz with my own (= > it > > contains a different set of binaries in the mfsroot. > > > > Now when my CD boots, the PC just goes into an endless reboot cycle. If = > I > > stop the boot process when "loader" is loaded and try to load my kernel > > manually (load kernel.gz) the loader answers with a "don't know how to l= > oad > > module /kernel.gz" error. > > > > If I do a lsmod, there is nothing loaded. > > > > I am getting really confused and frustrated... Good thing that I have a > > rewritable CD available :) > > > > > > > > Also on a side note, I think that it would be a great feature to have > > "mount_cd9660" as part of the binaries compiled in the fixit and/or inst= > all > > floppies. At least this way I could mount my CD after booting from a > > floppy... ohwell... > > > > > > > > Patrick. > > > > > > "Johan Kruger" <jkruger@oskar.dev.nanoteq.co.za> wrote in message > > news:XFMail.000818184610.jkruger@oskar.dev.nanoteq.co.za... > > > Ok, here's what i did ( busy building a custom CD installation ) > > > After the 'make release' , i took the boot.flp image 2.88 Meg and > > > mounted it. I deleted everything except for /boot/boot0-2 an the > > > bootforth loader. Then i made my own kernel allowing a MFS of 2048 x 5= > 12 > > > blocks, giving me 1.44 Meg in the filesystem. > > > In this i crunched 72 Megs of binary's , one of them 'chroot' > > > I compiled init as not to look for 'rc' ( check the Makefile, define p= > art > > > that's specifically for a release ) > > > After this i use the write_mfs_in_kernel script and umount it ( rememb= > er > > to > > > compress the kernel after the mfs write > > > > > > sh -e doFS.sh -s mfsroot ./ /mnt 2880 johan's_mfsfd_root_dir/ 8000 > > minimum2 > > > ./write_mfs_in_kernel kernel mfsroot > > > gzip -9vc kernel > kernel.gz > > > vnconfig /dev/vn0 boot.flp > > > mount /dev/vn0 /mnt > > > rm /mnt/kernel.gz > > > cp kernel.gz /mnt/kernel.gz > > > umount /mnt > > > vnconfig -u /dev/vn0 > > > > > > Now your boot.flp is ready for mkisofs > > > > > > Basically what happens now , i copy my complete live filesystem with > > > installed apps to the CD's root dir, and when i do mkisofs, i use my n= > ew > > > bootimage. After boot , since it can not find rc, it executes .profile= > in > > > the MFS filesystem in the kernel- BUT ONLY if you compiled init for th= > e > > > crunch with in /usr/src/sbin/init/Makefile > > > > > > #CFLAGS+=3D-DDEBUGSHELL -DSECURE -DLOGIN_CAP -DCOMPAT_SYSV_INIT > > > CFLAGS+=3D-DSECURE -DLOGIN_CAP -DCOMPAT_SYSV_INIT > > > > > > > > > In .profile i put 'mount_cd9660 /dev/acd0a /cdrom' ( /cdrom an extra d= > ir i > > put > > > in my filesystem ) and 'chroot /cdrom /setup' , where setup is my prog= > , > > and > > > this works perfectly , i even load my own modules before the chroot an= > d so > > on. > > > > > > The release i built is 5.0-CURRRENT , and if you want the boot.flp i c= > an > > > attach it for you. Just mail me. Right now i'm going home - it's Frida= > y - > > at > > > last > > > GOOD LUCK > > > *;-) > > > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > ------------------------------ > > > > Date: Sat, 19 Aug 2000 19:00:26 +0900 > > From: Katsushi Kobayashi <ikob@koganei.wide.ad.jp> > > Subject: IEEE1394 driver system for -current > > > > Hello, > > > > I announced IEEE1394 device driver on FREENIX'99 (sorry not > > on '00). I have caught up -current version at this time. > > > > The latest -current driver patch can be found at: > > > > ftp://ftp.uec.ac.jp/pub/firewire/beta/ > > > > I hope you success to make a kernel on your source tree. > > > > The driver function is still limited and may include many > > bugs since the driver has been used for specific purrposes, > > e.g., the driver have not supported SCSI (CAM) storage on > > IEEE1394 and not been complient to loadable kernel module. > > However, I think it is better to merge -current on this time and > > maintain on it compared with taking a effort in independent. > > > > Let me know what shall I do to merge my code. > > > > - -- > > > > ikob@koganei= > .wide.ad.jp > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > ------------------------------ > > > > End of freebsd-hackers-digest V4 #925 > > ************************************* > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Mon, 21 Aug 2000 19:04:34 -0400 (EDT) > From: Robert Watson <rwatson@freebsd.org> > Subject: Re: quotas and file creditentials > > On Thu, 10 Aug 2000, Damian Kuczynski wrote: > > > When I tried to analizee problem with mail.local writing messages to > > user mailmox over quota limit I saw, that once root open a file which > > belongs to nonprivileged user ex. test1, and after that drops his > > privlegees to this user then user test1 is able to write to this file as > > many data an he want and qverquota his disk limits mail.local works in > > this maneer so it is able to overquota user mailbox. > > > > Is this normal, or maybe file should be writen under permissions > > effective user (euid=test1) > > Damian, > > Cached credentials for file descriptor (socket, file) access are a fairly > widely used phenomena under UNIX, and probably not something that should > be used; the defined semantics indicate that access checks can occur only > on open(), not necessarily on individual read()/write() calls. However, > what you could do is move the open() in mail.local to after the revocation > of privilege, although you'd want to create the mailbox first with > privilege if it doesn't already exist. This would probably give the > correct semantics from the perspective of quotas. At one point patches to > do this were floating around -- from your message, I think it's safe to > assume that they were not committed. Might be worth checking the archives > of -hackers and -isp. > > Robert N M Watson > > robert@fledge.watson.org http://www.watson.org/~robert/ > PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 > TIS Labs at Network Associates, Safeport Network Services > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Tue, 22 Aug 2000 08:12:39 +0900 > From: Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp> > Subject: Re: [PATCH] 3-button microsoft-type serial mouse > > >Hi! > > > >I have a 3-button microsoft-type serial mouse (I do not know the vendor, > >only FCC ID if needed) which generates the `middle button down' event as > >previous `button down/up' event (any). Attached are: > > I have heard about this tipe of mouse. It's one of old serial mice, > isn't it? > > >1. the script(1) output of unmodified moused(8) with comments on events. > >2. the patch that makes my mouse's 3rd button work. > > Thank you for the patch. > > However, this modification should best be implemented as an option (or > a special kludge for this mouse). > > It is perfectly valid the same data packet is sent from the mouse > twice (or three time or more), and there may be some 3-button mice > which stop working if this kludge is invoked for all mice as a > standard feature. > > Kazu > > >Cheers, > >-- > >Ruslan Ermilov Oracle Developer/DBA, > >ru@sunbay.com Sunbay Software AG, > >ru@FreeBSD.org FreeBSD committer, > >+380.652.512.251 Simferopol, Ukraine > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Mon, 21 Aug 2000 19:15:57 -0400 (EDT) > From: Robert Watson <rwatson@freebsd.org> > Subject: Re: quotacheck on a live filesystem; safe? (fwd) > > Due to the locking involved in ufs_quota.c's management of the quota > files, I believe it may be possible to get a deadlock when modifying the > quota from userland. I haven't thought through all the details yet, and > am not familiar with the quotacheck.c code, but there are some related > deadlock conditions in the extended attribute code as it uses backing > files in much the same way. In essence, the UFS code holds onto an extra > reference to the quota record file as part of the file system mount > structure. When it needs to commit quota updates to disk, it acquires a > vnode lock for the record file. However, this is not done using the > locking protocol -- i.e., the locking order may not be maintained. The > caller to ufs_readwrite() may already hold the lock on another file; I'm > not sure how rigorously the quota code checks for this type of situation, > but if you are getting either hangs during direct quota file modification, > or lock manager panics, that could be the source. I believe quotacheck.c > attempts to directly access the backing file, in which case such a > deadlock could arise. The quotactl interface appears to support a > call to set/get quota settings/usage, which should be used to manipulate > quotas -- never direct quota backing file access. > > I make no promise about the accuracy of my claims about the existing > quotacheck implementation, but that might be a place to start looking, and > you can certainly imagine problems coming about as a result. You might > also be able to imagine that direct user access to the quota backing files > could be used to bottleneck or entirely block write access to the file > system, due to locking requirements. In the extended attribute > implementation, I generally recommend that backing files be stored in a > directory inaccessible to non-administrative users, as the ability to hold > vnode locks for the file (i.e., long vop_read/write calls) could impact > performance substantially, or allow a deadlock to arise/be engineered. > > Robert Watson > > On Thu, 10 Aug 2000, David Kirchner wrote: > > > I've searched the archives and I've seen this question asked a few other > > times, but I did not see any response. Does anyone know the answer? > > > > ---------- Forwarded message ---------- > > Date: Wed, 9 Aug 2000 14:15:17 -0700 (PDT) > > From: David Kirchner <dpk@dpk.net> > > To: freebsd-questions@FreeBSD.ORG > > Subject: quotacheck on a live filesystem; safe? > > > > > > Hi, > > > > I've been reading over source for quotacheck and ufs_quota.c and so far I > > have not found a reason why running quotacheck on a live filesystem would > > cause anything but inconsistencies in the quota.user file. Is this an > > incorrect belief? > > > > >From what I understand: > > > > the quota.user file is used as a storage for quota information between > > boots and by the various userland quota reporting utilities. The kernel > > maintains an idea of the quota in memory, and commits it to disk when > > necessary. > > > > If this is correct, then I could expect, at worst, someone's quota to be > > invalid if the machine crashes while quotacheck is running and their files > > are being modified? > > > > Thanks, > > David Kirchner <dpk@dpk.net> > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-questions" in the body of the message > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > > Robert N M Watson > > robert@fledge.watson.org http://www.watson.org/~robert/ > PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 > TIS Labs at Network Associates, Safeport Network Services > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Mon, 21 Aug 2000 21:01:13 -0400 (EDT) > From: Robert Watson <rwatson@freebsd.org> > Subject: Re: freebsd and non-preemtive threads > > Both Coda and Arla make use of an LWP implementation originating at CMU. > I believe that the implementation can make use of timers to add > preemption, but know that in Coda preemption is not supported: LWPs are > used to represent in-process (potentially blocking) RPCs on both the > client and server, and are quite light weight, meaning low context-switch > overhead with minimal kernel involvement. As a result, AFS and Coda > servers tend to run with hundreds, if not thousands of threads: a feat not > possible in many 1:1 userland thread/kernel mappings (Linux kernel > threads, for example), and often not all that scalable in m:n models. > However, as with other library-based thread mechanisms, you have to be > careful to direct potentially blocking calls through the thread-aware > versions of the calls so as not to block all other threads. As the LWP > code used in AFS/Coda/Arla uses select() for blocking/timeout management, > there are some scalability issues with lots of blocked threads--these > might be improved through use of poll() or kqueue(). > > For reference, my recollection is that peemption-aware userland thread > libraries tend to make alot of timer syscalls, losing some of the > advantage of being a userland thread library (low context switch cost, few > transistions between user/kerneland). The AFS LWP code included a > fasttime() mechanism that took advantage of the ability to mmap kernel > memory under SunOS, allowing direct access to the timer variable in > kernel, without a context switch. I do not believe that native ports to > Linux/FreeBSD/et al have retained this capability, especially given its > requirements for privilege. However, it would be easy to imagine a kernel > module exporting a /dev/time, which had the singular ability of allowing > the mmaping of a page containing only the kernel's timer variables, > permitting syscall-free precise time access from userland using atomic > memory access calls. > > Robert N M Watson > > robert@fledge.watson.org http://www.watson.org/~robert/ > PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 > TIS Labs at Network Associates, Safeport Network Services > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Mon, 21 Aug 2000 18:13:16 -0700 > From: Alfred Perlstein <bright@wintelcom.net> > Subject: Re: freebsd and non-preemtive threads > > * Robert Watson <rwatson@FreeBSD.ORG> [000821 18:01] wrote: > > > > For reference, my recollection is that peemption-aware userland thread > > libraries tend to make alot of timer syscalls, losing some of the > > advantage of being a userland thread library (low context switch cost, few > > transistions between user/kerneland). The AFS LWP code included a > > fasttime() mechanism that took advantage of the ability to mmap kernel > > memory under SunOS, allowing direct access to the timer variable in > > kernel, without a context switch. I do not believe that native ports to > > Linux/FreeBSD/et al have retained this capability, especially given its > > requirements for privilege. However, it would be easy to imagine a kernel > > module exporting a /dev/time, which had the singular ability of allowing > > the mmaping of a page containing only the kernel's timer variables, > > permitting syscall-free precise time access from userland using atomic > > memory access calls. > > I think phk and I discussed this about a year ago, our idea was to > automatically map the segment in for each process (also allowing > things like getpid and such to be accessable). > > It would be nice to see happen either way (mmap'able /dev/time or > automatically) > > - -- > - -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > "I have the heart of a child; I keep it in a jar on my desk." > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Tue, 22 Aug 2000 17:08:55 +0530 > From: Pran Joseph <pran@procsys.com> > Subject: Memory Mapping > > Hi, > > I am trying to write a PCI ethernet driver for FreeBSD 3.4 release . I > am new to the driver stuff. > > I want to allocate some memory for device buffer using malloc > function. I also want the physical address of allocated memory block > so that I can initialize the device registers. > > Can any one of you please explain me how I can convert address > returned by > malloc to Physical address. > > Thanks > - -Pran > > > > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Tue, 22 Aug 2000 04:44:21 -0700 > From: Alfred Perlstein <bright@wintelcom.net> > Subject: Re: Memory Mapping > > * Pran Joseph <pran@procsys.com> [000822 04:36] wrote: > > Hi, > > > > I am trying to write a PCI ethernet driver for FreeBSD 3.4 release . I > > am new to the driver stuff. > > > > I want to allocate some memory for device buffer using malloc > > function. I also want the physical address of allocated memory block > > so that I can initialize the device registers. > > > > Can any one of you please explain me how I can convert address > > returned by > > malloc to Physical address. > > VTOPHYS or vtophys. > > - -Alfred > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Tue, 22 Aug 2000 06:29:34 -0700 (PDT) > From: bliss-s@excite.com > Subject: Advanced OS Questions only you can answer... > > I am stuck between a rock and a hard place. I've been to your website, I've > logged in under deja.news and posted questions, I've emailed several people, > and my Dad even called the BSD 800 number for me and paid a fee to find out > that all my questions are too advanced for their services. The > representative at the 800 number told my Dad that my only hope was to send > this email to you. > > I am researching OS's and chose FreeBSD because it was open source. I know > nothing about OS's. I thought open source would mean that I could review > the documentation and find all my answers. However, open source means > nothing to me because I reviewed the documentation, and it doesn't help me > out because I know no terms good enough to understand the documentation. > I've been doing this now for 4 weeks...what is sad is that I need answers to > these questions in 2 weeks. I have a highschool paper that is due in 3 > weeks, and the teacher is unable to help me out...my Dad doesn't have the > knowledge...so, as you can tell by now, I suck at getting this paper > completed in time. > > I am very green on this, so please keep this in mind if you are able to > answer the questions below. I understand that there might be a fee for > this....if so, please let me know. > > Again, you are my only hope. I thank you VERY much > > With most SINCERE thanks! > David Igo > ========================================= > 1. How does this OS manage process scheduling, interprocess communication, > process synchronization, and of handling deadlocks. > > 2. How does the OS manage main memory and does it manage secondary storage > to back up main memory. I need on algorithm and one structure to show this > management...along with how they relate to the management. > > 3. I need the key characteristics of the OS supporting file structures and > access methods in regards to types of access methods, directory structures, > data protection, and file consistency. > > 4. How does the OS control peripheral devices and the input/output need for > applications regarding input/output design, interfaces, internal system > structures. > > 5. how does the OS provide for a collection of processors including: > a. processors that do not share a memory > b. processor that do not share a clock > c. storage devices dispersed among various sites > d. distributed file system > e. process synchoronization > f. process communication > g. failures recovery > > 6. And finally, how does the OS ensure the protection and security of > files, memory, segments, and CPU for data and code in the following > situations: > a. Unauthorized access > b. mailicious destruction, > c. alteration > d. accidental introduction of inconsistency > > I CAN'T THANK YOU ENOUGH FOR TAKING THE TIME TO HELP ME OUT. > > > > > > _______________________________________________________ > Say Bye to Slow Internet! > http://www.home.com/xinbox/signup.html > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Tue, 22 Aug 2000 14:10:37 +0000 > From: Alan Clegg <abc@firehouse.net> > Subject: Re: Advanced OS Questions only you can answer... > > Out of the ether, bliss-s@excite.com spewed forth the following bitstream: > > I am stuck between a rock and a hard place. I've been to your website, I've > > logged in under deja.news and posted questions, I've emailed several people, > > and my Dad even called the BSD 800 number for me and paid a fee to find out > > that all my questions are too advanced for their services. The > > representative at the 800 number told my Dad that my only hope was to send > > this email to you. > > My guess is that the answer was more along the lines of "Can't your son > do his own homework/research?" > > AlanC > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Tue, 22 Aug 2000 17:19:13 +0300 > From: Peter Pentchev <roam@orbitel.bg> > Subject: Re: Advanced OS Questions only you can answer... > > The short answer: none of your questions has a short answer. > > A recommendation: get Kirk McKusick's "Design and Implementation of 4.4BSD", > it has a lot of the information you need, and a quick skim through the > relevant chapters should be enough to give you an idea of the answers > you need. I think that for most people, the ability to really answer even > half of your questions would come after several university-level courses > in computer science and OS design, and/or after several years' worth > of work in the field. > > (alright, so there may be exceptions.. if you happen to be one of them, > or if you've had those several years of programming experience, then > McKusick's book should give you the answers you need :) > > G'luck, > Peter > > - -- > The rest of this sentence is written in Thailand, on > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Tue, 22 Aug 2000 10:27:17 -0400 (EDT) > From: "Chris D. Faulhaber" <jedgar@fxp.org> > Subject: Re: Advanced OS Questions only you can answer... > > On Tue, 22 Aug 2000 bliss-s@excite.com wrote: > > *snip* > > > > I am researching OS's and chose FreeBSD because it was open source. I know > > nothing about OS's. I thought open source would mean that I could review > > the documentation and find all my answers. However, open source means > > nothing to me because I reviewed the documentation, and it doesn't help me > > out because I know no terms good enough to understand the documentation. > > I've been doing this now for 4 weeks...what is sad is that I need answers to > > these questions in 2 weeks. I have a highschool paper that is due in 3 > > weeks, and the teacher is unable to help me out...my Dad doesn't have the > > knowledge...so, as you can tell by now, I suck at getting this paper > > completed in time. > > > > If you know nothing about OS's, perhaps you should start with an easier > topic than BSD internals. > > Also, Open Source means that the source is available, not that everything > you have questions on is documented. And since FreeBSD is done almost > completely by volunteers, what information you do find has been > contributed by those with the time and interest, not because they get > paid for it. However, you are welcome to contribute your answers back to > the project for future reference. > > Many of your questions can be answered by reading a copy of Design and > Implementation of 4.4BSD, available at most fine bookstores. In addition, > you are welcome to UTSL (Use The Source, Luke). > > - ----- > Chris D. Faulhaber - jedgar@fxp.org - jedgar@FreeBSD.org > - -------------------------------------------------------- > FreeBSD: The Power To Serve - http://www.FreeBSD.org > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Tue, 22 Aug 2000 16:34:49 +0200 (SAST) > From: Lists Account <lists@security.za.net> > Subject: IBM ServerRaid > > Hi All, > > does anyone know if there are any IBM Server raid drivers for FreeBSD out > there? If So can anyone tell me where I can get one > > Thanks > > Andrew > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Tue, 22 Aug 2000 11:41:36 -0400 > From: Jon Parise <jon@csh.rit.edu> > Subject: Re: Advanced OS Questions only you can answer... > > On Tue, Aug 22, 2000 at 06:29:34AM -0700, bliss-s@excite.com wrote: > > > I am very green on this, so please keep this in mind if you are able to > > answer the questions below. I understand that there might be a fee for > > this....if so, please let me know. > > Looks like you bit off a lot more than you could chew. =) > > Have a look here for some seminar information on 4.4BSD internals: > > http://www.csh.rit.edu/seminars/os/19962/week4/ > > - -- > Jon Parise (jon@csh.rit.edu) . Rochester Inst. of Technology > http://www.csh.rit.edu/~jon/ : Computer Science House Member > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > Date: Tue, 22 Aug 2000 12:44:14 -0400 (EDT) > From: Zhihui Zhang <zzhang@cs.binghamton.edu> > Subject: kernel debugging on 4.1-release > > I try to trace some system call using remote debugging and find something > that I can not explain myself (the related source is ffs_write()): > > case 1: > - ------- > > 443 if (object) > (gdb) break 430 > Breakpoint 6 at 0xc0289cea: file ../../ufs/ufs/ufs_readwrite.c, line 430. > (gdb) c > Continuing. > > Breakpoint 6, ffs_write (ap=0xc64f5e70) at > ../../ufs/ufs/ufs_readwrite.c:438 > 438 p = uio->uio_procp; > > In the above case, even if I set breakpoint 6 at line 430, it insists on > line 438. > > case 2: > - ------- > > (gdb) print p->p_limit > $1 = (struct plimit *) 0xffffffff > > In the above case, the statement has just used p->p_limit to do some > comparison and yet gdb says its value is -1. The statement using it is: > > if (vp->v_type == VREG && p && > uio->uio_offset + uio->uio_resid > > p->p_rlimit[RLIMIT_FSIZE].rlim_cur) { > > Are these bugs of gdb or am I doing something wrong? I notice that > 4.1-release install KLD files at the same time you install kernel. In the > past, I only copy the file kernel.debug to the target machine. Do I have > to copy those .ko files to the target machine as well? > > Any help is appreciated. > > - -Zhihui > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > > End of freebsd-hackers-digest V4 #927 > ************************************* > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39A84A4C.20198.175588>