Slashdot Mirror
FreeBSD 5.0 Developer Preview #1 Released
An Anonymous Coward writes: "The FreeBSD developers just announced the release of an official snapshot of the upcoming FreeBSD 5.0 which should be expected in November. Time to try out amazing new feature like background fsck, FFS snapshots, KSC, devfs, SMPng and many more. Check the Release Notes for detailed information." Read on for a list of ISO mirrors, too.
Thanks to AEtherSPOON, you can spare the main servers and use one of these FTP mirrors to grab the ISO:
The design of the BSD file system, when using "softwrites", is specifically engineered to handle this. It does require a rather sophisticated fsck (and one that is aware of how softwrites works). On the other hand, this also removes some of the complexity of the file system (which is not to say it isn't tricky code, but tricky in a different way from, say, a journaled filesystem)
"It's overkill, of course. But you can never have too much overkill." - Anonymous Slashdot Coward
To quote: "fsck(8) now has support for foreground (-F) and background (-B) checks. Traditionally, fsck(8) is invoked before the filesystems are mounted and all checks are done to completion at that time. If background checking is available, fsck(8) is invoked twice. It is first invoked at the traditional time, before the filesystems are mounted, with the -F flag to do checking on all the filesystems that cannot do background checking. It is then invoked a second time, after the system has completed going multiuser, with the -B flag to do checking on all the filesystems that can do background checking. Unlike the foreground checking, the background checking is started asynchronously so that other system activity can proceed even on the filesystems that are being checked. Boot-time enabling of this feature is controlled by the background_fsck option in rc.conf(5)."
You are right on Theo getting rooted. This sufficiently propelled the OpenBSD team into the security first approach that has made them so famous.
Thats not the real Theo. Its really spelled Theo de Raadt, not DeRaadt. Its just some troll who likes to think he acts like him.
Just because a kernel supports the Intel 80386 CPU doesn't mean that later x86 processors can't leverage their advances with the same kernel. It seems that you didn't fully register the last phrase in your blockquote. When a kernel supports advanced instructions, CPUs with lesser instruction sets must run tests to see which instructions are supported, and which they need to ignore. This significantly slows down the relatively underpowered 386 class CPUs, while post-Pentium grade CPUs hardly notice anything.
The trouble isn't that advanced instruction sets aren't utilized, but that there is no streamlined kernel for 386s that doesn't waste their precious time. Let me fictionalize a dramatization:
"Are you superscalar?"
"no"
"Do you grok MMX?"
"no"
"Have you heard of SSE?"
"huh?"
"Do you have the Pentium Floating point Bug?"
"The what?"
"Do you mind if I waste another 16,000,000 cycles asking you rhetorical questions?"
"no - at least not until I get my I386_CPU optimized kernel, so that I can make every kHz count!"
Support for i386 chips in the generic kernel should definitely be the default, even if it did mean that the advanced features in the latest CPUs couldn't be fully exploited. For one thing, you need to ship the lowest common denominator so that the lower boxes can even run in the first place. Not to mention that it is much more sensible to ask a Terahertz Sexium w/Frobnitz CPU to recompile a kernel than a piddling 16MHz 80386 with a whopping 8MiB RAM. By the time the poor thing grinds out a useable vanilla kernel, your latest generation system is starting its third bout of "make world".
It's called perspective... not everybody can track the latest revision of every hardware component. Some systems actually have uptimes higher than your IQ. (Hmm, was that last bit an insult? better think about it...)
-castlan
Except generic code that runs on any i386-i686 is going to be less optimizable and more verbose than code that runs only on i486-i686.
386 lacks certain instructions (e.g. cmpxchg); the compiler's not going to do a CPU check every time such an instruction will be useful, it'll just choose a solution that works everywhere, and you can be sure code that's good for a 16MHz 80386 that's just pulled the series out of 16bit hell is not going to be good for a 1600MHz Pentium 4 that doesn't even impliment the instruction set natively.
Besides which, anyone running i386 level hardware is hardly going to be interested in any of the new stuff in 5.0; they're probably still running 2.x, 3.x or maybe 4.x.
What he means is: kernel-land threads as opposed to user-land threads. Kernel threads are independently schedulable (the scheduler deals with threads not processes), user threads run in one process and take turns executing within that process's cpu allocation (timeslice) using a library to switch stacks and do partial context switches. User threads are not seen by the kernel and are not independently schedulable by the kernel. I.e. if one user-land thread blocks, none of the user-land threads in that process will run since the kernel only schedules the process, even if these threads are capable of running. Also, within a single process, user-land threads cannot execute in parallel on SMP machines while kernel-land threads can.
Threads that exists in the kernel are probably currently implemented in a way similar to linux's clone and FreeBSD's rfork(): they are probably really processes sharing the kernel address space.
> Come back up immediately after an unclean shutdown, but have a background task sucking up IO bandwidth for an hour or three.
FFS fsck's quite fast, actually. As for sucking up IO; background fsck can be ran at a higher nice value.
IO operations for niced tasks are reduced in favour of other tasks competing for IO; so, you *could* have fsck running for hours if your system's doing a lot of IO and fsck is running at a nice of +20, but you're unlikely to notice it on anything but an accurate IO benchmark.
See Running "fsck" in the Background, section 7.
Sigh, at least get the name right, even if you have no id ea how the technology works.
-sirket
FFS (the filesystem used by the BSDs) is designed not to require defragmenting, not in the sense of Microsoft FAT-type filesystems. (FFS uses different algorithms for laying the data out on disk, which I unfortunately can't explain well enough to be of use.) So it's kind of a non-issue here.
RAM fragmentation: "Fragmentation" is a vastly over-used word in the computer world. As applied to filesystems, it means a suboptimal layout of disk blocks on the disk, therefore requiring lots of seeks to read/write the data blocks. RAM disks are random access, and it generally takes the same amount of time to grab a disk block from a RAM disk no matter where it is. The word "fragmentation" can be applied to memory but in a different context that what you cited.