Hold on, if you partition with a different utility like gparted/qtparted, will BSD take the space it's given or insist on partitioning something itself?
with the announcement of the features last night the following topics were beaten to death already: Why use FreeBSD? (why not?) FreeBSD is dead! (clearly its not) FreeBSD is not dead! yahoo use freeBSD (nobody cares) FreeBSD vs Linux (ooh flame ware, but then everybody realized that it doesnt matter some people prefer FreeBSD for stability & the fact its all integrated, some people prefer linux because it has lots of flashy features & there are loads of projects to add extra features to it ( but they're not integrated and don't always play well together)!)
please go about your business there's nothing to spam about here!
ZFS is indeed labeled experimental, and it's an important distinction. That said, I believe that Pawel Dawidek, who ported the file system from Solaris, is using it in production. The chief caveat at the moment is that ZFS should only be used on the amd64 architecture. Other issues are not specific to FreeBSD's implementation of ZFS, e.g., the large memory footprint, but are instead inherent to the current release of ZFS and would be the same under any OS. More about the project at http://wiki.freebsd.org/ZFS/ [freebsd.org].
We're using FreeBSD 7.2 RC2 ZFS in a production environment on Amd64. It's getting hammered, and holding up fine.
1) ZFS has *solved* our storage problems. 2) ZFS needs 2GB of RAM 3) You should run it on a dual core processor if you're going to use compression. 4) Research glabel so you can move drives around from cable to cable and still use the same device name.*
This is not intended as a troll... really... but it's good to keep in mind that this is the FreeBSD team's definition of "experimental". You may be more accustomed to the meaning that the Linux community attaches to that term. When Linux says it's experimental, that generally means it won't work for most people. When FreeBSD says it's experimental, that means you can probably use it in production but you might want to keep an eye on it.
When Linux says it's experimental, that generally means it won't work for most people.
Define "work".
As I posted up in the thread, pata_via incorrectly detects my 80 wire cables as 40 wires, but the whole switch over from/dev/hda to/dev/sda (and sdb, hpt366 still puts my 4 RAID chip devices as hda b c and d) went very smoothly and two kernels ago was labelled EXPERIMENTAL.
Turning off all EXPERIMENTAL kernel options leaves you with a system that really is only good for i386, not the i686 and better.
Funnily enough, the devices connected to the HighPoint chip are using the same cables, s
When FreeBSD says it's experimental, that means you can probably use it in production but you might want to keep an eye on it.
Does that hold true for such things as tmpfs? I've been using that on a devel server without incident, but would like to roll it out elsewhere if it was widely thought to be stable.
GREAT article - it is interesting for a non-programmer to read this type of technical detail, presented in an understandable way. For me, right at the edge of my theoretical-only knowledge. A detailed summary, I guess. (oxymoron)
I have a dual-Opteron rackmount Dell with a ServerWorks HT1000 chipset, running 7.0-PRELEASE from January 15, that was having DMA-related fits. Does anyone know if they've got that problem under control yet? I had seen it discussed a lot on the mailing lists but lately haven't had the time to follow closely. Either way that server's staying on the 7-STABLE line because it's so much faster that I can live with running the drives in PIO4 (and with 4GB of RAM those drives don't get touched a lot).
Fair enough, but given most people here are Linux or Windows kids, you're still better off asking the lists - even if you get a "read the archives!" response you'll know more than you'll get here. >:)
You'll have everything you need. You may want to consider PC-BSD [pcbsd.org], a.. friendlier edition of FreeBSD. It uses KDE by default, and as you're a Fluxbox user, you'll know how to swap that out as needed.
The only gotcha is that nVidia's binary drivers are just as finicky as in Linux, and you're SOL if you want to use the amd64 version of FreeBSD, unless I'm out of touch. You can find their binary driver here [nvidia.com].
I happen to have a very similar setup on my FreeBSD 7-STABLE system right now, and it works great.
You should have no problems at all. It'll work perfectly.
However, is there a compelling reason for you to switch? Debian is a great operating system, and unless it's not working out too well for you, you should not just switch for no good reason. You risk being unproductive for a few days, running into issues you don't know about, etc.
How does one install new software on BSD? (do you compile everything from source?)
I upgraded from 6.2 to 7.0-PRERELEASE by doing the following:
It's a convolouted process, but I wanted to follow FreeBSD 7 development. It's easier when you do it from a binary CD. Basically you restart from the CD and upgrade and it's automated.
Start by updating my system source: $ sed -e 's/RELENG_6/RELENG_7/'/usr/share/examples/cvsup/stable-supfile >/root/7-supfile $ csup -h cvsup6.freebsd.org/root/7-supfile
Seriously, jump! I switched from Debian (2.something, I think) to FreeBSD 4.5 *years* ago. I haven't been happier. I'm still running FreeBSD 6.3 on my server, and I will upgrade to 7 soon, but I found PC-BSD to be the better desktop system (DesktopBSD had strange quirks, and wasn't as polished).
PC-BSD uses the "stable" FreeBSD as it's base, so although it's currently FreeBSD 6.3 based, that'll no doubt change to 7.0 soon. PC-BSD also uses KDE as it's desktop environment, so you'll have no trouble with your a
I too switched from being a debian server person to FreeBSD back in the days when FreeBSD 4.0 was new. In fact, I still have a bunch of FreeBSD 4 servers that I installed, left the company for 2 years, came back, and they're still running fine:D
They will be upgraded/hardware replaced with 7.0 machines soon (have been waiting on 7.0 release for a few months now).
Now, why did I switch?
For me, several factors, these are the main ones...
Clear seperation of the supported "base system" and additional ap
You're probably spoiled by the package manager. Ports are neat, but apt is a dream. At the very least you'll have to get used to a different way of doing things. If you use a lot of custom repositories (e.g. rarewares [rarewares.org]) you might encounter a few headaches getting all the software you want. There are some things, like 'apt-cache search' that it's not immediately obvious how to do on ports. I think you're just supposed to string together 'find' and 'grep' commands, since ports is just a tree full of text
You're probably spoiled by the package manager. Ports are neat, but apt is a dream. At the very least you'll have to get used to a different way of doing things. If you use a lot of custom repositories (e.g. rarewares [rarewares.org]) you might encounter a few headaches getting all the software you want. There are some things, like 'apt-cache search' that it's not immediately obvious how to do on ports. I think you're just supposed to string together 'find' and 'grep' commands, since ports is just a tree full of text files.
I'm running FreeBSD, and the latest release of wine works just fine for most things.
Then I guess we have had markedly different wine / FreeBSD experiences. I haven't found a working combination of the two since FBSD 5.4 with a version of wine that was still numbered by its release date. Since then each successive version of wine has run fewer windows applications for me.
And as for games, I have yet to find a windows game that I can run in wine on FreeBSD at all. But obviously that's not the focus of FreeBSD anyways, so I don't hold it against either. It would certainly be nice t
Of course, there has been a few kinks here and there, but the problems eventually get resolved over time. They do truly wholeheartedly care, but the logistics of wine development make it extremely difficult to live up to a standard that shows that. It's like tapping into a market where you have little experience in. Even if you try really hard, chances are, there will be kinks that you have to work out.
FreeBSD has shown its part with a wine port and some FreeBSD users contributing to wine. Wine has shown its
From personal experience, WoW runs on FreeBSD, but the installer won't work (or didn't on 6.2 & whatever version of wine I was using a year or so ago).
And the obligatory kudos to the FreeBSD guys for this one. I'm seriously contemplating a switch back (I'm running Ubuntu now, and am a little skittish after all the hand-wringing it took to get it to work on my laptop). There's some things I don't like about FreeBSD as far as desktop stuff goes, but the more centralized nature seems to give it more stab
To quote from the article... I believe we are actually "first" to make it part of the shipping kernel. In Linux you can enable it as a module, but there are extra steps you must take. For FreeBSD its just there, like TCP.
There's extra steps you must take? What steps are these? I haven't had experience with SCTP on any OS, but I would have thought that once the Linux module is loaded, the protocol is "just there" as well.
Maybe he's talking about kernel defaults? It's a curious statement th
I've been reading about zfs for awhile and recently started implementing it on some Solaris servers and really getting into it. It's nice. Really nice. I am anxiously awaiting being able to run it on linux (not via FUSE) in production. Has anyone heard anything on the objections over license compatibility and stepping beyond traditional filesystem areas of the kernel?
You can do whatever the hell you like with GPLd software, you just can't distribute it as part of a non-GPL project.
ie/ Unless it's LGPL, you can't put the CDDL (ZFS) software in the same download as Linux (GPL). You can, however, download them separately and use them like that. That's what the ZFS-FUSE project is trying to do.
Dramatic improvements in performance and SMP scalability shown by various database and other benchmarks, in some cases showing peak performance improvements as high as 350% over FreeBSD 6.X under normal loads and 1500% at high loads. When compared with the best performing Linux kernel (2.6.22 or 2.6.24) performance is 15% better.
So: How do you upgrade an existing system from FreeBSD 6.0 without wiping the entire system and installing from scratch?
And before anyone asks:
Yes, I know about the ports collection.
Yes, I know about the binary packages.
Yes, I know how to configure and compile the kernel.
No, I've never really tried to compile userspace.
All the docs I've read on the subject tend to suggest that the Real Way to keep a FreeBSD system current is to download the kernel and userspace core every so often and recompile them. And that's fine, sorta, except that it doesn't address how to deal with the "leftovers", such as config files that have been moved or eliminated. (I mean, honestly, compiling the world is not a realistic way to keep current on X.org.)
Who has practical experience doing this? How do you keep your machines current, particularly with security patches?
As far as security and other within-branch updates go, I've had no problems in the past keeping the base system up to date using the steps outlined in the Handbook (cvsup, make kernel/world/etc, reboot, install, etc). Config files are usually handled with mergemaster, which isn't half-bad when it comes to keeping configurations in check. X is a third-party package, so it gets handled with the port/package tools (the jump to modular X was a pain in the dick IIRC, but it all got smoothed out). I'm not sure wh
I just use freebsd-update. That does mean that custom kernels are a pain, but OTOH I have never had any problems. Well, there was the one time that it took two reboots to get the release to update for whatever reason, but that was just an annoyance.
I've come to think of journaled filesystems as pretty much ubiquitous at this point, is FreeBSD really only now getting them? Or do they mean something else?
No, you read that right. The reason is mainly that FreeBSD users have been enjoying something called "softupdates" for the last decade or so, which is sort of like an in-memory journaling. Rather than writing metadata directly to disk, it's queued in memory, grouped into an efficient order, then transactionally committed to the underlying drive. The disk is never in an inconsistent state, even without a journal to fall back on. If the system crashes, a special fsck that can run while a filesystem is mounted read-write comes along and deallocates any space that's no longer used but hasn't yet been marked as empty.
Because of that, there hasn't been much need or real drive to get journaling into FreeBSD. The solution they're going with is actually nicely abstracted, in that you configure a journal for a whole device through GEOM (which is kind of like a Lego set for building drive setups). Although you'd probably never want this, you could theoretically have two "drives" that reside on remote machines (via ggate) bound together with RAID1 (via gmirror), encrypted (via geli), and with a local journal (via gjournal).
I had to abandon FreeBSD a few years ago with performance with MySQL got so abysmal -- apparently the MySQL folks and the FreeBSD folks got into pissing match about threads.
I don't know the results of the "pissing match", but I can attest to the re-written ULE scheduler (NOT the same ULE that was in 5.x and 6.x! This scheduler is referred to as ULE/SMP2.0) being both stable and greatly improved. The scheduler was tested *specifically* against MySQL, and the benchmarks exceed that of Linux. Here's the details you want:
My feedback as an user of "current" Linux distros.
- I found the same sysinstall that I saw 4+years ago when I last tried installing Freebsd. - I found that the official way to configure is to generate the config file template using 'Xorg -configure' and then hand editing the xorg.conf config file!!!! - I found that the standard install still installs TWM and doesn't even ask for KDE/GNOME (I know you need to install the packages *after* the install, and yes I know I can use sysinstall) and you are dropped to a text login after install. - I found that my amd64 cpu with the nvidia integrated card doesn't have an nvidia driver. And the default nv driver can't make use out of DDC to configure my brand new widescreen LCD monitor. - I found that my mouse pointer is invisible in X.
Now, before other start, please understand why I am saying this - I know Freebsd has a different approach to building a distro. I also know that reasons like prop. drivers are not its fault. I also accept that I probably am facing some system specific issue inherent in any.0 release of distros.
My point here is simply to let how a typical user who thought of migrating to Freebsd thinks. I for one, value using my relatively new hardware to the fullest, so I am going back to Ubuntu.
I still have tremendous regards for Freebsd as a server. I have found them to be much more stable than any current Linux distro, and capable of much more punishment too.
- I found the same sysinstall that I saw 4+years ago when I last tried installing Freebsd.
What's the problem, does sysinstall not work for you? I've never had a problem with it. If you fear the sight of plain text, then FreeBSD will not be for you. While FreeBSD makes a damned awesome desktop system, that is not its goal. It is not designed for Aunt Tillie.
- I found that the official way to configure is to generate the config file template using 'Xorg -configure' and then hand editing the xorg.conf confi
Hmm. The time I tried to install FreeBSD, the installer choked on my hardware. I tried two different dell desktops. Part of the problem was an inability to deal with a USB keyboard. I hope that has been fixed, and I plan to try FreeBSD again, some day. I'll stick with a more common OS, for now.
Hmm. The time I tried to install FreeBSD, the installer choked on my hardware. I tried two different dell desktops. Part of the problem was an inability to deal with a USB keyboard. I hope that has been fixed, and I plan to try FreeBSD again, some day. I'll stick with a more common OS, for now.
FWIW, there's something about Dells and USB keyboards and the FreeBSD single user mode. I'm not sure exactly what the problem is (or I'd contribute my own fix), but a workaround is to go to the loader prompt on boot (option 6 I think) and enter 'set hint.atkbd.0.disabled="1"'m then 'boot'. This will bump the AT keyboard out of the way and allow the USB keyboard to function. You'll either need to set this in your/boot/device.hints after installation or remember to do it whenever you boot into single user mode.
I haven't run FreeBSD since 6.0, but the problem with Dells, IIRC, is that the AT controller acts like there's a keyboard there even if there isn't one.
I had no problem using the clearly labeled "boot with USB keyboard" menu option.
It's a moot point -- with the at mux that came in I believe halfway through the 6-series, you can have as many keyboards as you feel like.
There's something about Dells, USB keyboards and any non-windows installer... Tried about 5 os boot disks on a vostro before I discovered you need the keyboard in just the right socket - and then it screwed up after you chose the kbd type in the installer, necessitating a different machine to install on. Once installed it's worked well.
I've never had a USB Keyboard problem with FreeBSD
From 5.4 to 7.0, K6-III + Tyan/VIA mobo -> Athlon + Abit/nForce -> Athlon64 + ASUS/nForce -> Core Solo + Toshiba/Intel.
I've used USB keyboards on all of them. The only time I don't use an PS2 Keyboard is with the Athlon, and then only when I need to edit the bios settings (no USB support for the BIOS menus? WTF?)
Slated for 7.1 is support for booting GPT [wikipedia.org] partitioned disks. This will make the whole partitioning thing even easier, since it will make BSD labels and the MBR go away entirely, and partitioning will be done entirely using LBA addressing.
Unless you actually want to install from CD and use any of the packages.
As of 6.2-R, it still required no fewer than four CD-swaps (between 2 cds) since the installer can't handle "dependencies coming in the future"[0]
[0] Package A(Disc 2) depends on Package B(Disc 1) which depends on Package C(disc 2). Instead of installing Package B on the first run through, knowing the other two will be coming, it will ask you to swap back and forth.
I love my freeBSD, but installing it has gotten really painful.
To be honest, i have never tried the package CDs. I either do it via the net if im in a hurry so i get the most current version, or via ports if im not in a rush ( ports are the preferred way anyway ).
The only exception is if im building a base server, i have my favorite set of packages that i keep on a separate cd and install them after a minimal install.
Some things I like to have from the get-go. bash, for example... I'm perfectly capable of using tcsh or even *shudder*/bin/sh, but it adds steps. Add non-root admin user -> install bash -> change user's shell
Kind of obnoxious. As I said, I still use it, I just really wish they'd consider this the problem that it is.
I don't want to have to figure out disk geometry to install an OS...have they made it as easy as Ubuntu?
You don't need to figure out the disk geometry if you use the guided installer. I usually like to set that myself anyways, I find it funny you want it compared to Ubuntu, Ubuntu almost wants to hold me back from setting up my disk exactly how i want it. As far as how easy the installer is, if you can install a Slackware system its pretty similar, same solid color menus and package selection(if you do
While I believe you quite rightly attained your +Insightful mod, I couldn't even start to tell you what my disk geometry is, and I'm running openSUSE, XP and (sorry) Vista on the same HDD, partitioned through Linux fdisk after XP had the whole disk, and Vista was the last thing on there. Messing around with partitions is not hard, but never have I been asked to delve into things that the BIOS presents and are ignored only to be faced with a utility querying the HDD itself and be asked if the returned inform
For people that are looking for the more typical mainstream Linux install experience, FreeBSD still isn't there. But it isn't that hard, and there's always DesktopBSD which is pretty much identical apart from the install program and desktop integration.
Whether FreeBSD is too hard to install or not comes down far more to tolerance for ncurses style programs. I personally grew up on them with dos and early windows versions.
Which reminds me that I've got to download a copy of DesktopBSD to try out.
Disk Geometry trolling isn't funny or have you confused this with partitioning. So, are you trolling or are you stating that you don't like to partition drives. If it is partitioning then you may want to check out the above links; if you're trolling, then continue with what you're doing
by Anonymous Coward writes:
on Wednesday February 27, 2008 @09:56PM (#22582778)
I've never needed to know any of those things to install FreeBSD. We run a number of FreeBSD virtual machines and physical servers. I installed them all myself. The most complicated part was entering network information, since all of these systems had static IPs and weren't using DHCP. Unless you're doing something out of the ordinary, you can just use all the defaults and have a fully working system in 15-20 minutes on an average machine.
I've been using FreeBSD since version 2.2.7. I've been using Linux and other OSs even longer. Operating systems that have been around as long as these weren't just created from the start to be a breeze to install. Linux used to require a lot more manual configuration than it does now... just because something like Ubuntu makes it easy doesn't mean it always was. Linux has progressed in this area, and so has FreeBSD, and so have most other mature operating systems.
Also, FreeBSD is not targeted at the same audience as something like Ubuntu. A better comparison would be PC-BSD and Ubuntu, as they are targeted at desktop users. I guess maybe FreeBSD could be compared to the server or alternate editions of Ubuntu, in which case the install process (using text screens) is fairly similar.
Ubuntu easy to install? Perhaps. But does it meet the quality standards of FreeBSD and esp OpenBSD? I dumped Ubuntu and over wrote the partitition with OpenBSD because everytime I tried to manually enter in my network encryption parameters manually, the next time Ubuntu booted it just ignored it and locked onto the strongest unencrypted signal.
everytime I tried to manually enter in my network encryption parameters manually, the next time Ubuntu booted it just ignored it and locked onto the strongest unencrypted signal.
Were you using nm-applet and the keyring? I've never had a problem doing it like that.
Actually, the usual answer is the pre release have extra stuff turned on to help enable debugging. That's why it's not a release where they turn that extra stuff off, or you can recompile the pre release kernels and such.
by Anonymous Coward writes:
on Wednesday February 27, 2008 @09:12PM (#22582286)
It's quite good. Where I work, we've been using the release candidates to store upwards of 15 TB of data, spread over about 50 hard drives. We haven't had any problems, and the performance has been fantastic.
Solaris still offers better support, but the ZFS support offered by FreeBSD is production quality.
No, it's not production quality. Not when there's bugs which can deadlock the entire system when copying large sums of data between UFS and ZFS filesystems:
It's actually pretty stable. Having said that, there are some issues surrounding it.
For starters, FreeBSD 7.0 uses ZFS ported from version 6, whereas Solaris now has ZFS pegged at version 10. There have been numerous enhancements made to ZFS in v10 which aren't in v6. It remains to be seen how the FreeBSD implementation catches up to the Solaris implementation. There is an upgrade command in ZFS that can upgrade the file system to the new version - but no idea how this will work in future FreeBSD versions yet.
Secondly, ZFS runs better on 64bit - so using the 32-bit i386 release is not recommended.
Thirdly, you need quite a large clump of memory - over 1GB and preferably 2GB or more. It is recommended to tune some kernel memory parameters to ensure that ZFS doesn't cause your system to panic. ZFS seems to like munching on memory in an attempt to scale.
Otherwise ZFS is really good and very stable - perfect for use in a file server.
Just don't build your file server on old 32-bit hardware, and make sure you have plenty of RAM.
You seem to know a lot about ZFS. Is it a file system suitable for use on home computers or small file servers that just let us access movies and music from any computer in the house? Or is it complete overkill in that situation and I should just stay with whatever filesystem I have at the moment.
I can't answer your original question, but for a basic file server, why not just use Linux and lvm2? It handles both snapshots and disk-redundancy without needing hardware RAID. Manifestly production stable, and scales to many terabytes of storage.
I use linux lvm fairly heavily to manage storage across a handful of FC arrays, it is quite nice. But I have to say zfs is far nicer for many reasons (better admin interface, much nicer sw raid management and capabilities, etc).
So you have not used ZFS yet? If so, you would know "why not just use Linux and lvm2?" It is just so easy and fast to add extra storage and provide data security across many different devices. For one thing, newfs is redundant.
Last I checked [opensolaris.org], you couldn't just add a device to ZFS. Instead you have to create a whole new vdev to add to the pool. So if I had a ZFS on 2 500GB drives, one data one parity, and I wanted to add another 500 gb drive so I'd have 2 data and 1 parity, I can't do that. I'd have to buy two whole 500gb drives and have 2 data and 2 parity drives. And even then, those 2 parity drives are kind of wasted being split among vdevs like that, since it would be possible for me to lose both drives in one vdev and lose
You can still run ZFS on i386, but it's not recommended. There will be a performance hit. I think the lowest you can go in the memory department is 512MB. Either way if you're not going to use recommended hardware, you will HAVE to tune ZFS in the system to cope.
I seriously doubt ZFS will destroy your data - but running it on sub-optimal hardware could potentially cause the system to kernel panic. During BETA testing, even with 2GB of RAM and a core-2 duo, I managed to get a panic without tuning anything. I th
"Does ZFS really require that much memory?" No, but if it is available it will certainly use it. The upside of ZFS using more memory is that disk IO will be lower so better overall performance.
*I love how STABLE just sticks out, like BSD wasn't stable before. Ha!*
"7-STABLE" is FreeBSD-speak for "this implements the FreeBSD 7 API/ABI, and any program you write or compile for an earlier release will work just fine on a later release". In other words, the Application Programming/Binary Interfaces won't change in incompatible ways.
This is in contrast to Linux, where updating to a new kernel (belonging to the same "stable" kernel branch, or even applying security patches) can make programs break until you recompile them.
FreeBSD hasn't wanted journaling filesystems for years, since we've had softupdates which solve many of the same problems but with half the writes. The recent gjournal plugin to the GEOM system is a block-level journal. In other words, it handles all writes to a device, whether or not the overlying filesystem supports journaling. Journaled FAT anyone?
No offence, but I found your answer somehow single sided. My experience is quite different (so is, probably, the way I'm using bsd) I am using BSD in production environments for years; almost everything I'm installing IS bsd based. I was wanting journaled filesystem since forever, just because I'm sick of fsck, and yes, linux has been a lot better on this for many many years (I also work a lot with linux). Softupdates are truly great, but they don't cover the check part.
No offence, but I found your answer somehow single sided. My experience is quite different (so is, probably, the way I'm using bsd)
None taken! Yes, our usage is probably different. I use it almost exclusively our our multipurpose servers (like a machine loaded out with a bunch of jails, each running services that use different resources so that we can max out the hardware). These tend to stay up until I reboot them for upgrades, so I don't really deal with fscks too much. That said, I'm running 7-PRERELEASE on my ancient, flaky home server that hardware-crashes at least once or twice a month. With the background fsck, I'm never
"FreeBSD hasn't wanted journaling filesystems for years, since we've had softupdates which solve many of the same problems but with half the writes."
It doesn't solve the "wait hours for fsck after unclean unmount", which has made it a dead-end for a number of years now. FreeBSD may not have wanted a solution to this problem, but lots of people have; it was a recurring topic on the FreeBSD mailing lists until ZFS support was added.
Softupdates don't solve the important unclean shutdown fsck problem very well. Background fsck is a nightmare for any production system with non-trivial amount of spinning rust.
How's that? I mean, I'd rather not have to fsck my terabyte RAIDs, but if I have to, at least the system can be running live and undegraded while the loose ends get cleaned up.
Wrong. Half the writes as compared to the naive gjournal journalling. Real modern journalling filesystems usually have the option to journal just metadata. What's more, journalling is far more flexible than softupdates. You can journal to a small battery backed RAM device for example.
If you're just journaling metadata, then you're not getting the full benefit of journaling (and definitely not anything more than softupdates offers, as it's basically an in-memory ordered journal of metadata transactions to be committed). As far as the battery-backed RAM: that's like saying cats are better than dogs because you can give them medicine if they get ringworm. BTW, with FreeBSD's GEOM system, you could journal to an encrypted RAID on a remote host if you wanted to. You might have already known that; others might not.
Wrong. There has to be some filesystem support work done.
Wrong. gjournal is a generic journaling provider. You can use it to wrap any other GEOM component. From it's own man page:
When gjournal is configured on top of gmirror or graid3 providers, it also keeps them in a consistent state, thus automatic synchronization on power failure or system crash may be disabled on those providers.
Pretty neat, huh? You can wrap it around your RAID to make it crashproof. If you think background fscks are bad, then you've probably never watched a few terabytes of mirror resync itself. Anyway, what you misunderstood is that filesystems have to be altered to interact meaningfully with the underlying journal. UFS has been so modified. That doesn't mean that other filesystems won't work on top of it (which would be silly because a gjournal looks just like any other block device), but that they're not optimized for it.
UFS+SU is still much, much faster than any Linux filesystem in real world usage. Plus moving a huge amount of data does not lock other disk-accessing processes, doing "chmod -R.." on a huge tree IME is incomparably quicker on FreeBSD (like 5-10 seconds on FreeBSD whereas on the very similar tree it virtually died for 15+ minutes on RHEL/Ext3), etc.
I also want to know what the new gjournal FreeBSD utility actually does, especially when used with UFS2.
From gjournal(8):
This is block level journaling, not file system level journaling, which means gjournal everything gets logged, e.g.: for file systems, it journals both data and metadata.
It may not be YOUR idea of open source, but it's still open source none the less. And providing it retains relevance on new hardware, it will never die.
Personally I've never used it, but after reading this thread I think I'll fire up VMware and give it a try. I come from an Ultrix & Tru64 background which were/are heavily influenced by BSD, so many of the concepts are familiar to me.
It should be fun. And isn't that what much of Open Source is all about.
Life would be so much easier if we could just look at the source code.
-- Dave Olson
Just use the default geometry (Score:5, Informative)
Re:Just use the default geometry (Score:5, Funny)
Re: (Score:2)
No need to comment (Score:5, Insightful)
Why use FreeBSD? (why not?)
FreeBSD is dead! (clearly its not)
FreeBSD is not dead!
yahoo use freeBSD (nobody cares)
FreeBSD vs Linux (ooh flame ware, but then everybody realized that it doesnt matter some people prefer FreeBSD for stability & the fact its all integrated, some people prefer linux because it has lots of flashy features & there are loads of projects to add extra features to it ( but they're not integrated and don't always play well together)!)
please go about your business there's nothing to spam about here!
Re:No need to comment (Score:5, Funny)
Re: (Score:2, Interesting)
Re: (Score:2)
Last time I checked most performance crowns were worn by solaris.
ZFS Support (Score:5, Informative)
Re:ZFS Support (Score:5, Informative)
Re:ZFS Support (Score:5, Informative)
We're using FreeBSD 7.2 RC2 ZFS in a production environment on Amd64. It's getting hammered, and holding up fine.
1) ZFS has *solved* our storage problems.
2) ZFS needs 2GB of RAM
3) You should run it on a dual core processor if you're going to use compression.
4) Research glabel so you can move drives around from cable to cable and still use the same device name.*
*more info: http://www.freebsd.org/cgi/man.cgi?query=glabel&sektion=8 [freebsd.org]
Re: (Score:3, Funny)
If you *do* have a time machine, do CPU topology detection and EFI+GPT work in 7.2? Does 8.0 have a new installer yet? Inquiring minds want to know.
Re: (Score:3, Funny)
Have a nice day.
Re:ZFS Support (Score:5, Insightful)
Re: (Score:3, Informative)
When Linux says it's experimental, that generally means it won't work for most people.
Define "work". /dev/hda to /dev/sda (and sdb, hpt366 still puts my 4 RAID chip devices as hda b c and d) went very smoothly and two kernels ago was labelled EXPERIMENTAL.
As I posted up in the thread, pata_via incorrectly detects my 80 wire cables as 40 wires, but the whole switch over from
Turning off all EXPERIMENTAL kernel options leaves you with a system that really is only good for i386, not the i686 and better.
Funnily enough, the devices connected to the HighPoint chip are using the same cables, s
Re: (Score:2)
Re: (Score:2)
Does that hold true for such things as tmpfs? I've been using that on a devel server without incident, but would like to roll it out elsewhere if it was widely thought to be stable.
Re: (Score:3, Informative)
Re: (Score:3, Funny)
Good developer interview at onlamp (Score:5, Informative)
http://www.onlamp.com/pub/a/bsd/2008/02/26/whats-new-in-freebsd-70.html?page=1 [onlamp.com]
More good summaries of kernel development (Score:5, Informative)
GREAT article - it is interesting for a non-programmer to read this type of technical detail, presented in an understandable way. For me, right at the edge of my theoretical-only knowledge. A detailed summary, I guess. (oxymoron)
Similar article on NetBSD: Waving the flag: NetBSD developers speak about version 4.0 [arstechnica.com] (1/30/2008)
Linux focused links:
Current discussion:
LWN: Kernel [lwn.net]
KernelTrap [kerneltrap.org]
KernelNewbies: Summary of Linux Changes [kernelnewbies.org]
---
The Wonderful World of Linux series are excellent history - in-depth for outsiders:
WWOL 2.2 [kniggit.net]
WWOL 2.4 [kniggit.net]
WWOL 2.6 [kniggit.net]
---
Towards Linux 2.6 - A look into the workings of the next new kernel [ibm.com](2003)
Kernel Comparison: Linux (2.6.22) versus Windows (Vista) [pbwiki.com](2007)
Any luck with HT1000 DMA yet? (Score:3, Interesting)
I have a dual-Opteron rackmount Dell with a ServerWorks HT1000 chipset, running 7.0-PRELEASE from January 15, that was having DMA-related fits. Does anyone know if they've got that problem under control yet? I had seen it discussed a lot on the mailing lists but lately haven't had the time to follow closely. Either way that server's staying on the 7-STABLE line because it's so much faster that I can live with running the drives in PIO4 (and with 4GB of RAM those drives don't get touched a lot).
Re: (Score:3, Insightful)
/mike
Re: (Score:2)
The point of asking here was that, as I mentioned in the OP, I haven't had time to read them lately. :-)
Re: (Score:2)
/Mike
Considering switching. (Score:2)
These are my requirements before I switch:
fluxbox as wm.
various KDE apps, esp. Amarok.
NFS support
Nvidia binary video drivers. so that I can play: Never Winter nights & Enemy Territory.
Can/Will FreeBSD work for me?
(I run dual Opteron 270's with 2GB of ram so SMP is important but AMD64 is not).
Re: (Score:2)
The only gotcha is that nVidia's binary drivers are just as finicky as in Linux, and you're SOL if you want to use the amd64 version of FreeBSD, unless I'm out of touch. You can find their binary driver here [nvidia.com].
Re: (Score:3, Interesting)
You should have no problems at all. It'll work perfectly.
However, is there a compelling reason for you to switch? Debian is a great operating system, and unless it's not working out too well for you, you should not just switch for no good reason. You risk being unproductive for a few days, running into issues you don't know about, etc.
Re: (Score:2)
I LOVE apt. I love the breadth of software that is available for it. But I'm a geek and I want to try something new.
How does one install new software on BSD? (do you compile everything from source?)
Or are there repos available?
Re: (Score:3, Informative)
I upgraded from 6.2 to 7.0-PRERELEASE by doing the following:
It's a convolouted process, but I wanted to follow FreeBSD 7 development. It's easier when you do it from a binary CD. Basically you restart from the CD and upgrade and it's automated.
Start by updating my system source:
$ sed -e 's/RELENG_6/RELENG_7/'
$ csup -h cvsup6.freebsd.org
Now the sou
Do it! (Score:3, Informative)
I'm still running FreeBSD 6.3 on my server, and I will upgrade to 7 soon, but I found PC-BSD to be the better desktop system (DesktopBSD had strange quirks, and wasn't as polished).
PC-BSD uses the "stable" FreeBSD as it's base, so although it's currently FreeBSD 6.3 based, that'll no doubt change to 7.0 soon. PC-BSD also uses KDE as it's desktop environment, so you'll have no trouble with your a
Re: (Score:2)
They will be upgraded/hardware replaced with 7.0 machines soon (have been waiting on 7.0 release for a few months now).
Now, why did I switch?
For me, several factors, these are the main ones...
Re: (Score:2)
Re: (Score:3, Informative)
You're probably spoiled by the package manager. Ports are neat, but apt is a dream. At the very least you'll have to get used to a different way of doing things. If you use a lot of custom repositories (e.g. rarewares [rarewares.org]) you might encounter a few headaches getting all the software you want. There are some things, like 'apt-cache search' that it's not immediately obvious how to do on ports. I think you're just supposed to string together 'find' and 'grep' commands, since ports is just a tree full of text files.
# cd /usr/ports
# make quicksearch name=whatever
An important remaining question (Score:4, Interesting)
Re: (Score:2)
I'm running FreeBSD, and the latest release of wine works just fine for most things.
Then I guess we have had markedly different wine / FreeBSD experiences. I haven't found a working combination of the two since FBSD 5.4 with a version of wine that was still numbered by its release date. Since then each successive version of wine has run fewer windows applications for me.
And as for games, I have yet to find a windows game that I can run in wine on FreeBSD at all. But obviously that's not the focus of FreeBSD anyways, so I don't hold it against either. It would certainly be nice t
Re: (Score:2)
They do truly wholeheartedly care, but the logistics of wine development make it extremely difficult to live up to a standard that shows that. It's like tapping into a market where you have little experience in. Even if you try really hard, chances are, there will be kinks that you have to work out.
FreeBSD has shown its part with a wine port and some FreeBSD users contributing to wine. Wine has shown its
Re: (Score:2)
Space Rangers 2: Rise of the Dominators (installed through Stardock Central) for one. One of the most fun games I ever played.
Re: (Score:2)
From personal experience, WoW runs on FreeBSD, but the installer won't work (or didn't on 6.2 & whatever version of wine I was using a year or so ago).
And the obligatory kudos to the FreeBSD guys for this one. I'm seriously contemplating a switch back (I'm running Ubuntu now, and am a little skittish after all the hand-wringing it took to get it to work on my laptop). There's some things I don't like about FreeBSD as far as desktop stuff goes, but the more centralized nature seems to give it more stab
SCTP (Score:2)
I believe we are actually "first" to make it part of the shipping kernel. In Linux you can enable it as a module, but there are extra steps you must take. For FreeBSD its just there, like TCP.
There's extra steps you must take? What steps are these? I haven't had experience with SCTP on any OS, but I would have thought that once the Linux module is loaded, the protocol is "just there" as well.
Maybe he's talking about kernel defaults? It's a curious statement th
Jealous of ZFS (Score:3, Interesting)
Re: (Score:2)
Re: (Score:2)
So many people misunderstand the GPL...
You can do whatever the hell you like with GPLd software, you just can't distribute it as part of a non-GPL project.
ie/ Unless it's LGPL, you can't put the CDDL (ZFS) software in the same download as Linux (GPL). You can, however, download them separately and use them like that. That's what the ZFS-FUSE project is trying to do.
One of many benchmarks to back up the announcement (Score:2)
http://people.freebsd.org/~kris/scaling/bind-pt.png [freebsd.org]
Summary:
* FreeBSD 7.0-R with 4BSD scheduler has close to ideal scaling on this test.
* The drop above 6 threads is due to limitatio
Upgrading HOWTO? (Score:3, Interesting)
And before anyone asks:
All the docs I've read on the subject tend to suggest that the Real Way to keep a FreeBSD system current is to download the kernel and userspace core every so often and recompile them. And that's fine, sorta, except that it doesn't address how to deal with the "leftovers", such as config files that have been moved or eliminated. (I mean, honestly, compiling the world is not a realistic way to keep current on X.org.)
Who has practical experience doing this? How do you keep your machines current, particularly with security patches?
Schwab
Re: (Score:2)
Re: (Score:2, Informative)
Journaled filesystems? (Score:2)
(Not trolling, I know next to nothing about *BSD)
Re:Journaled filesystems? (Score:5, Informative)
No, you read that right. The reason is mainly that FreeBSD users have been enjoying something called "softupdates" for the last decade or so, which is sort of like an in-memory journaling. Rather than writing metadata directly to disk, it's queued in memory, grouped into an efficient order, then transactionally committed to the underlying drive. The disk is never in an inconsistent state, even without a journal to fall back on. If the system crashes, a special fsck that can run while a filesystem is mounted read-write comes along and deallocates any space that's no longer used but hasn't yet been marked as empty.
Because of that, there hasn't been much need or real drive to get journaling into FreeBSD. The solution they're going with is actually nicely abstracted, in that you configure a journal for a whole device through GEOM (which is kind of like a Lego set for building drive setups). Although you'd probably never want this, you could theoretically have two "drives" that reside on remote machines (via ggate) bound together with RAID1 (via gmirror), encrypted (via geli), and with a local journal (via gjournal).
Does it work with MySQL yet? (Score:2)
with MySQL got so abysmal -- apparently the MySQL folks
and the FreeBSD folks got into pissing match about
threads.
Anyone know how this turned out?
Re: (Score:2, Informative)
http://people.freebsd.org/~kris/scaling/mysql.html [freebsd.org]
Re: (Score:2)
Here's a few links that might help you with performance in newer incarnations of FreeBSD:
FreeBSD 6 - http://wiki.freebsd.org/MySQL [freebsd.org]
FreeBSD 7 - http://people.freebsd.org/~kris/scaling/mysql.html [freebsd.org]
What *I* found in Freebsd 7.0 (Score:3, Interesting)
- I found the same sysinstall that I saw 4+years ago when I last tried installing Freebsd.
- I found that the official way to configure is to generate the config file template using 'Xorg -configure' and then hand editing the xorg.conf config file!!!!
- I found that the standard install still installs TWM and doesn't even ask for KDE/GNOME (I know you need to install the packages *after* the install, and yes I know I can use sysinstall) and you are dropped to a text login after install.
- I found that my amd64 cpu with the nvidia integrated card doesn't have an nvidia driver. And the default nv driver can't make use out of DDC to configure my brand new widescreen LCD monitor.
- I found that my mouse pointer is invisible in X.
Now, before other start, please understand why I am saying this - I know Freebsd has a different approach to building a distro. I also know that reasons like prop. drivers are not its fault. I also accept that I probably am facing some system specific issue inherent in any
My point here is simply to let how a typical user who thought of migrating to Freebsd thinks. I for one, value using my relatively new hardware to the fullest, so I am going back to Ubuntu.
I still have tremendous regards for Freebsd as a server. I have found them to be much more stable than any current Linux distro, and capable of much more punishment too.
Re: (Score:3, Informative)
What's the problem, does sysinstall not work for you? I've never had a problem with it. If you fear the sight of plain text, then FreeBSD will not be for you. While FreeBSD makes a damned awesome desktop system, that is not its goal. It is not designed for Aunt Tillie.
Re: (Score:3, Insightful)
Re: (Score:3, Interesting)
Re:Still hard to install? (Score:4, Informative)
Re:Still hard to install? (Score:4, Informative)
I had no problem using the clearly labeled "boot with USB keyboard" menu option.
It's a moot point -- with the at mux that came in I believe halfway through the 6-series, you can have as many keyboards as you feel like.
Re: (Score:3, Interesting)
Re: (Score:2)
Re: (Score:2)
From 5.4 to 7.0, K6-III + Tyan/VIA mobo -> Athlon + Abit/nForce -> Athlon64 + ASUS/nForce -> Core Solo + Toshiba/Intel.
I've used USB keyboards on all of them. The only time I don't use an PS2 Keyboard is with the Athlon, and then only when I need to edit the bios settings (no USB support for the BIOS menus? WTF?)
*shrug* milage and varying and all that.
Re:Still hard to install? (Score:5, Informative)
Re: (Score:2, Funny)
Re:Still hard to install? (Score:4, Funny)
Reminds me of a
Re: (Score:2)
As of 6.2-R, it still required no fewer than four CD-swaps (between 2 cds) since the installer can't handle "dependencies coming in the future"[0]
[0] Package A(Disc 2) depends on Package B(Disc 1) which depends on Package C(disc 2). Instead of installing Package B on the first run through, knowing the other two will be coming, it will ask you to swap back and forth.
I love my freeBSD, but installing it has gotten really painful.
Re: (Score:2)
The only exception is if im building a base server, i have my favorite set of packages that i keep on a separate cd and install them after a minimal install.
Re: (Score:2)
Kind of obnoxious. As I said, I still use it, I just really wish they'd consider this the problem that it is.
Re: (Score:2)
You don't need to figure out the disk geometry if you use the guided installer. I usually like to set that myself anyways, I find it funny you want it compared to Ubuntu, Ubuntu almost wants to hold me back from setting up my disk exactly how i want it. As far as how easy the installer is, if you can install a Slackware system its pretty similar, same solid color menus and package selection(if you do
Re:Still hard to install? (Score:4, Insightful)
I'd gladly give it a go.
I refuse to willingly evaluate it without preconceived prejudice.
Re: (Score:2, Redundant)
Re:Still hard to install? (Score:5, Informative)
Press "A" for auto partitioning and then "A" in the disk layout section for auto-defaults.
As it has been since at least FreeBSD 4.0.
Re: (Score:2)
Whether FreeBSD is too hard to install or not comes down far more to tolerance for ncurses style programs. I personally grew up on them with dos and early windows versions.
Which reminds me that I've got to download a copy of DesktopBSD to try out.
Re: (Score:2)
Re:Still hard to install? (Score:5, Informative)
http://www.pcbsd.org/ [pcbsd.org]
http://www.desktopbsd.net/ [desktopbsd.net]
Disk Geometry trolling isn't funny or have you confused this with partitioning. So, are you trolling or are you stating that you don't like to partition drives. If it is partitioning then you may want to check out the above links; if you're trolling, then continue with what you're doing
Re:Still hard to install? (Score:5, Informative)
I've been using FreeBSD since version 2.2.7. I've been using Linux and other OSs even longer. Operating systems that have been around as long as these weren't just created from the start to be a breeze to install. Linux used to require a lot more manual configuration than it does now... just because something like Ubuntu makes it easy doesn't mean it always was. Linux has progressed in this area, and so has FreeBSD, and so have most other mature operating systems.
Also, FreeBSD is not targeted at the same audience as something like Ubuntu. A better comparison would be PC-BSD and Ubuntu, as they are targeted at desktop users. I guess maybe FreeBSD could be compared to the server or alternate editions of Ubuntu, in which case the install process (using text screens) is fairly similar.
Re: (Score:3, Interesting)
Re: (Score:2)
Were you using nm-applet and the keyring? I've never had a problem doing it like that.
Re:Performance is really lacking (Score:5, Insightful)
Re:ZFS? (Score:5, Informative)
Solaris still offers better support, but the ZFS support offered by FreeBSD is production quality.
Re: (Score:2, Informative)
http://wiki.freebsd.org/ZFSKnownProblems [freebsd.org]
The "this is experimental" tag should remain until all of the issues on the ZFSKnownProblems page are addressed.
Re:ZFS? (Score:5, Interesting)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:3, Informative)
Re: (Score:2)
Last I checked [opensolaris.org], you couldn't just add a device to ZFS. Instead you have to create a whole new vdev to add to the pool. So if I had a ZFS on 2 500GB drives, one data one parity, and I wanted to add another 500 gb drive so I'd have 2 data and 1 parity, I can't do that. I'd have to buy two whole 500gb drives and have 2 data and 2 parity drives. And even then, those 2 parity drives are kind of wasted being split among vdevs like that, since it would be possible for me to lose both drives in one vdev and lose
Re: (Score:2)
I think the lowest you can go in the memory department is 512MB.
Either way if you're not going to use recommended hardware, you will HAVE to tune ZFS in the system to cope.
I seriously doubt ZFS will destroy your data - but running it on sub-optimal hardware could potentially cause the system to kernel panic.
During BETA testing, even with 2GB of RAM and a core-2 duo, I managed to get a panic without tuning anything. I th
Re: (Score:2)
Well, 7 or 8 people plus the few million people who have bought generic Dell boxes (or anything nicer) in the last year or so.
Re:ZFS? (Score:4, Informative)
No, but if it is available it will certainly use it. The upside of ZFS using more memory is that disk IO will be lower so better overall performance.
Re:STABLE (Score:5, Informative)
"7-STABLE" is FreeBSD-speak for "this implements the FreeBSD 7 API/ABI, and any program you write or compile for an earlier release will work just fine on a later release". In other words, the Application Programming/Binary Interfaces won't change in incompatible ways.
This is in contrast to Linux, where updating to a new kernel (belonging to the same "stable" kernel branch, or even applying security patches) can make programs break until you recompile them.
Re:STABLE (Score:5, Interesting)
FreeBSD hasn't wanted journaling filesystems for years, since we've had softupdates which solve many of the same problems but with half the writes. The recent gjournal plugin to the GEOM system is a block-level journal. In other words, it handles all writes to a device, whether or not the overlying filesystem supports journaling. Journaled FAT anyone?
I just said journal a lot, didn't I?
Re: (Score:2)
I am using BSD in production environments for years; almost everything I'm installing IS bsd based. I was wanting journaled filesystem since forever, just because I'm sick of fsck, and yes, linux has been a lot better on this for many many years (I also work a lot with linux). Softupdates are truly great, but they don't cover the check part.
The block level journal with GEOM work
Re: (Score:2)
No offence, but I found your answer somehow single sided. My experience is quite different (so is, probably, the way I'm using bsd)
None taken! Yes, our usage is probably different. I use it almost exclusively our our multipurpose servers (like a machine loaded out with a bunch of jails, each running services that use different resources so that we can max out the hardware). These tend to stay up until I reboot them for upgrades, so I don't really deal with fscks too much. That said, I'm running 7-PRERELEASE on my ancient, flaky home server that hardware-crashes at least once or twice a month. With the background fsck, I'm never
Re: (Score:2)
It doesn't solve the "wait hours for fsck after unclean unmount", which has made it a dead-end for a number of years now. FreeBSD may not have wanted a solution to this problem, but lots of people have; it was a recurring topic on the FreeBSD mailing lists until ZFS support was added.
Re: (Score:2)
That's like saying they didn't wantsmp support for all that time they didn't have it...
Re:STABLE (Score:4, Informative)
You underestimate my capacity for wrongness.
How's that? I mean, I'd rather not have to fsck my terabyte RAIDs, but if I have to, at least the system can be running live and undegraded while the loose ends get cleaned up.
If you're just journaling metadata, then you're not getting the full benefit of journaling (and definitely not anything more than softupdates offers, as it's basically an in-memory ordered journal of metadata transactions to be committed). As far as the battery-backed RAM: that's like saying cats are better than dogs because you can give them medicine if they get ringworm. BTW, with FreeBSD's GEOM system, you could journal to an encrypted RAID on a remote host if you wanted to. You might have already known that; others might not.
Wrong. gjournal is a generic journaling provider. You can use it to wrap any other GEOM component. From it's own man page:
Pretty neat, huh? You can wrap it around your RAID to make it crashproof. If you think background fscks are bad, then you've probably never watched a few terabytes of mirror resync itself. Anyway, what you misunderstood is that filesystems have to be altered to interact meaningfully with the underlying journal. UFS has been so modified. That doesn't mean that other filesystems won't work on top of it (which would be silly because a gjournal looks just like any other block device), but that they're not optimized for it.
Re: (Score:2)
Re: (Score:2)
From gjournal(8):
Re: (Score:3, Informative)
Re: (Score:2)
Re: (Score:2)
It may not be YOUR idea of open source, but it's still open source none the less. And providing it retains relevance on new hardware, it will never die.
Personally I've never used it, but after reading this thread I think I'll fire up VMware and give it a try. I come from an Ultrix & Tru64 background which were/are heavily influenced by BSD, so many of the concepts are familiar to me.
It should be fun. And isn't that what much of Open Source is all about.