Re: {a}sync updates (was Re: make install trick)
On Thu, Oct 07, 1999 at 11:57:26AM +1000, a little birdie told me that Peter Jeremy remarked > > How detailed should the man page be? Exactly my query in writing this ;> > If it stated "all file data will > be written synchronously, but inodes where the only update is atime > and free block bitmaps are written asynchronously", would that be any > clearer to a user who didn't have a detailed understanding of UFS? > If you would like it to say something different, write some patches > and send them in as a PR (keeping in mind phk's recent e-mail about > green bikesheds). I'm still stewing on what should be with it; what we have works fine, if being slightly inconsistent in an obscure way. I'm trolling for ideas on whether well enough should be left alone (since there's obviously an incredibly small percentage of people USING sync as a mountop), or whether a footnote should be added somewhere (I lean toward mount(2) instead of mount(8) myself, with a possible xref in mount(8)). I'll see what I think of, and possibly have some diffs tomorrow. > There should be fairly few writes to the root partition, so having > these writes synchronous is not a big performance hit. On the other > hand, there are probably a _lot_ of read accesses to devices in /dev > and files in /bin (how many of your scripts begin #!/bin/sh?). Unless > you specify NOATIME, each of these read accesses implies an atime > update within the inode. Making these synchronous probably would > be a big performance hit. This is why I haven't screamed for them to be sync-tified... -- Matthew Fuller (MF4839) |[EMAIL PROTECTED] Unix Systems Administrator |[EMAIL PROTECTED] Specializing in FreeBSD |http://www.over-yonder.net/ FutureSouth Communications |ISPHelp ISP Consulting "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: modules: how to use?
On 07-Oct-99 Greg Lehey wrote: > Well, the standard way to load a kld is with kldload(1) or kldload(2). > I don't know if procfs works properly like this, though. Well I would assume (aha) that when mount cannot find procfs in the list of FS's the kernel knows about it would try and load it just like all the others.. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: modules: how to use?
> Well, the standard way to load a kld is with kldload(1) or kldload(2). > I don't know if procfs works properly like this, though. Procfs works just fine: [groovy] /usr/src.With_secure_NFS # kldstat Id Refs AddressSize Name 17 0xc010 1a10cc kernel.debug 21 0xc09c1000 3000 mfs.ko 31 0xc09cd000 6000 procfs.ko 41 0xc09da000 8000 if_xl.ko 51 0xc09e3000 7000 miibus.ko 61 0xc09f9000 4b000nfs.ko 71 0xc0a6a000 2000 green_saver.ko M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: modules: how to use?
On Thursday, 7 October 1999 at 3:00:52 -0300, The Hermit Hacker wrote: > > Figuring one of the things a friend of mine raves about Linux for is their > kld's, I'd start playing with ours... Yes, it's funny how the Linuxers rave about loadable modules. It's a good idea, but I don't see anything that spectacular about it. > Looking in /modules, I saw 'procfs', so, cool, a place to start...remove > "options PROCFS" from kernel config, rebuild, install and reboot ... > > crashes... How? > so, I figure that I somehow have to tell the kernel to load that module? > > checked the kld man page, and nothing in there appears to be > appropriate...and just looked at my /usr/src/etc/rc* files to see if maybe > it was something I was supposed to configure in there, but nothing appears > to be in tehre either... > > Help? Well, the standard way to load a kld is with kldload(1) or kldload(2). I don't know if procfs works properly like this, though. Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: modules: how to use?
On 07-Oct-99 The Hermit Hacker wrote: > Looking in /modules, I saw 'procfs', so, cool, a place to start...remove > "options PROCFS" from kernel config, rebuild, install and reboot ... > so, I figure that I somehow have to tell the kernel to load that module? Well its a kld.. You don't have to reboot.. Since its a VFS module mount will load it automatically anyway.. Maybe a better place to start would be linux emulation.. The 'linux' shell script basically does a kldload linux Have a look at /boot/defaults/loader.conf for stuff you can load as a module before the kernel is executed. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
modules: how to use?
Figuring one of the things a friend of mine raves about Linux for is their
kld's, I'd start playing with ours...
Looking in /modules, I saw 'procfs', so, cool, a place to start...remove
"options PROCFS" from kernel config, rebuild, install and reboot ...
crashes...
so, I figure that I somehow have to tell the kernel to load that module?
checked the kld man page, and nothing in there appears to be
appropriate...and just looked at my /usr/src/etc/rc* files to see if maybe
it was something I was supposed to configure in there, but nothing appears
to be in tehre either...
Help?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: {a}sync updates (was Re: make install trick)
On 1999-Oct-07 09:15:42 +1000, Matthew D. Fuller wrote: >Is this good, bad, ugly, or just inconsistent? On the one hand, you can >argue that 'sync should be sync should be sync, I don't bloody care, just >don't do anything async at all', since that's what it's supposed to do: >mount(8): > syncAll I/O to the file system should be done synchronously. How detailed should the man page be? If it stated "all file data will be written synchronously, but inodes where the only update is atime and free block bitmaps are written asynchronously", would that be any clearer to a user who didn't have a detailed understanding of UFS? If you would like it to say something different, write some patches and send them in as a PR (keeping in mind phk's recent e-mail about green bikesheds). > sync atime updates will slow it >down, but on the flip side, if you're mounting sync in the first place >you don't care much for speed anyway. There should be fairly few writes to the root partition, so having these writes synchronous is not a big performance hit. On the other hand, there are probably a _lot_ of read accesses to devices in /dev and files in /bin (how many of your scripts begin #!/bin/sh?). Unless you specify NOATIME, each of these read accesses implies an atime update within the inode. Making these synchronous probably would be a big performance hit. Peter -- Peter Jeremy (VK2PJ)[EMAIL PROTECTED] Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: {a}sync updates (was Re: make install trick)
:mount(8): : syncAll I/O to the file system should be done synchronously. : :On the gripping hand, you can say, 'this is an ATIME update, there's no :way its presence or lack thereof can do anything bad to the filesystem, :so let it be async since it takes extra work to make it sync'. : :Does anyone have any feeling either way on this? I, unfortunately, seem :to have strong feelings BOTH ways... sync atime updates will slow it :down, but on the flip side, if you're mounting sync in the first place :you don't care much for speed anyway. : :Thoughts? :Matthew Fuller (MF4839) |[EMAIL PROTECTED] Well, you don't gain anything by making atime updates sync, and you lose a lot, so why do it? If you are worried about protecting the root drive from a crash, mount it read-only (and put /dev on an MFS mount) or mount it noatime. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make install trick
> /dev/da0s1a on / (local, synchronous, writes: sync 32 async 15100) > ^^^ > > Though I'm still waiting for an explanation of WHY exactly I have async > writes on a sync partition. Nobody yet has said anything but 'that's > interesting...'. A direction to look would be helpful. The sync flag only affects data writes and block allocation for data writes. Metadata is normally always written synchronously, except for safe optimisations. Safe optimisations include never writing inode or block bitmaps (fsck can recover these), not writing some indirect blocks (correct block numbers are not very useful until the blocks have been written), and not writing inodes in many cases where only timestamps have changed. You seem to have a lot of async writes. This may be caused by using soft updates. Soft updates causes many (or most or all) metadata updates to be done using delayed writes. Using the sync flag with soft updates doesn't make much sense and may be harmfull (there doesn't seem to be anything to prevent data writes being done long before the metadata points to the data). Smaller number of async writes may be caused by metadata write optimisations. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
{a}sync updates (was Re: make install trick)
Thank you, this is *EXACTLY* what I was looking for :) On Thu, Oct 07, 1999 at 08:59:00AM +1000, a little birdie told me that Peter Jeremy remarked > > As far as I can tell, the net effect is that inode access time updates > will remain async writes into the filesystem. > > An easy way to tell would be to use NOATIME and see if you're still > getting async writes. (Or any writes at all). This does appear to be it. Testing such things as (cat /kernel >> /dev/null && sync && sync) preceded and followed by a 'mount' call in another window does show the 'async' counter incrementing, and when I remount it noatime it no longer does. Is this good, bad, ugly, or just inconsistent? On the one hand, you can argue that 'sync should be sync should be sync, I don't bloody care, just don't do anything async at all', since that's what it's supposed to do: mount(8): syncAll I/O to the file system should be done synchronously. On the gripping hand, you can say, 'this is an ATIME update, there's no way its presence or lack thereof can do anything bad to the filesystem, so let it be async since it takes extra work to make it sync'. Does anyone have any feeling either way on this? I, unfortunately, seem to have strong feelings BOTH ways... sync atime updates will slow it down, but on the flip side, if you're mounting sync in the first place you don't care much for speed anyway. Thoughts? -- Matthew Fuller (MF4839) |[EMAIL PROTECTED] Unix Systems Administrator |[EMAIL PROTECTED] Specializing in FreeBSD |http://www.over-yonder.net/ FutureSouth Communications |ISPHelp ISP Consulting "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ahc panics and (da2:ahc2:0:2:0): data overrun detected in Data-Out phase. Tag == 0x25.
I'm getting this with a recent current (6. october): (da2:ahc2:0:2:0): data overrun detected in Data-Out phase. Tag == 0x25. (da2:ahc2:0:2:0): Have seen Data Phase. Length = 0. NumSGs = 1. (da2:ahc2:0:2:0): data overrun detected in Data-Out phase. Tag == 0x25. (da2:ahc2:0:2:0): Have seen Data Phase. Length = 0. NumSGs = 1. (da2:ahc2:0:2:0): data overrun detected in Data-Out phase. Tag == 0x25. (da2:ahc2:0:2:0): Have seen Data Phase. Length = 0. NumSGs = 1. Fatal trap 12: page fault while in kernel mode fault virtual address = 0xbfc0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc020fa16 stack pointer = 0x10:0xc02600bc frame pointer = 0x10:0xc02601f4 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = kernel: type 12 trap, code=0 Stopped at bus_dmamap_load+0x1ce: movlPTmap(,%eax,4),%edx (kgdb) bt #0 bus_dmamap_load (dmat=0xc0834340, map=0xc0293980, buf=0x0, buflen=0x0, callback=0xc013729c , callback_arg=0xc083a4a0, flags=0x0) at machine/pmap.h:172 #1 0xc013779f in ahc_setup_data (ahc=0xc0830600, csio=0xc09c6000, scb=0xc083a4a0) at ../../dev/aic7xxx/aic7xxx.c:5037 #2 0xc0136c15 in ahc_action (sim=0xc08341c0, ccb=0xc09c6000) at ../../dev/aic7xxx/aic7xxx.c:4530 #3 0xc011deef in xpt_run_dev_sendq (bus=0xc0834180) at ../../cam/cam_xpt.c:3685 #4 0xc011ea30 in xpt_release_devq_device (dev=0xc0878200, count=0x1, run_queue=0x1) at ../../cam/cam_xpt.c:4393 #5 0xc011e958 in xpt_release_devq (path=0xc08abcd0, count=0x1, run_queue=0x1) at ../../cam/cam_xpt.c:4346 #6 0xc011d9a4 in xpt_action (start_ccb=0xc02603e8) at ../../cam/cam_xpt.c:3275 #7 0xc0121aba in cam_release_devq (path=0xc08abcd0, relsim_flags=0x0, openings=0x0, timeout=0xc013729c, getcount_only=0x0) at ../../cam/cam_periph.c:864 #8 0xc01221c9 in cam_periph_error (ccb=0xc09c6000, camflags=CAM_FLAG_NONE, sense_flags=0x11, save_ccb=0xc0889e04) at ../../cam/cam_periph.c:1646 #9 0xc0124a9f in daerror (ccb=0xc09c6000, cam_flags=0x0, sense_flags=0x10) at ../../cam/scsi/scsi_da.c:1376 #10 0xc012463f in dadone (periph=0xc0882880, done_ccb=0xc09c6000) at ../../cam/scsi/scsi_da.c:1146 #11 0xc0120703 in camisr (queue=0xc027c094) at ../../cam/cam_xpt.c:6217 #12 0xc0120515 in swi_cambio () at ../../cam/cam_xpt.c:6124 #13 0xc02128e0 in splz_swi () I can reproduce this situation. It happened using vinum on a single Raid5 plex volume with 3 disks. Softupdates is enabled. I trigger this when copying the cvs-tree on it or removing it. The first time I saw this was with a world from 30th september. Remembering the last messages on the list I updated the kernel and the vinum.ko just to see the same thing happen. This time there were the data overrun messages on the console as shown, but sometimes it simply panics looking the same without any console output beside the panic itself. I don't know the timegap between the consoleoutput and the panic. I can't write a crash dump and produced this output using a live gdb-session so a quick response if further online informations are needed would be nice. Beside: is there any way to get a dump over the seriel-line? -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make install trick
On Wed, 6 Oct 1999, Matthew D. Fuller wrote: > Indeed. > Thus: > /dev/da0s1a on / (local, synchronous, writes: sync 32 async 15100) > ^^^ > > Though I'm still waiting for an explanation of WHY exactly I have async > writes on a sync partition. Nobody yet has said anything but 'that's > interesting...'. A direction to look would be helpful. I believe "synchronous" refers only to metadata writes. So it would follow that the async writes are non-metadata writes. -- Ben Rosengart UNIX Systems Engineer, Skunk Group StarMedia Network, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make install trick
On 1999-Oct-07 06:44:19 +1000, Matthew D. Fuller wrote: >/dev/da0s1a on / (local, synchronous, writes: sync 32 async 15100) > ^^^ > >Though I'm still waiting for an explanation of WHY exactly I have async >writes on a sync partition. Nobody yet has said anything but 'that's >interesting...'. A direction to look would be helpful. You get a synchronous mount by passing MNT_SYNCHRONOUS to mount(2). Within the kernel, MNT_SYNCHRONOUS is used (basically only) within kern/vfs_vnops.c:vn_write(). There it adds IO_SYNC to the write request (the same as if the file has O_FSYNC enabled). IO_SYNC will be ignored if MNT_ASYNC is specified (which it isn't here). The write request goes through ufs/ufs/ufs_readwrite.c:WRITE(), which passes it to bwrite() if it's IO_SYNC. Inode access time updates (controlled by MNT_NOATIME, which becomes ~IN_ACCESS, which becomes IN_MODIFIED) don't go through vn_write() and wind up in bdwrite(). As far as I can tell, the net effect is that inode access time updates will remain async writes into the filesystem. An easy way to tell would be to use NOATIME and see if you're still getting async writes. (Or any writes at all). Peter -- Peter Jeremy (VK2PJ)[EMAIL PROTECTED] Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pfft Re: make install trick
On 1999-Oct-07 01:51:52 +1000, Alfred Perlstein wrote: >First post: > hey, anyone having crashes when doing installworld might like > my INSTALL="sync && install -C" trick I haven't kept that post. My recollection is that the problem was installworld dying, not the system crashing. If I misread or mis-remember the post, my apologies. >no matter which option you choose you can still get bitten by >softupdates when you do run out of space even by a trusted >user such as root. Softupdates reporting ENOSPC soon after a delete is a known bug. At this stage the recommended workaround (according to Kirk) is not to run softupdates on filesystems where this condition is likely. If anyone wants to fix it, patches would be welcomed by Kirk or Julian. If softupdates is causing panics, that is an extremely undesirable bug. I haven't been bitten (yet) and don't have a solution. My view is that the remainder of the thread has been discussing the relative merits of different ways to avoid the problem. Peter -- Peter Jeremy (VK2PJ)[EMAIL PROTECTED] Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make install trick
On 1999-Oct-06 16:14:19 +1000, Brian Somers wrote: >> On 1999-Oct-06 09:55:26 +1000, Alfred Perlstein wrote: >> >I've seen softupdates nearly eliminate disk io for systems that used >> >an abmornal amount of temp files, but the fact that it can destabilize >> >a system worries me greatly. >> >> What do you mean by `destabilize'? There are bugs in softupdates >> which mean that an application may receive ENOSPC when writing to a >> filesystem even though space on that filesystem has been recently >> freed. Any application that cannot handle this situation is _broken_. >[.] > >:-] You're joking right ? Most applications don't even *notice* >the situation let alone handle it. I wasn't really joking. Applications _should_ handle this situation. Most coding standards tell you to check for error conditions. Most programmers (including myself most of the time) just don't bother. (One reason being that C suffers from extreme code bloat and substantial loss of readability. C++ exceptions are a definite improvement here). > Whaddaya do when /var/log runs >out of space ? Show me an app that handles it. The only app that normally writes in /var/log is syslogd. And the behaviour you want in this case depends on the sysadmin's level of paranoia (anything from `ignore it' to `halt the system'). >I guess you can argue the case, but in real life, running out of any >machine resource can cause all sorts of possibly unrecoverable >problems. Agreed. One reason I (and presumably others) don't bother to check for some errors is that it's not clear what you can or should do if you get the error. > IMHO the best way to deal with it in a generic way is to >have the give-me-the-resource function block if it really thinks it's >a temporary thing. How do you work out whether the resource shortage is temporary or not? This situation is orthogonal to the ever-popular `out of swapspace' issue (normally brought up in conjunction with swap overcommit). The difficulty with any recovery strategy is avoiding deadlocks. (I suspect that a major reason why root is not constrained by UFS MINFREE was to try and avoid the situation where the _system_ (as against the users) ran out of disk space). >In the case of softupdtes, I'd be surprised if it couldn't easily >figure out that the problem is *probably* transient and block, To quote an excerpt from the response I got from Kirk when I asked him about this problem: : I experimented with keeping a count of space that was pending :removal. If the filesystem was about to return a space full message, :it would check the pending count for the filesystem and if there was :space that was going to show up in the future, it would request that :the space freeing be expedited then go to sleep and wait for it. The :problem is that the space freeing can take up to a minute (typically :more like 30 seconds) during which time the file's inode is :locked. If the locked file is say a log file, then you can get a :temporary lock race to the root which make for really terrible :perceived performance. If the inode is unlocked during the wait, then :file inconsistencies can sneak in. So, the short answer is that you :should not run soft updates on filesystems where you are running with :less than a 60 second reserve of free space. Note the last sentence... Peter -- Peter Jeremy (VK2PJ)[EMAIL PROTECTED] Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make install trick
:Indeed. :Thus: :/dev/da0s1a on / (local, synchronous, writes: sync 32 async 15100) : ^^^ : :Though I'm still waiting for an explanation of WHY exactly I have async :writes on a sync partition. Nobody yet has said anything but 'that's :interesting...'. A direction to look would be helpful. :... :Matthew Fuller (MF4839) |[EMAIL PROTECTED] : Access time updates perhaps? Try mounting with the 'noatime' option. Also, note that softupdates is *safer* then a synchronous mount in regards to ensuring filesystem consistancy. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make install trick
On Wed, Oct 06, 1999 at 04:18:15PM -0500, a little birdie told me that Kevin Day remarked > > > > /dev/da0s1a on / (local, synchronous, writes: sync 32 async 15100) > > My understanding was that that was just a indication of writes that were > able to be done asynchronously without any risk, so they were done async. > > (sync isn't purely sync, only synchronous when it's required for integrity) I was given to understand that while the default mountop follows these conventions, explicit 'sync' meant SYNC meant SYNC meant SYNC. This is my root filesystem. It gets written to when I edit a file under /etc or do an installworld. I don't *CARE* how slow it is, I want to know that it's solid, consistent, and complete. Just 'consistent' isn't enough. No write is able to be done async without risk when I'm explicitly saying 'write everything synchronously'. -- Matthew Fuller (MF4839) |[EMAIL PROTECTED] Unix Systems Administrator |[EMAIL PROTECTED] Specializing in FreeBSD |http://www.over-yonder.net/ FutureSouth Communications |ISPHelp ISP Consulting "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make install trick
> > On Wed, Oct 06, 1999 at 02:57:23PM +1000, a little birdie told me > that Peter Jeremy remarked > > > > I guess we disagree on this. My feeling is that write activity on > > root should be minimised to minimise the risk that root will be > > inconsistent following a crash. > > Indeed. > Thus: > /dev/da0s1a on / (local, synchronous, writes: sync 32 async 15100) > ^^^ > > Though I'm still waiting for an explanation of WHY exactly I have async > writes on a sync partition. Nobody yet has said anything but 'that's > interesting...'. A direction to look would be helpful. > My understanding was that that was just a indication of writes that were able to be done asynchronously without any risk, so they were done async. (sync isn't purely sync, only synchronous when it's required for integrity) Kevin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make install trick
On Wed, Oct 06, 1999 at 02:57:23PM +1000, a little birdie told me that Peter Jeremy remarked > > I guess we disagree on this. My feeling is that write activity on > root should be minimised to minimise the risk that root will be > inconsistent following a crash. Indeed. Thus: /dev/da0s1a on / (local, synchronous, writes: sync 32 async 15100) ^^^ Though I'm still waiting for an explanation of WHY exactly I have async writes on a sync partition. Nobody yet has said anything but 'that's interesting...'. A direction to look would be helpful. -- Matthew Fuller (MF4839) |[EMAIL PROTECTED] Unix Systems Administrator |[EMAIL PROTECTED] Specializing in FreeBSD |http://www.over-yonder.net/ FutureSouth Communications |ISPHelp ISP Consulting "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New CVSup mirror sites
John Polstra wrote: > > ... > One common misconception is that cvsup(N+1).FreeBSD.org is somehow > less up-to-date than or not as good as cvsup(N).FreeBSD.org. That's > not the case at all -- the numbers mean nothing. For example, all 7 > of the US mirror sites get their updates hourly from the same master > site. (So do most of the non-US mirrors.) The only reasons to choose Most, but not all. Is it possible to list that information too. As well as an on easily found place. The link on the mainform gives http://www.nl.freebsd.org/support.html#cvs which does not list that information. A search gives over 25 documents, one of which is http://www.freebsd.org/handbook/mirrors-cvsup.html which also does not list that tidbit. I switched from the dutch mirror to an UK one because the latter was more up to date. So now there is a new dutch mirror. However, it is not clear how up to date it is. Roelof -- Het Slakke Huis op http://SlakkeHuis.com/ Home is where the (@) http://eboa.com/ is. Telekabel home http://nisser.com/ Beveiligingsverwijzingen http://nisser.com/links.htm Chello lijn monitor http://nisser.com/~roelof/logs_chello.shtml To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make install trick
At 12:22 PM +0200 1999/10/6, Brad Knowles wrote: > Is there something fundamental I'm missing here? I thought > that this sort of thing was taught in SysAdmin 101 My sincerest (and public) apologies to Alfred. There is something pretty fundamental that I was missing -- this problem is not restricted to just a softupdates filesystem filling up, and if it's the root filesystem then there can be a crash. No, this problem appears to be that if *any* softupdates filesystem fills up, it can crash the system. Now that I understand what it was I was missing, I'm much more reluctant to use softupdates in general, at least until this problem is fixed. Thanks for understanding, and helping me to more clearly understand the problem! -- These are my opinions -- not to be taken as official Skynet policy |o| Brad Knowles, <[EMAIL PROTECTED]>Belgacom Skynet NV/SA |o| |o| Systems Architect, News & FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make install trick
According to Nate Williams: > So, are you suggesting make /tmp it's own disk, otherwise anytime you do > development alot of writes are done to /. Of course /tmp should NOT be on /. Either in its separate FS or on another partition through a symlink. / should be as small and as write-free as possible. Mine is too small now for a 4.0 system (/ has grown a bit since 2.0... :)) though. > And, if you do lots of development, then you'll have the same problem on > /tmp as you did on / unless you waste a huge disk for /tmp. :( It doesn't have to be that huge and -pipe helps a lot for C/C++ :) -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 4.0-CURRENT #74: Thu Sep 9 00:20:51 CEST 1999 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
identd
Has anyone else experienced problems with identd not working? -- Phil Nature To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make install trick
< said: > Forgive me if I'm misunderstanding something here, but isn't > having /tmp on the root filesystem just inviting a denial-of-service > attack on yourself? Only if you let random lusers log in to your machine. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make install trick
At 10:51 AM -0400 on 1999/10/6, Garrett Wollman <[EMAIL PROTECTED]> wrote: > Only if you let random lusers log in to your machine. That's not the way I interpret some of the previous comments on this thread. It seems to me that not having /tmp on a separate filesystem has, indeed, created quite a nice little self-inflicted denial-of-service attack on certain people. ;-) -- These are my opinions -- not to be taken as official Skynet policy |o| Brad Knowles, <[EMAIL PROTECTED]>Belgacom Skynet NV/SA |o| |o| Systems Architect, News & FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Still ATA problems
On 06-Oct-99 Soren Schmidt wrote: > > I have a new version almost ready that should fix this problem, including > the panic on the alpha. It just a bit more testing then I'll commit it... > If you want, I can give it a test on a 164SX-based alpha... ===++=== Erik H. Bakke || To be or not to be... Senior Consultant/Developer|[EMAIL PROTECTED]|Is simply a question of Habatech AS|| binary logic ===++== To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Still ATA problems
It seems Erik H. Bakke wrote: > I am still having problems with the ATA driver. > I am seeing the same error messages as has been reported on the lists during > the last few weeks, both on i386 and alpha platforms. > On the i386, the problem is just an irritating itch, but it seems to be > far more serious on the alpha, where the system reboots instantly when the > problems occur. > On reboot, the system stops at the probing of disks, reporting a timeout. > Then, the system reboots again, probing and rebooting in an endless loop. > > I have the latest sources, as cvsupped today, October 6th. > > I can provide more information on the system configuration if needed, but I > have no access to it right now. I have a new version almost ready that should fix this problem, including the panic on the alpha. It just a bit more testing then I'll commit it... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Still ATA problems
I am still having problems with the ATA driver. I am seeing the same error messages as has been reported on the lists during the last few weeks, both on i386 and alpha platforms. On the i386, the problem is just an irritating itch, but it seems to be far more serious on the alpha, where the system reboots instantly when the problems occur. On reboot, the system stops at the probing of disks, reporting a timeout. Then, the system reboots again, probing and rebooting in an endless loop. I have the latest sources, as cvsupped today, October 6th. I can provide more information on the system configuration if needed, but I have no access to it right now. ===++=== Erik H. Bakke || To be or not to be... Senior Consultant/Developer|[EMAIL PROTECTED]|Is simply a question of Habatech AS|| binary logic ===++== To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make install trick
At 6:33 PM -0700 1999/10/5, Alfred Perlstein wrote: > Which isn't an option unless you dedicate a partition for /tmp > which is pretty wasteful imo. Forgive me if I'm misunderstanding something here, but isn't having /tmp on the root filesystem just inviting a denial-of-service attack on yourself? It's bad enough when programs crap out when /tmp is full and they can't create the temporary files they demand (vi leaps to mind), but when you fill up the root filesystem and the whole machine falls over, that seems to be a really bad situation that everyone would want to avoid at virtually all costs. It was my understanding that it was standard recommended practice practice pretty much across the board to create the following separate filesystems: / /tmp (perhaps an mfs, perhaps softupdates, or whatever) /usr /var /var/tmp /home (or wherever you're going to store user directories) And that most people also then created a separate filesystem for /usr/local or /opt, or wherever they're going to store the additional system programs that they're going to be adding. This also allows you to do nice security things such as mounting /tmp, /var, /var/tmp nosuid, etc Is there something fundamental I'm missing here? I thought that this sort of thing was taught in SysAdmin 101 -- These are my opinions -- not to be taken as official Skynet policy |o| Brad Knowles, <[EMAIL PROTECTED]>Belgacom Skynet NV/SA |o| |o| Systems Architect, News & FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent kernel hangs during boot with pnp sio.
On Tue, 5 Oct 1999, Kevin Day wrote: > > > > > Afaik all 3C509B's are PnP. At least here in the UK there is not > > > shortage of those cards. > > > > If I can get a difinitive statement to this effect then I'll grab a > > 3c509B. There was some question as to them actually being PnP though. > > > > Yes, the 3c509B can have PnP turned on or off through a DOS utility. Either > you set an IO/IRQ setting, or you set it to PnP and let the system do it. (I > believe they come with PnP enabled now, but before the default was off) If you find yourself with one of these and pnp is turned off, you can download the DOS utility from 3com. I recently had to do this for a friend (to turn pnp off). It was harder to find a DOS boot disk :-). -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: try to build xfree under current siginfo_t
Fritz Heinrichmeyer wrote: > > as i accidentally deleted my libc.so.3 i thought it would be a good time > to rebuild xfree, but i came in a preprocessor hell due to siginfo_t > _POSIX_SOURCE or not ... definition at the stage of building makedepend. > In file included from main.c:41: > /usr/include/signal.h:72: warning: `union sigval' declared inside parameter \ > list > /usr/include/signal.h:72: warning: its scope is only this definition \ > or declaration, > /usr/include/signal.h:72: warning: which is probably not what you want. > /usr/include/signal.h:72: warning: parameter has incomplete type > /usr/include/signal.h:73: syntax error before `siginfo_t' > /usr/include/signal.h:74: syntax error before `siginfo_t' > > the offending code is between an #ifdef _P1003_1B_VISIBLE > construct. This caused by the recent namespace polution fixes. They were always defined before that, so this was not a problem. I think you should change #ifdef _P1003_1B_VISIBLE into #ifndef _POSIX_SOURCE for now. -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [Patches avail?] Re: MMAP() in STABLE/CURRENT ...
hi again, On Tue, 5 Oct 1999, Matthew Dillon wrote: > : The problem is that the machine is completely locked, I can't get into > :the debugger with CTR-ALT-ESC; no panics so there are no coredumps > :catched. Any advise ? Could you escape in the debugger when you were hit > :by these bugs ? > > If it's completely locked up and ctl-alt-esc doesn't work (and normally > does work - try it on a working system to make sure that you've compiled > in the appropriate DDB options), and you aren't in an X display > (ctl-alt-esc isn't useful when done from an X display)... then your > lockup problem is unrelated to mmap. No X on the machine, but CTRL-ALT-ESC doesn't work. And another thing: I tried the MMAP "exploit"/test that has been floating around at that time on another 3.2-STABLE machine SMP with 2 Pentiums and it does lock the machine but you can switch consoles and escape to the debugger; on the production server (K6-2 300) everything goes dead when it happens (I haven't tried the MMAP test)... You're probably right, it's not the MMAP bug; but it's not faulty hardware -- I'll have an undeniable proof in a few days, I have downgraded to 3.1-STABLE as of 20th April... > > If you are running an X display on this box, you may be able to get > more information in regards to the crash if you turn off X. > > : > : I have: squid (20Mb), nntpcached (17Mb SIZE, 1Mb RES), apache, named, > :MFS, a few PPP processes and the rest of the standard menu. > > The only programs known to cause the swap problem are innd and innxmit, > both part of the inn news system. No such thing (yet); and I heard that innd-stable is OK (I have INND-stable running on that SMP box and had no problems with it) ?... > > : OK, how about some workarounds, I can't wait anylonger for this to be > :fixed, my situation got critical. Should I downgrade to 3.1-RELEASE (that > :hadn't exhibit this way) or can I dare a 4.0-CURRENT (are these problems > :present in -current too ?) ? > : > : Thanks, > : Ady (@warpnet.ro) > > If the machine is locking up to the point where you cannot even drop > into DDB, this bug is not related to the known mmap() bugs. > > At this point I have no idea what might be causing your lockup problem. Neither do I, dammit... :-( > > -Matt > Matthew Dillon > <[EMAIL PROTECTED]> > I'll get back to you in a few days. Thanks a lot, Ady (@warpnet.ro) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
try to build xfree under current siginfo_t
as i accidentally deleted my libc.so.3 i thought it would be a good time to rebuild xfree, but i came in a preprocessor hell due to siginfo_t _POSIX_SOURCE or not ... definition at the stage of building makedepend. In file included from main.c:41: /usr/include/signal.h:72: warning: `union sigval' declared inside parameter \ list /usr/include/signal.h:72: warning: its scope is only this definition \ or declaration, /usr/include/signal.h:72: warning: which is probably not what you want. /usr/include/signal.h:72: warning: parameter has incomplete type /usr/include/signal.h:73: syntax error before `siginfo_t' /usr/include/signal.h:74: syntax error before `siginfo_t' the offending code is between an #ifdef _P1003_1B_VISIBLE construct. Fritz Heinrichmeyer mailto:[EMAIL PROTECTED] FernUniversitaet Hagen, LG ES, 58084 Hagen (Germany) tel:+49 2331/987-1166 fax:987-355 http://ES-i2.fernuni-hagen.de/~jfh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
