Re: optional 'make release' speed-up patch
> Hi, > >The following patch to /usr/src/release/Makefile allows the > specification of the variable FASTCLEAN, which instead of doing > a recursive rm on CHROOTDIR, simply umounts/newfs/mounts. Of > course, this is only useful if your CHROOTDIR location is a > separate mount point (which mine is: /snap). > >Comments and critiques welcome. > >Would someone consider committing this please? This patch scares me a little. FASTCLEAN should at a minimum be set to some value, like "NEWFS" (and probably something a bit more descriptive) before it goes around re-making file systems. I would hate to see my file system wiped out just because I have the "FASTCLEAN" environment variable set for some other application, and didn't intend for "make release" to use it. -Mike -- Mike Pritchard [EMAIL PROTECTED] or [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: optional 'make release' speed-up patch
On Thursday, 9th September 1999, "John W. DeBoskey" wrote:
> The following patch to /usr/src/release/Makefile allows the
>specification of the variable FASTCLEAN, which instead of doing
>a recursive rm on CHROOTDIR, simply umounts/newfs/mounts.
>+ -device=`df | grep '${CHROOTDIR}' | cut -f1 -d' '` && \
>+ /sbin/umount ${CHROOTDIR} && \
>+ /sbin/newfs $$device && \
>+ /sbin/mount ${CHROOTDIR} && \
>+ /bin/df ${CHROOTDIR}
This is going to look like I'm putting the boot in after everyone else has
already expressed a negative opinion, but I want to reinforce why this is
a dangerous option, and I think a bit of unhappiness now will result in
safer future contributions. I'm really not trying to be a pain.
First up, destroying file systems in a makefile is a very rare event, and
a pretty spectacular trick to use as a performance optimisation. Admittedly
a make release is heavy stuff already, but destroying file systems is one
step further than expected. Have you tested this and verified that it is
a major time saving? I suspect it is not. Optimising the 10% case instead
of the 90% case just increases the likelihood of bugs, and it is doubly
risky to use the big guns on the small fry.
The proposed code isn't very careful, and would attempt to destroy the
wrong file system if, for example, I had CHROOTDIR set to /d. (Maybe
I like calling file systems /a, /b, /c, etc like those crazy folks on
freefall.) I doubt that it would succeed (because of checks for mounted
file systems) but it would try. So, the code should verify that CHROOTDIR
is a local mounted file system, and of the type you intend to make.
The code runs newfs on the block device. It really should run on the
character device. In a dangerous thing like on-the-fly file system
destruction and creation, precision is important, even if only to instill
confidence in the user when it runs.
Defining FASTCLEAN to destroy a file system is a surprise unless you
are intimately familiar with the makefile. That's a bear trap on the
nature walk. For example, I used MACHINE all the time in my .profile
until it started screwing up FreeBSD compiles. FASTCLEAN is probably
somebody's favourite variable for some unimportant thing. They might
never run make release, but it's lurking there for them when they do.
The variable name should be more descriptive, and require that it be
set to a particular value before it triggers.
So, what's the upside of all this gloom? Do I really think this is the
most dangerous thing I've ever seen? Well, no. I just think it is
inadvisable. There is nothing stopping you from creating a script that
runs make release for you. Then you can newfs your filesystem there,
fully aware of the risks, and fully in control. For everyone else, the
enormous rm is a useful test of the softupdates code. Most things have
a silver lining if you know how to look at them. :-)
Stephen.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
An FS question perhaps... non blocking I/O.
Hi, please redirect to the appropriate forum if appropriate. There is one thing i don't completely understand with non-blocking FS operation. Is there any way to guarantee (more or less strictly, see below) that when i issue a read() on a file (a real file coming from a UFS i mean) such read will not block because data from the disk is not in memory yet, yet avoid that i end up in a busy loop. The app i have in mind is squid-like, which, if i understand well, is a single process looping around a select. If i get things right, select() on a file descriptor will return the read bit set if i am not at the end of file, yet the block might not be in memory yet even if the UFS seems to do readahead. Maybe i can turn NONBLOCK on for these descriptors, but still would have select returning essentially useless info as I'd need to try the read() to be sure... Maybe poll() has some way to indicate "yes you can read and the page is in memory" ? I can tolerate some occasional failures when because of memory shortage the readahead page is discarded after the select/poll in favour of some other one... Any suggestion ? Would async I/O help in a case like this, considering the possible overhead for handling signals when a transfer is complete ? thanks luigi ---+- Luigi RIZZO, [EMAIL PROTECTED] . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) http://www.iet.unipi.it/~luigi/ngc99/ First International Workshop on Networked Group Communication ---+- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: An FS question perhaps... non blocking I/O.
The Posix AIO calls that john implememted are the best way of doing this. On Thu, 9 Sep 1999, Luigi Rizzo wrote: > Hi, > > please redirect to the appropriate forum if appropriate. > > There is one thing i don't completely understand with non-blocking > FS operation. > > Is there any way to guarantee (more or less strictly, see below) > that when i issue a read() on a file (a real file coming from a > UFS i mean) such read will not block because data from the disk is > not in memory yet, yet avoid that i end up in a busy loop. > > The app i have in mind is squid-like, which, if i understand well, is a > single process looping around a select. If i get things right, select() > on a file descriptor will return the read bit set if i am not at the > end of file, yet the block might not be in memory yet even if the UFS > seems to do readahead. Maybe i can turn NONBLOCK on for these > descriptors, but still would have select returning essentially useless > info as I'd need to try the read() to be sure... > > Maybe poll() has some way to indicate "yes you can read and the page is > in memory" ? I can tolerate some occasional failures when because of > memory shortage the readahead page is discarded after the select/poll > in favour of some other one... > > Any suggestion ? Would async I/O help in a case like this, considering > the possible overhead for handling signals when a transfer is > complete ? > > thanks > luigi > ---+- > Luigi RIZZO, [EMAIL PROTECTED] . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) > > http://www.iet.unipi.it/~luigi/ngc99/ > First International Workshop on Networked Group Communication > ---+- > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: An FS question perhaps... non blocking I/O.
> Date: Thu, 9 Sep 1999 16:18:57 +0200 (MET DST) > From: Luigi Rizzo <[EMAIL PROTECTED]> > Subject: An FS question perhaps... non blocking I/O. > [ ... snip ... ] > > The app i have in mind is squid-like, which, if i understand > well, is a > single process looping around a select. If i get things > right, select() > on a file descriptor will return the read bit set if i am not at the > end of file, yet the block might not be in memory yet even if the UFS > seems to do readahead. Maybe i can turn NONBLOCK on for these > descriptors, but still would have select returning essentially useless > info as I'd need to try the read() to be sure... > [ ... snip ... ] Since you are talking about files, I presume when you say "select() on a file descriptor will return the read bit set if I am not at the end of file" you are implying the file descriptor is for a file, not a socket. Admittingly, this has nothing to do with your question directly, but I wanted to clarify something (if nothing else then for my sake): select() will not block on file descriptors referring to files. The logic being that select is only supposed to wait until the operation can occur without blocking (namely a read operation). But reads on files never block, they just return a short count, hence select() always indicates success for file descriptors for open files (and won't block on them). And, we mentioned the the last sentence, select() will always return success for reading file descriptors for open files, EOF or not, since the read would just return a short count. So again, it has nothing to do with the question of finding out whether the data for the read in already in memory, but how can you tell if you are already at EOF for a file using select(), as you describe. I was basing the above statements off of various books I have read, and have never tried select()ing a file's file descriptor for reading as I have always been told it is pointless. If there is a way to do it, I would love to hear it (I have a project that requires tail -f like functionality and I would much prefer to use select() than just checking the file size every so often like tail does). Thanks, Kelly ~[EMAIL PROTECTED]~ FreeBSD - The Power To Serve - http://www.freebsd.org/ Join Team FreeBSD - http://www.posi.net/freebsd/Team-FreeBSD/ "The ultimate result of shielding men from the effects of folly is to fill the world with fools." - Herbert Spencer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: An FS question perhaps... non blocking I/O.
Hmm. I guess this was added to -current; I don't actually run -current, just read the list :) poll(2) on my -stable system doesn't mention POLLEXTEND. I just checked, the poll(2) listed at http://www.freebsd.org/cgi/man.cgi?query=poll&apropos=0&sektion=0&manpath=Fr eeBSD+4.0-current&format=html as being from 4.0-current is dated Sept 7, 1996; either the man page search on the web is out of date or this is an undocumented bit? Kelly ~[EMAIL PROTECTED]~ FreeBSD - The Power To Serve - http://www.freebsd.org/ Join Team FreeBSD - http://www.posi.net/freebsd/Team-FreeBSD/ "The ultimate result of shielding men from the effects of folly is to fill the world with fools." - Herbert Spencer > -Original Message- > From: Juha Nurmela [mailto:[EMAIL PROTECTED]] > Sent: Thursday, September 09, 1999 3:26 PM > To: Kelly Yancey > Subject: Re: An FS question perhaps... non blocking I/O. > > > > Hello. > > Check out poll(2) and POLLEXTEND. > Don't know anything about it, have just seen it > when looking at other things. > > Juha > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: An FS question perhaps... non blocking I/O.
< said: > I just checked, the poll(2) listed at > http://www.freebsd.org/cgi/man.cgi?query=poll&apropos=0&sektion=0&manpath=Fr > eeBSD+4.0-current&format=html as being from 4.0-current is dated Sept 7, > 1996; either the man page search on the web is out of date or this is an > undocumented bit? It is probably undocumented. I was a bit reluctant to document it since I know that the interface is not correct. One of these days, I (or more likely some enterprising young hacker) will fix it. -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: "The Matrix" screensaver, v.0.2
On Sun, Aug 22, 1999 at 05:02:00PM -0400, Chuck Robey wrote: > On Sun, 22 Aug 1999, Ollivier Robert wrote: > > That very important... The screensaver triggered me to see the movie > > again. A. I love it. > > Yeah, it's gotta be the perfect hacker's movie. Sneakers is always fun. :) -d -- dannyman - http://www.dannyland.org/~dannyman/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Stuttering mtv with newpcm & es1370 card
Hi, Earlier today I was trying to watch a short mpeg and found out that it's impossible with newpcm. The sound (and picture) stutters constantly. It works with a kernel from August, 31 (oldpcm). Anyone else able to reproduce this or have any ideas? pcm0: irq 5 at device 10.0 on pci0 http://www.r33t.org/files/cute.mpg for a laugh. Not just this mpeg has this problem, though. -Chris -- [EMAIL PROTECTED] [EMAIL PROTECTED] "We're going to turn this team around 360 degrees." --Jason Kidd, upon his drafting to the Dallas Mavericks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make update
My make update isn't working anymore, and I can't figure out why. I know the recent stuff regarding Id->FreeBSD, and I've closely watched all the files that Doug talked about, and they're all the way he said they should be, but after I get done with the cvsup part of make update, and it looks to be real near the end of the "cvs -q update -d -P", it dies, no core. I have gone in afterwards and tried to do a cvs update without the -q flag so I could spot just where it was failing, but (and this astonished me) it always works when I invoke it directly (not via make). I am using the same cwd, and I've tried the manual cvs update with and without the -q flag, it always works without the makefile, and always fails as part of make update. I've checked Makefile, Makefile.inc0 and Makefile.inc1, they're all in fine condition (cvs diff shows no problems). Any idea why this should be so? ---+--- Chuck Robey| Interests include any kind of voice or data [EMAIL PROTECTED] | communications topic, C programming, Unix and 213 Lakeside Drive Apt T-1 | carpentry. It's all in the design! Greenbelt, MD 20770| picnic.mat.net: FreeBSD/i386 (301) 220-2114 | jaunt.mat.net : FreeBSD/Alpha ---+--- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
NewPCM and Quake :)
Hi, I am trying NewPCM on -current with an AWE64. It works fine for normal sound apps like esd, splay etc etc.. but Quake 1 & 2 which use the DMA buffers to play their sound. It is allowed to do this (the ioctl is supported), but it stutters very badly. Its a bit hard to explain :) --- 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 PGP signature
Re: NewPCM and Quake :)
I get this two, it sounds like its playing at the wrong sampling speed, but none of them (speeds) sound right. - ( Adam Strohl ) - - UNIX Operations/Systems http://www.digitalspark.net - - adams (at) digitalspark.netxxx.xxx. x - - ( DigitalSpark.NET )--- - On Fri, 10 Sep 1999, Daniel O'Connor wrote: > Hi, > I am trying NewPCM on -current with an AWE64. > It works fine for normal sound apps like esd, splay etc etc.. but Quake 1 & 2 > which use the DMA buffers to play their sound. It is allowed to do this (the > ioctl is supported), but it stutters very badly. > > Its a bit hard to explain :) > > --- > 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: NewPCM and Quake :)
I also get this, on an SB32-PNP, with the pcm0 device (setup for pnp) I havnt tried q3atest on the sb0 stuff though.. I might do this weekend. Daniel O'Connor wrote: > > Hi, > I am trying NewPCM on -current with an AWE64. > It works fine for normal sound apps like esd, splay etc etc.. but Quake 1 & 2 > which use the DMA buffers to play their sound. It is allowed to do this (the > ioctl is supported), but it stutters very badly. > > Its a bit hard to explain :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NewPCM and Quake :)
On 09-Sep-99 Adam Strohl wrote: > I get this two, it sounds like its playing at the wrong sampling speed, > but none of them (speeds) sound right. I didn't try that.. I was wondering if the DMA buffer switching wasn't done correctly. I'll try and work up a test program which exibits the problem over the weekend. --- 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 PGP signature
Re: NewPCM and Quake :)
On 10-Sep-99 Mike Muir wrote: > I also get this, on an SB32-PNP, with the pcm0 device (setup for pnp) > I havnt tried q3atest on the sb0 stuff though.. I might do this weekend. Ahh.. I've only tried Q1 & 2, and they both get the problem, but work fine using sb0 and friends. --- 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 PGP signature
No Subject
Anyone running CompuPic?
Not sure which list this should go to, so if I'm in error feel free to point me in the right direction. I was wondering if anyone has had any luck running CompuPic (http://linux.compupic.com) under FreeBSD? It's an excellent image viewer that can do some basic file management as well. Along with Agent, it's one of the few good apps available for Windoze, and I was excited when I heard there was a free *NIX version available. Unfortunately, I haven't been able to get it to run. I'm not in FreeBSD right now so I'm working from memory, but I had some trouble with the install process (it is obviously not as portable as they'd have you believe). I seem to recall setting $UID and installing bash, but the script still bombed after it was installed. Then I had to brandelf it. I tried both "Linux" and "FreeBSD" branding and one was working better than the other though I don't recall which. End result: It starts to load, brings up a splash screen, and exits. I do recall it leaving messages on the console but forget which signal it was dying with. I can get more info if it's wanted but first I'm just asking if anyone else has either had better luck than I. Here's a quote from the website: "CompuPic is highly portable, and Photodex intends to support as many target platforms as possible over time. CompuPic for Linux (and UNIX) is available as a statically linked executable with no library dependencies whatsoever. You need only a Linux or UNIX kernel to run CompuPic. CompuPic has been tested with major Linux and BSD distributions and had no distribution specific issues. If you represent a hardware manufacturer or Linux/UNIX distribution publisher, you can contact Paul Schmidt to discuss Photodex's development plans for a specific platform. Paul Schmidt VP Technology Photodex Corporation 1106 Clayton Lane #200W Austin, TX 78723 (512) 406-3061 - voice (512) 452-6825 - fax [EMAIL PROTECTED]" They seem to make a point of saying "Linux/UNIX" and not referring to all of *NIX OS's as "Linux", even going so far as to mention BSD once. I was therefor a bit surprised when the binary wouldn't run on FreeBSD. I wonder if The Powers That Be would be interested in pursuing the last sentence there? FYI: My system is SMP 4.0-CURRENT from a day or two ago, XFree86 3.3.3.4 from packages, KDE-1.1 from packages, Linux emu running, etc. As far as my FreeBSD proficiency, lets just say I'm probably not the kind of person that ought to be running -CURRENT :) so I don't think I'd be much help in tracking down the problem (aside from being a guinea pig). of course there also exists the possibility that I forgot to insert tab A into slot B and CompuPic indeed runs perfectly in FBSD for everyone else.. and how did it get to be 3AM ? Ugh. well thanks to anyone who can clue me in, Tom Embt ICQ UIN: 11245398 [EMAIL PROTECTED] d:-)> -- "You're one of those condescending Unix computer users!" "Here's a nickel, kid. Get yourself a better computer" - Dilbert. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: An FS question perhaps... non blocking I/O.
Luigi Rizzo <[EMAIL PROTECTED]> writes: > Is there any way to guarantee (more or less strictly, see below) > that when i issue a read() on a file (a real file coming from a > UFS i mean) such read will not block because data from the disk is > not in memory yet, yet avoid that i end up in a busy loop. There is no way to guarantee that a read will not block on disk I/O. The same applies to writes. The read/write calls should never return EAGAIN for local files, even if they are set for non-blocking I/O. This actually makes sense. Given virtual memory, you also don't know if your call to read or the memory you're copying to is actually in memory, it might block to page something in, which is also disk I/O and is comparable to the I/O for the actual file. So even if non-blocking would "work" on local files (how could it, meaningfully?), it would be a hint at best. > Any suggestion ? Would async I/O help in a case like this, considering > the possible overhead for handling signals when a transfer is > complete ? Yes, aio is probably the best alternative. It is quite expensive, though. Another alternative is to use multiple processes, but it also has considerable overhead. FreeBSD and typical Unix-like systems in general aren't perfect. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
