[geeks] OS testing, dragonfly

[Shannon]

I spent a good bit of yesterday and early this morning testing DragonFly BSD.

Its impressive so far.

In terms of just being an OS, its nothing all that special, since it feels a
whole lot like NetBSD and FreeBSD. Since the fork it seems to have headed more
toward NetBSD in overall feel and uses pkgsrc.

Matt Dillon said he wants to have a custom package system however, because
current applications are just out of control with dependencies. What he
described as a future goal sounds pretty nice, a bit more like the control
offered by doing it yourself or using gentoo.

But for now its pkgsrc and it works fine.

I'm running the test machine on my Mac Pro under VMWare, and performance is a
lot better than some reviews indicated, to the point where I find it hard to
believe they were being accurate.

The following is just collected notes so far:

Installation: One of the easiest installs I have ever seen. Boot CD, login as
"installer", and you have an OS about 5 minutes later. It has sane defaults
and comes with enough software to get up and running. Unlike NetBSD, it
actually has a valid repository configuration from the start so you can add
packages without having to figure that out.

sshd: by default it requires crypto keys to login. The secure-by-default is a
good idea. My only complaint is that it takes sshd several seconds to respond
to a login. No idea why.

SMP: There are no easy ways to verify SMP is working. From dmesg output it
appears that dfly is not seeing both of my CPUs. I may have to build a kernel
for that, not sure. AMD64 support is newer than the 32-bit stuff.

Hammer filesystem: This is really nice. Continuous streaming master/slave
filesystems, cluster filesystem abilities (share FS between machines),
continuous snapshot/history system (tunable and can be disabled), automatic
deduplication, etc. It is not yet up to ZFS abilities... but it is leaner and
has some abilities that ZFS lacks, and it seems to not be so sensitive to
hardware issues. It does do CRC checking of data, but some data requests which
are answered from buffercache are not verified every time. So it does check
for errors, but not on every single access like ZFS. There is a goal to add
this and the base support is there, it just the support code to be written.

One interesting thing is that DragonFly is being heavily geared toward
parallel computation and clustered operations. The basic parts of single-image
OS have been created and the goal is a single unified DragonFly instance over
multiple machines all sharing a single hammer filesystem. That's pretty
interesting even for some home and hobby projects, and certainly good for
various business operations.

One thing to get used to with hammer filesystems is that they keep continuous
track of all changes in streaming snapshots, much like a WORM drive. This is
tunable and can be disabled, but at first it looks alarming. Your filesystem
fills up as you add and change files so you have to keep that in mind when
deciding which filesystems to keep history with and which to disable. Its very
nice to change a file and then do something like "vi /filesystem/file at 2311" to
edit the version you did at 11:11pm.

Common practice is to use pseudofilesystems which are filesystems you create
inside a hammer filesystem, which have their own inodes and btree, and you put
them where you want with a nullfs mount. This is a lot like the ZFS
filesystems added to pools, but I find it more intuitive.

Like ZFS it has mirroring abilities, but they go further. For one thing, you
can make master/slave mirror setups on one machine or across machines
automatic. Every change you make to the master gets mirrored on the slave,
whether it is on the same machine, in the same room, or 3000 miles away in
another country. At any time you can turn a slave into an independent master,
so it makes things like manual failover fairly easy, and obviously paves the
way to some sophisticated clustering and automated failover environments.

The mirroring ability in a lot of ways can do a lot of what you normally use
virtual servers for: easy migration during upgrades and failures. Its making
me think about just running a single instance OS rather than do
virtualization.

Virtualization: There are plans to make a virtual server support in DragonFly,
but different from Xen or KVM. It will probably be related to the clustering
efforts. Some people are messing with Xen but I get the feeling its "not quite
there" yet.

Interesting scenario: use a Linux KVM system to host several copies of
DragonFly, which can share common filesystems. Lot of potential for fun
there.




--
Shannon Hendrix
shannon at widomaker.com