Re: mounting/reading a DVD
On Sat, Jan 26, 2008, Mikhail Teterin wrote: g_vfs_done():acd0[READ(offset=4623824896, length=65536)]error = 5 acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x6f ascq=0x04 g_vfs_done():acd0[READ(offset=4623828992, length=65536)]error = 5 acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x6f ascq=0x04 ... ``dd'' refuses to read from /dev/acd0: dd: /dev/acd0: Invalid argument cat tries to, but fails: cat: stdin: Input/output error Is there a step I'm missing? I strongly doubt, the disk is damaged, as I just unwrapped it myself... libdvdcss can probably help, and you can use mplayer or ogle as a front end to it. mplayer has an option to copy the tracks to a file as well. It may be necessary to set the drive's region code to match the disc's before it allows you to read the track keys. There's an ioctl for that... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fwd: How to read bad blocks error message marking of same
On Fri, Aug 06, 2004, Gary Corcoran wrote: Dan Nelson wrote: In the last episode (Aug 06), Gary Corcoran said: Mike Meyer wrote: Modern drives deal with bad block substitution all by themselves. Umm - not quite, right? That is, if a block goes bad and you get a read error, the drive isn't going to do any substituting at that point. You'll just continue to get the read error if you try to access (read) that block. It's only when you allow another *write* to that block (e.g. by deleting the original file and writing new files) that the drive will automatically substitute a spare block for the one that went bad. SCSI drives, at least, may do automatic reallocation on both reads and writes ( camcontrol mode da0 -m 1, the ARRE and AWRE flags ). If the drive had to reread the block or had to use ECC to recover data, AND the entire block was recovered, it will relocate the data if ARRE is set. Good to know, although I stopped buying SCSI disks (for home use) years ago. I presumed the more common case these days, that we were talking about IDE disks. In fact doesn't this (from the original question): ad0s1a: hard error necessarily refer to an ATA (IDE) disk? I don't believe any (current) ATA disks will do automatic reallocation on reads, will they? Though of course serial ATA drives seem to be the future and are taking on more and more SCSI-like features as time goes by. Both ATA and SCSI drives may relocate blocks that were difficult to read (e.g. correctable errors, took multiple attempts, etc). But if the block can't be recovered at all, the drive will still report an error to the OS (in addition to relocation). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: x86 Disassembler
On Tue, Aug 12, 2003, Ryan Sommers wrote: Are there any tools to disassemble an x86 binary file? objdump does a nice job on most files. However, I'm messing with some machine-code binary files that don't have ELF headers or anything other then the machine-code (ie MBR's). I'd like to disassemble them on FreeBSD, possibly to a format that G(as) could reassemble. Then I don't have to use something like debug.exe. One kludge that may work is to use objcopy --add-section to insert the machine code into an ELF file. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why is there no JFS?
Thus spake Terry Lambert [EMAIL PROTECTED]: David Schultz wrote: The easy way to fix this is to insert a new dependency for the completion of the allocation. Basically, this would put in a stall barrier that would cause the outstanding I/O to drain before the new I/O was attempted. All other operations behind the one that caused the stall would b held off, which would avoid the starvation deadlock you describe. Most likely, all this would require some minor code to maintain a running tally of virtual vs. real free block count. It really isn't a big deal. You're saying you can fix the problem where allocations can sometimes fail on a busy 99% full filesystem, but on such a filesystem, you're just as likely to hit it when it's 100% full. Kirk's solution is simple and has the advantage of not requiring additional dependency tracking for the common case. No, actually it should work for 100% full, as well, as long as that 100% full is the real disk vs. the real disk, after all pending updates have been applied. In other words, if it would have worked with soft updates turned off, then it will work with soft updates turned on. My point was that a busy disk that is nearly 100% full will probably experience intermitted ``disk full'' errors anyway, so it suffices to simply deal with cases such as 'rm -rf foo immediately create lots more files', which softupdates does handle in -CURRENT. IMO, this is not the reason for them being off on /; the real reason is as I've stated: sysinstall expects the common case to be an initial install, not operations after the initial install, and so does not turn it on by default. The original reason was due to the possibility of installworld failing, due to the case described above not being handled particularly well in FreeBSD 4.X. Sysinstall is perfectly happy with creating a root FS with softupdates enabled. If someone wants to bother changing the default for what little difference it might make in installworld/installkernel times, I would support it. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Why is there no JFS?
Thus spake Darren Pilgrim [EMAIL PROTECTED]: David Schultz wrote: Thus spake Terry Lambert [EMAIL PROTECTED]: IMO, this is not the reason for them being off on /; the real reason is as I've stated: sysinstall expects the common case to be an initial install, not operations after the initial install, and so does not turn it on by default. The original reason was due to the possibility of installworld failing, due to the case described above not being handled particularly well in FreeBSD 4.X. Sysinstall is perfectly happy with creating a root FS with softupdates enabled. If someone wants to bother changing the default for what little difference it might make in installworld/installkernel times, I would support it. For what its worth, I think all that's needed is to change line 339 in usr.sbin/sysinstall/label.c: ... I think softupdates is still (viewed as) riskier than synchronous writes, at least for large numbers of writes (like installworld) to a filesystem of limited size, so someone is going to inevitably ask if FreeBSD should be loading the bullets as well. Personally, if it's a matter of choosing overall safety or a performance gain for something you really shouldn't be doing to a live machine anyway, I'll take the safe route and option the performance gain. I've heard that argument, and while I think it has *some* validity in general, I don't buy it for installworld/installkernel in particular. Softupdates guarantees metadata consistency (modulo hardware issues that have been discussed on this list before), but it can reorder writes and delay the amount of time it takes your data to hit the disk. For an installworld, this means that the window during which you have a partially installed world is slightly larger, but installworld takes a while, so the window is already pretty darn big. The whole rationale for doing installworld/installkernel in a particular sequence is that with any luck, you can boot to single-user mode after something goes wrong and finish the job (or revert to the old kernel.) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Why is there no JFS?
Thus spake Daxbert [EMAIL PROTECTED]: The inspiration for this email was from a thread in -questions: Re: fsck takes very long after crash/reset Is anybody currently working on or does there exist a JFS for FreeBSD? ... Is there not a JFS for FreeBSD becuase, Softupdates do the job just fine and nobody has the time or interest to work on this? Various people have indicated that they might try to implement them, but there really isn't a lot of support for the idea. People already have softupdates, so there's substantially less incentive to support another technology for ensuring metadata consistency. (As Terry will surely point out if I don't, Softupdates and journalling don't solve *exactly* the same set of problems.) I'm not running FreeBSD 5.x. So I'm not able to take advantage of the background fsck. Can anybody comment on their success w/ the background fsck? Problems have been reported for very large (60 GB+) drives, but otherwise it seems to work well. It is only appropriate to use if the reason you need to fsck is a crash or power failure. If a hardware or software bug messes up part of your FS, you need to run a foreground fsck. If a JFS were to be ported and/or developed for FreeBSD what should it be based on? XFS, JFS, ReiserFS??? It would be easier to add journalling to FFS than to port one of the above filesystems, and the licensing would be problematic. It is less problematic for ReiserFS because Hans Reiser is willing to make exceptions to the GPL as long as e.g. Apple can't build OS X on top of FreeBSD and thereby get ReiserFS without sharing the profits with him. But you still have to find someone for whom softupdates isn't good enough who is willing to do the work. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Why is there no JFS?
Thus spake Brooks Davis [EMAIL PROTECTED]: On Wed, Feb 12, 2003 at 07:40:00PM -0800, Terry Lambert wrote: Darren Pilgrim wrote: Not really. A properly laid-out filesystem hierarchy will result in no writes to / (except for installworld/kernel). That removes the problem that journalling addresses, and is probably why softupdates is disabled by default for /. For large, active filesystems, journalling would be a big improvement when you had to run a foreground fsck. Soft updates are disable on / by default because of the chicken and egg problem of runing tunefs on /. There's no chicken and egg problem when you're booting off install media or for that matter from single user mode. The problem was that softupdates means you don't get space back from deleted files immediatly so previously / tended to fillup during installworld or installkernel. I know some fixes have been implemented in that area, but I'm not sure if then mean you can always write to the space occupied by unlinked files or just that you have a better chance. The problem is effectively fixed in 5.0. Basically, when no space can be found, the syncer is accelerated to try to speed up frees. Technically it's possible to run into a livelock, where you keep freeing space and it keeps getting snatched up before you can grab it, so you wait forever. So IIRC, there is a point where it just gives up on finding the space. However, that won't happen with an install, so the free space problem isn't a reason not to use softupdates on the root FS. I think the default hasn't been changed just because nobody has bothered. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: mac os x 10.2.3 jaguar and port forwarding?
Thus spake Ralph Freibeuter [EMAIL PROTECTED]: Ho can I exactly define a rule (and where?) that forwards incoming requests to port 445 (samba?) to an internal machine with lan ip 192.168.2.50 ? The routing Macs IP is 192.168.2.1 and the external IP is given by ISP via pppoe. Please help me. I've already tried: sudo natd -redirect_port tcp 192.168.2.50:445 445 But all I get are messages about errors and addresses that already have been given. This isn't an OS X list, but... have you tried killing any existing natd instances before you try the command above? I just use natd_flags in rc.conf to specify the -redirect_port options, and it works fine. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Drawing diagrams a-la-Visio
Thus spake Cliff Sarginson [EMAIL PROTECTED]: I am looking for an application that will allow diagrams to be drawn (such as network topologies) similar to the Windows program Visio (I think that is what it is called). One that has some pre-defined shapes/lines etc suitable for technical use. Does anyone have any suggestions ... ? I can't think of a direct comparison any closer than xfig, and xfig isn't as featureful as Visio. However, if you just want a nice looking graph of network connections, and you're happy letting the computer arrange the nodes (for the most part), try graphviz. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: chown broken??
Thus spake Andrew Cutler [EMAIL PROTECTED]: I realise that now, but why does chown not ignore the match since most other commands simply return? . is a directory -- ignored .. is a directory -- ignored This inconsistency is not logical. rm makes a special case for '.' and '..' specifically to avoid this kind of foot-shooting. It gets away with it because it doesn't make much sense to remove your current directory, much less its parent. Unfortunately, you can't really do the same thing for chown because people sometimes do say 'chown -R foo .' and really mean it. Since the '.*' is expanded by the shell, chown has no way of knowing what was really meant. (BTW, the example I gave shows you how to do what you were trying to do, without the problems you ran into.) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: How to truncate a file in the beginning
Thus spake Andre Albsmeier [EMAIL PROTECTED]: Are there any special features in FreeBSD that I can use to truncate a file in the beginning? Let's assume I have a 50GB file. Only the last 10GB are interesting for me and I have to free the first 40GB for some reason. Of course, I could seek to the appropriate position and copy the 10GB to a new file and unlink the old one. The problem is that I don't have a lot of time to do this so I am looking for something like ftruncate() but for the beginning... Nope, you have to copy the data. Technically something like this could be implemented by copying metadata only, but it would only work if the amount you want to snip is a multiple of the filesystem's block size. However, it's a lot of work for a rather uncommon case; even ftruncate() is used infrequently. Perhaps you could devise a scheme for striping your data across multiple 10GB files. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: maxusers and random system freezes
Thus spake Varshavchick Alexander [EMAIL PROTECTED]: Thank you David for such an excellent explanation. So if sysctl reports vm.zone_kmem_pages: 5413 vm.zone_kmem_kvaspace: 218808320 vm.kvm_size: 1065353216 vm.kvm_free: 58720256 does it mean that total KVA reservation is 1065353216 bytes (1G) and almost all of it is really mapped to physical memory because only 58720256 (56M) is free, and the server is balancing on the edge of crashing with KVA going out? Yes, 56 MB of unreserved kernel virtual memory (modulo fragmentation) is probably pushing it for a busy server. Try bumping KVA_PAGES. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: maxusers and random system freezes
Thus spake Varshavchick Alexander [EMAIL PROTECTED]: Well, now I made KVA space 2G, we'll see later on if it helps to get rid of the sudden system halts, but for some reason a side-effect has appeared: pthread_create function returns EAGAIN error now, so I had to recompile the software using it with linux threads to make it working. With the old kernel these pieces worked without problems. Can it be that somehow the enlarged KVA space messed up with the threads mechanism? I'm not a pthreads expert, but my best guess is that your program tried to create a thread with a stack address that was too high. Remember that with a 2 GB KVA, user processes have only 2 GB to play with instead of 3 GB, so attempting to mmap() a stack above about 2 GB would cause pthread_create() to return EAGAIN. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: maxusers and random system freezes
Thus spake Varshavchick Alexander [EMAIL PROTECTED]: On Fri, 6 Dec 2002, David Schultz wrote: Thus spake Varshavchick Alexander [EMAIL PROTECTED]: Well, now I made KVA space 2G, we'll see later on if it helps to get rid of the sudden system halts, but for some reason a side-effect has appeared: pthread_create function returns EAGAIN error now, so I had to recompile the software using it with linux threads to make it working. With the old kernel these pieces worked without problems. Can it be that somehow the enlarged KVA space messed up with the threads mechanism? I'm not a pthreads expert, but my best guess is that your program tried to create a thread with a stack address that was too high. Remember that with a 2 GB KVA, user processes have only 2 GB to play with instead of 3 GB, so attempting to mmap() a stack above about 2 GB would cause pthread_create() to return EAGAIN. Yes this makes sense, however this call to pthread_create didn't specify any special addresses for the new thread. The pthread_create was called with the NULL attribute which means that the system defaults were being used. Something in the system has gone wrong... I just glanced at the source in -STABLE, and it appears to be a pthreads bug. (Then again, maybe I'm missing something, since nobody seems to have noticed this before.) The default address at which new thread stacks are created is just below the main stack. This address is based on the lexical constant USRSTACK, but it should be initialized in uthread_init() based on the kern.usrstack value returned by sysctl. (The correct value is already used to map the main stack's red zone.) The result is that you need to make world and recompile any apps statically linked against pthreads after building your new kernel in order to get things to work. I don't have time to fiddle with pthreads until after Christmas, but you might see if the following patch (against -STABLE) helps when you reduce the configured KVA size without remaking pthreads. Index: uthread/uthread_init.c === RCS file: /home/ncvs/src/lib/libc_r/uthread/uthread_init.c,v retrieving revision 1.23.2.10 diff -u -r1.23.2.10 uthread_init.c --- uthread/uthread_init.c 2002/10/22 14:44:03 1.23.2.10 +++ uthread/uthread_init.c 2002/12/06 13:41:06 @@ -245,6 +245,8 @@ len = sizeof (int); if (sysctl(mib, 2, _usrstack, len, NULL, 0) == -1) _usrstack = (void *)USRSTACK; + _next_stack = _usrstack - PTHREAD_STACK_INITIAL - + PTHREAD_STACK_DEFAULT - (2 * PTHREAD_STACK_GUARD); /* * Create a red zone below the main stack. All other stacks are * constrained to a maximum size by the paramters passed to To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Quota help
Thus spake Andrew Knapp [EMAIL PROTECTED]: Does anyone out there know how to change the grace period on file-system quotas? I know the default is 7 days, but if I wanted to change it, where would I look? The man pages don't seem to be of any help on this, and I didn't find anything in the archive. See edquota(8). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: -O3 optimization?
Thus spake Evren Yurtesen [EMAIL PROTECTED]: I wonder if a source is compiled with -O3 without any problems, might there be any problems in binaries which might create crashes? You're welcome to try it out, but it isn't supported. GCC has a few obscure misfeatures at -O3. Some applications break at -O3, usually because they violate C's aliasing rules or contain broken inline assembly. At one point, the kernel's TCP checksum code had some difficult-to-solve problems with -O3, and I'm not sure whether that has been fixed. Despite all of that, I built world and kernel with -O2 a while ago and noticed no problems whatsoever. Just note that you've been warned, and you probably won't see a significant performance improvement anyway. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: -O3 optimization?
Thus spake Evren Yurtesen [EMAIL PROTECTED]: Well, I made searches from google and people talk that O3 produced quite noticably faster code. But well I am not so hungry for speed. I just wondered if the binary might have something wrong with it or not even though the compiler didnt complain while compiling. What about using -O or not using any optimizations? Is it very rare that -O breaks somethings? I was using -Os and I also didnt notice anything wrong but maybe there can be something I am missing too... -O is the most widely tested setting, and it is significantly faster than no optimization. The higher optimization levels usually increase performance marginally, but they're still just microoptimizing. Maybe if you were running some compute-intensive scientific software you would see more of a difference. Is there big performance improvement between -O and -O2 ? or from not using any optimizations to -O or -O2? Lets say if I am compiling KDE,XFree86. How much would it effect? is there a web page with some statistical data about this? I don't know of any serious benchmarks. Try compiling the software in question with -O3. If it works and performs better, great; if you can't tell the difference you might want to be a bit more conservative about the setting... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: maxusers and random system freezes
Thus spake Varshavchick Alexander [EMAIL PROTECTED]: A question arises. The value 256 (1G KVA space) acts as a default for any system installation, not depending of real phisical memory size. So for any server with RAM less than 2G (which is a majority I presume) the KVA space occupies more than half of physical memory. It can even be more than TOTAL phisical memory for servers with RAM less than 1G. Isn't it bad for a system? It seems that it is not. Then why cannot the KVA space always be made as some big value? If it is important for servers with large RAM, why it is not or a smaller servers? In FreeBSD, each process has a unique 4G virtual address space associated with it. Not every virtual page in every address space has to be associated with real memory. Most pages can be pushed out to disk when there isn't enough free RAM, and unallocated parts of the virtual address space aren't backed by anything. (Referencing an unmapped page that the system doesn't know about generally causes the program or OS to crash. You've probably seen these as ``segmentation faults'' and ``page fault in kernel mode'' panics.) To simplify things, the kernel is mapped into a fixed location in every address space. The KVA parameter controls how big a chunk the kernel gets; the remainder goes to user processes. However, only the part of the KVA reservation that the kernel actually uses is wired to physical memory. For example, if you have a 1 GB KVA reservation and the kernel allocates only 20 MB of RAM, then only 20 MB of RAM is needed (plus some epsilon if you want to be picky), but in theory, the kernel could allocate and manage up to 1 GB of data. You don't lose extra physical memory for increasing KVA, but a large KVA size does constrain the virtual address space available to user processes. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Always mystified by this. /stand file sizes
Thus spake Cliff Sarginson [EMAIL PROTECTED]: I have been meaning to ask this since I started using FreeBSD but have never dared to, since I thought I ought to know :) Excerpt from /stand -r-xr-xr-x 31 root wheel 1865544 Sep 18 2001 -sh -r-xr-xr-x 31 root wheel 1865544 Sep 18 2001 [ -r-xr-xr-x 31 root wheel 1865544 Sep 18 2001 arp -r-xr-xr-x 31 root wheel 1865544 Sep 18 2001 boot_crunch -r-xr-xr-x 31 root wheel 1865544 Sep 18 2001 cpio -r-xr-xr-x 31 root wheel 1865544 Sep 18 2001 dhclient .. etc What does this mean all these things of size 1865544. And where is /stand exactly ? It certainly isn't taking up all this space on root... See crunchgen(1). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Confirmation: ext2fs requires kernel rebuild?
Thus spake Cliff Sarginson [EMAIL PROTECTED]: On Thu, Nov 21, 2002 at 03:09:12PM -0800, David Schultz wrote: Thus spake Cliff Sarginson [EMAIL PROTECTED]: FreeBSD support for ext2fs is a specific instance of the more general problem that features that very few people care about tend not to get maintained. FreeBSD already has a filesystem that is more complete and faster than ext2fs,[1] so the only people using both UFS and ext2fs are also running Linux. If you mount an ext2fs filesystem r/w, consider yourself a beta tester. Oh I am not comparing their relative merits. But the thing is there are people who for one reason or another run heterogenous networks. I mean it is not a crime to run both Linux and FreeBSD (or is it ?). My feeling is that it is a shame that is all. As for your scathing comment about the evolution of EXT2, I have no comment since it sounds like opinion rather than fact. The point of my post was to point out why nobody is interested in maintaining FreeBSD's ext2fs support. But ext2fs really is a simplified version of FFS! Basically, they took out support for fragments and vastly simplified the allocation policies. Some of the things they took out aren't even used anymore in FFS, like the code to take rotational offsets on the disk into consideration. On the other hand, they left out Kirk's realloc algorithm, which has been shown to significantly reduce fragmentation as filesystems age. (FYI, some people have expressed interest in porting ReiserFS to FreeBSD. Hans Reiser is willing to negotiate special exceptions to the license, as long as Microsoft can't build the next version of Windows on top of FreeBSD and be able to use his filesystem for free.) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Disk copying
Thus spake Mark [EMAIL PROTECTED]: Are the disks the same size/geometry? If so: dd if=/dev/olddisk of=/dev/newdisk bs=32k Can dd also be used to copy to/fro my RAID disks (40G), to a single 40G disk? The latter is of a different brand, but has the same size. In other words: how identical does the geometry need to be? If I can use dd here, I think I will use dd to create a core system; and then use additional dumps to backup individual slices. If the drives have the same geometry as far as the BIOS is concerned, you should be okay. Basically, the partition table you copy has to be valid for the target drive. But it's much more reliable to just use dump/restore. If you want to have a spare `live filesystem', just restore the backup to the new disk. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Confirmation: ext2fs requires kernel rebuild?
Thus spake Chris Pepper [EMAIL PROTECTED]: even into GENERIC. To do the latter, the module must exist; it will be created if you make the kernel with -DWANT_EXT2FS_MODULE. It is also installed by sysinstall, IIRC. [...] Hmm...I think you're right. I don't see any documentation for the option. I would just as soon hook the module up to the default build like all the other modules, but maybe the license is an issue. I think it's off by default for stability, but would like to submit a patch to the LABI Handbook chapter linking to a discussion of the FS module. Unfortunately, I haven't yet found a URL that describes it. Thus spake Giorgos Keramidas [EMAIL PROTECTED]: The license *is* an issue. Distributing kernels that by default include GPL'ed code can have many complications for people who make commercial applications based on FreeBSD source. I'm not talking about linking ext2fs support into the kernel by default, I'm talking about just *creating* the module by default. See previous discussion. Stability isn't an issue, except for people who explicitly load the module. I'm aware of the problems with linking GPL'd code into the kernel, but that's not what is being discussed here. The license would only be a problem if there are legal or religious reasons against people building binaries that *could* be linked into the kernel. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Confirmation: ext2fs requires kernel rebuild?
Thus spake Cliff Sarginson [EMAIL PROTECTED]: LINT says: # # Add support for the EXT2FS filesystem of Linux fame. Be a bit # careful with this - the ext2fs code has a tendency to lag behind # changes and not be exercised very much, so mounting read/write could # be dangerous (and even mounting read only could result in panics.) # options EXT2FS This message has been in LINT since the dawn of time and is extremely mystifying. Be a bit careful .. meaning what ? You either mount it or don't mount it, use it or don't use it. What exactly are you supposed to be careful of :) Saying Boo!. FreeBSD support for ext2fs is a specific instance of the more general problem that features that very few people care about tend not to get maintained. FreeBSD already has a filesystem that is more complete and faster than ext2fs,[1] so the only people using both UFS and ext2fs are also running Linux. If you mount an ext2fs filesystem r/w, consider yourself a beta tester. [1] The designers of ext2 basically took FFS and removed the parts they didn't care for or were hard to implement. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Boot stuck at F1 after swapping drives
Thus spake Andrew Y Ng [EMAIL PROTECTED]: Hi all, I shutdown FreeBSD and changed my harddrive and booted up Win2K this morning (needed Windoze for something real quick). I put the FreeBSD harddrive back and it wouldn't boot, it got stuck at the F1 boot0 prompt. Like it couldn't find the MBR or something. How do I get it to boot again? Make sure you've got boot0 on the primary master (assuming IDE) or da0 (SCSI) and on no other drives. Booting from one boot manager on the BIOS boot disk to boot0 on another drive hasn't worked well in my experience. Also, make sure FreeBSD's idea of your drive geometry matches what the BIOS thinks. Posting disklabel and 'fdisk -s' output might help. (The fixit CD is your friend here.) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Reacting to spam targetted to freebsd.org [was: Re: PLS GET BACK TO ME.]
Thus spake Yann Golanski [EMAIL PROTECTED]:
Quoth Giorgos Keramidas on Thu, Nov 21, 2002 at 15:58:03 +0200
This very spammer has hit the lists more than once, and every time I
mailed {abuse|postmaster} at a2000.nl. If they receive a few hundred
messages for each spam message they let through they will certainly
start acting fast :-)
Would it be possible for the owners of the lsit to install something
like SpamAssassin so that those messages actually don't get to us?
Just add a SPAM filter at your end. By the way, this works far
better if people don't *reply* to the SPAM, circumventing your
filters. ;-)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-questions in the body of the message
Re: panic: kmem_map too small
Thus spake Petri Helenius [EMAIL PROTECTED]: With about 150M in use and KVA_PAGES undefined in config (default), both 4.7-STABLE and 5.0-CURRENT panic (1G installed memory). Yes, the default is 256, IIRC. That corresponds to 1 GB of KVA, and you have only 1 GB of physical memory to back it. I take it this is a very busy machine. Short of getting more memory, you can decrease memory utilization by the network, e.g. by decreasing TCP window sizes, or you can limit memory usage by the network so you don't get panics. I forget the details here, so perhaps someone else can fill them in. The thing I´m concerned about that if with 150M kernel memory usage and 200M free and 300M inact memory the system panics, how much extra memory is needed to keep it running? And the swap is never touched. Most kernel memory is not pageable, so swap probably won't help you. Your `kmem_map too small' error message should report to you the size of the attempted allocation and the size of kmem_map. If the map really isn't full, I'm not sure why you would get this panic, unless you're somehow running into excessive fragmentation. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: panic: kmem_map too small
Thus spake Petri Helenius [EMAIL PROTECTED]: Most kernel memory is not pageable, so swap probably won't help you. Your `kmem_map too small' error message should report to you the size of the attempted allocation and the size of kmem_map. If the map really isn't full, I'm not sure why you would get this panic, unless you're somehow running into excessive fragmentation. Nov 3 21:44:52 giga /kernel: panic: kmem_malloc(7164): kmem_map too small: 183193600 total allocated Nov 3 22:10:30 giga /kernel: panic: kmem_malloc(7164): kmem_map too small: 175476736 total allocated This is what I'm seeing. Most of the kernel allocated memory was free at the time the panic occurred, but fragmented though. 71 MB of contiguous wired memory is a huge amount to expect in the kernel at runtime. What exactly are you trying to do? Can you post a backtrace? I'm not a networking guru, so I probably won't be able to tell you what you might not be able to do differently, although you might have better luck if you tried to grab the memory earlier on, when KVA is relatively unfragmented. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: panic: kmem_map too small
Thus spake Petri Helenius [EMAIL PROTECTED]: I seem to get kmem_map too small panics when using large buffers with bpf. Is there a tunable I should be increasing? Yes, increase KVA_PAGES in your kernel config. I put in KVA_PAGES=1024 with following results on next boot: Fatal trap 12: page fault while in kernel mode Read LINT (or NOTES) carefully. You can't set KVA_PAGES to 1024, because then your kernel would take up the entire 4 GB virtual address space. Since the kernel must fit into 4 GB alongside every user process, that leaves you no room for programs. Try a more reasonable value like 512 (2 GB). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Confirmation: ext2fs requires kernel rebuild?
Thus spake Chris Pepper [EMAIL PROTECTED]: To use ext2fs, you can either add the option EXT2FS to your kernel config to compile it statically into your kernel, or you can load the ext2fs module dynamically, even into GENERIC. To do the latter, the module must exist; it will be created if you make the kernel with -DWANT_EXT2FS_MODULE. It is also installed by sysinstall, IIRC. David, I know they're distinct, but it's silly for a discussion of Linux applications to ignore the possibility of those apps residing on a Linux filesystem. I couldn't find ext2fs documented anywhere, which is the first issue. The second is adding a link comment to the LABI chapter. Hmm...I think you're right. I don't see any documentation for the option. I would just as soon hook the module up to the default build like all the other modules, but maybe the license is an issue. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: panic: kmem_map too small
Thus spake Petri Helenius [EMAIL PROTECTED]: Read LINT (or NOTES) carefully. You can't set KVA_PAGES to 1024, because then your kernel would take up the entire 4 GB virtual address space. Since the kernel must fit into 4 GB alongside every user process, that leaves you no room for programs. Try a more reasonable value like 512 (2 GB). Am I correct assuming that the default is 256? I´m not coming near this utilization when the system panics. With about 150M in use and KVA_PAGES undefined in config (default), both 4.7-STABLE and 5.0-CURRENT panic (1G installed memory). Yes, the default is 256, IIRC. That corresponds to 1 GB of KVA, and you have only 1 GB of physical memory to back it. I take it this is a very busy machine. Short of getting more memory, you can decrease memory utilization by the network, e.g. by decreasing TCP window sizes, or you can limit memory usage by the network so you don't get panics. I forget the details here, so perhaps someone else can fill them in. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: FreeBSD cluster setup
Thus spake Adam M Ryan [EMAIL PROTECTED]: Has anyone worked with a cluster setup for fbsd? Is there any information on how I can get started with multiple machines and freebsd running as a solution cluster? http://nrez.net/~rmger/fbsdcluster/cluster-doc.html http://acme.ecn.purdue.edu/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Confirmation: ext2fs requires kernel rebuild?
Thus spake Chris Pepper [EMAIL PROTECTED]: I'm trying to get at a file on an ext2fs slice. I'm a bit confused about kernel recompiles vs. KLDs for Linux compatibility, though. Am I reading correctly at http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/linuxemu.html http://www.seabug.org/archive/2000-05/msg00086.html, that I can run Linux applications with a single command or rc.conf entry, but accessing files on ext2 file systems requires a kernel rebuild? This seems a bit backwards -- is anyone aware of work to make ext2fs a standard module, so it can be loaded under GENERIC? Running Linux binaries and using Linux filesystems are two completely different things. To to the former, and the appropriate rc.conf entry and install ports/emulators/linux_base as described in the Handbook. To use ext2fs, you can either add the option EXT2FS to your kernel config to compile it statically into your kernel, or you can load the ext2fs module dynamically, even into GENERIC. To do the latter, the module must exist; it will be created if you make the kernel with -DWANT_EXT2FS_MODULE. It is also installed by sysinstall, IIRC. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: panic: kmem_map too small
Thus spake Petri Helenius [EMAIL PROTECTED]: I seem to get kmem_map too small panics when using large buffers with bpf. Is there a tunable I should be increasing? Yes, increase KVA_PAGES in your kernel config. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Question about memory usage
Thus spake Matt Winslow [EMAIL PROTECTED]: I'm running FreeBSD 4.5, on a P-133 system. I just upgraded my RAM yesterday from 80MB to 256MB, because it always used to sit at 93-94% used when I had 80. Well now that I installed more, it's sitting at 93% used again. Being newer to BSD, is there a way I can check what is using memory...or does it just do that automatically? Free memory is wasted memory. If you have more of it, FreeBSD will use more, e.g. by caching things longer. With the additional memory, you will probably notice that your system is faster and accesses the disk less frequently under load. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Changing the boot manager
Thus spake Anand Buddhdev [EMAIL PROTECTED]: I currently have the booteasy boot manager on my FreeBSD system, so it prompts me with a menu on startup (F1 FreeBSD) and waits 5 seconds before defaulting to F1. But I only have FreeBSD my box. Is there any way to go back to the simpler, standard boot code that loads FreeBSD directly? I have read about boot0cfg, which is supposed to allow me to change the MBR, but I can't seem to find the correct boot code to install there to get rid of booteasy. fdisk -B /dev/foo0 where foo0 is the boot disk. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
