Slashdot Mirror

At some point, the data on any writable disk is inconsistent, even with a journal system.

ZFS is copy-on-write, ie. it is not a journaled filesystem. It is transaction-based and atomic; it does not traverse an inconsistent state because it does not overwrite the data during a write.

but data can be lost, simply because data that hasn't been written to disk yet can't be if power is lost.

Right, no doubt you have deduced I am making a distinction between data inconsistency (corruption) and "lost writes". Note that because ZFS is a "rampant layering violation", lost writes cannot cause inconsistency/corruption of the filesystem itself (except in degenerate scenario 2 below).

The primary data "loss" scenarios for ZFS during power loss are:

1) File writes that haven't been flushed yet. Note that this does not lead to filesystem inconsistency, just lost writes. A battery-backed write cache won't fix this—if this scenario is a concern, then you really need a UPS for the machine and an orderly shutdown. That is to say, if pending asynchronous writes being flushed is a concern then you're probably also concerned about currently-executing application processes that may not be complete.

2) Hardware that lies/breaks spec and acks a synchronize-cache command when it hasn't really done so. This causes much rage in the ZFS developers, because there's no true fix for it besides suggest people not use substandard hardware. Note that this *can* cause ZFS to lose data. Would this scenario corrupt a system with battery-backed RAID write cache as well? The drive fraudulently swears it has flushed the data... would the controller double-check later by reading the data back in just to see if it was lying? Even if the controller did try to check, how would it know that the drive wasn't responding from its own cache?

This is where battery-backed cache can help, as the OS thinks it has been written, but it hasn't yet.

I presume you are referring to enabling write caching on your controller, and asserting it is safe to do so due to the battery-backed cache.

I specced an IBM System x3650 M3 with a similar system for a production PostgreSQL server. God, I loved that machine... you could even make a 96 core/1 TB RAM Voltron-like single logical machine by plugging four of them together. Anyway, the intention of the cache was to be able to safely disable fsync() in PG without risk of data corruption. The IBM system took it one step further: the battery-backed cache had the ability to be transferred to another x3650 and replay the cache on the other machine in case of catastrophic failure. Anyway, I never bothered to enable the feature because we never became I/O bound on writes with fsync() enabled while I was there. It did give us headroom, though.

Anyway, the obvious perf advantage is to allow the hardware to lie and assert sync has happened even though it hasn't yet.

On my home ZFS array I have a allocated part of my OCZ Vertex 4 SSD for my RAID zpool's ZIL, which serves a similar acceleration function for synchronous writes (only). The ZIL acts like a protected write cache, but only in the case of power failure. Essentially, the in-RAM ZFS pending write cache is mirrored to the ZIL device(s) (if you have them). If the ZIL device acks a sync of the ZFS cache data written to it, then ZFS counts the overall write to the destination volume as complete (because the transactions are now replayable if power is lost) and therefore allows the OS sync() to return.

Also note that I misspoke, because the Adaptec 5805Z that I have uses a capacitor, not a battery.

By design, the ZIL is never read unless there is a power-failure. The Vertex 4 is supposed to have supercaps to ensure flush, but given

And, for a view somewhat less harsh about C++, but still not a case of "C++ roolz, C droolz!", see The Old Man and the C, the abstract of which says

"You can't teach an old dog new tricks" goes the old proverb. This is a story about a pack of old dogs (C programmers) and their odyssey of trying to learn new tricks (C++ programming).

It is a good story and a good experience, but I certainly and strongly disagree with the following:

We never gave consts much thought. Looking back we do not recall any situations in which consts would have saved us. Still, they seem like a reasonable feature, especially in interfaces to class libraries. If an interface rigorously uses consts in its declarations, then users can know which parameters may be modified by which routines. This looks like another feature which is more valuable when producing a public API.

There is a reason why modern languages typically default-qualify parameters and attributes as const (and/or const ref). Having everything const by default makes life a shitload easier for software of any size.

From: Linus Torvalds Subject: Re: [RFC] Convert builin-mailinfo.c to use The Better String Library. Newsgroups: gmane.comp.version-control.git Date: 2007-09-06 17:50:28 GMT (2 years, 14 weeks, 16 hours and 36 minutes ago) ... In other words, the only way to do good, efficient, and system-level and portable C++ ends up to limit yourself to all the things that are basically available in C. And limiting your project to C means that people don't screw that up, and also means that you get a lot of programmers that do actually understand low-level issues and don't screw things up with any idiotic "object model" crap.

And, for a view somewhat less harsh about C++, but still not a case of "C++ roolz, C droolz!", see The Old Man and the C, the abstract of which says

"You can't teach an old dog new tricks" goes the old proverb. This is a story about a pack of old dogs (C programmers) and their odyssey of trying to learn new tricks (C++ programming).

C++ is a large, complex language which can easily be abused, but also includes many features to help programmers more quickly write higher quality code. The TeamWare group consciously decided which C++ features to use and, just as importantly, which features not to use. We also incrementally adopted those features we chose to use. This resulted in a successful C++ experience.

If the LZO folks had an easy way to purchase a license to their products (purchase online with credit card), they would have a little more money in their pockets.. Instead, they get a tiny bit of publicity.. and anyone who cares will simply use a free (as in MIT/BSD) library, such as FastLZ or LZJB, 7-Zip.

I just looked at this article as my employer uses Debian and Ubuntu heavily and I've been pushing for ZFS on our file servers. There is no mention of ZFS version, the feature set available, or even a link to the source material.

ZoL is based on ZFS version 28 from the last open Solaris release, and currently integrating Illumos as its upstream.

There isn't much mention of how to use ZFS. I happen to know most commands, but I think this article would be difficult for a beginner even though it seems to be targeted at that demographic.

It looks like the Slashdot editors are doing this blogger a favor by linking to a mostly empty article.

At a minimum, this article should link to the ZoL home page, the ZoL Launchpad page for packages, and maybe the ZFS introduction or another tutorial.

.
Both FreeBSD and FreeNAS, in addition to OpenSolaris, support ZFS.

Again, not true. You cannot 'just use the xen 4.1 hypervisor'. You seem to be completely ignorant of how much work there is in adding dom0 support in a kernel which is fortunate for you only. And the last opensolaris in august 2010 did not have dom0 and nor does openindiana. [1][2][3]

[1] https://www.illumos.org/boards/1/topics/561
[2] http://wiki.openindiana.org/oi/7.+Virtualization
[3] http://opensolaris.org/jive/thread.jspa?threadID=134657

This certainly happened to ATI; but I don't think ZFS was cut for the same reason. It was never "leaked" that Apple would use ZFS, just rumored, since they had a working alpha version (well, they called it a beta, but it was nowhere near beta quality - at least for the reliability one expects for a file system). It was publicly known that Apple was working on it in April 2006. The beta worked on 10.5.0, released in October 2007 - I even used it myself that fall for an Operating Systems project in school. Apple themselves announced that it would be available in 10.6 Server in about February 2009. However, references were later removed, and the project was publicly canned in October 2009, about 2 months after 10.6 was released. Ars Technica blames it on either licensing issues, or possibly Oracle's acquisition of Sun. A Sun employee more-or-less confirmed.

But yes, if there's a drop-in replacement for whatever Sony's making that's reasonably similar, or if the design process is early enough (eg if the iPhone 5 is coming out in fall, not summer, as has been rumored), then Sony probably won't be in it. And either way, they probably won't be in the next one, either. After that, it's anybody's guess; it takes Apple a year or two to cool off after a leak like that, typically.

Though it is possible that they'll ignore it; they didn't say anything about the phone itself, other than the camera resolution. (Granted, ATI didn't say anything except that there'd be new PowerMacs in a couple days either...)

It's sorta sad you and others like you assume the ZFS corruption on FreeBSD is somehow FreeBSD's fault. I can provide examples of how ZFS pools/ZIL's can be corrupted regardless of the OS it's running under. (Hint: Lying hardware is to blame so it's neither OS or file system's responsibility)

http://mail.opensolaris.org/pipermail/zfs-discuss/2010-January/035740.html -- After digging into a few ZFS corruption complaints on FreeBSD, this type of error seems to be the most common one.

Can you demonstrate a scenario where FreeBSD is the cause of ZFS corruption?

Version 15 of ZFS seems to have a better support for quotas and other accounting stuff: http://hub.opensolaris.org/bin/view/Community+Group+zfs/15

Almost forgot..

Here's the info page on OpenSolaris

http://hub.opensolaris.org/bin/view/Community+Group+brandz/linux_2_6

You can follow pretty closely - ignoring the guide about creating your own image since you'll be using an openvz image. The rest is relevant. .. Just remember they're removing lx support in the newest versions =(

Also I think the /etc/resolv.conf file doesn't exist after setting up the zone.. So you'll need to create one to do anything practical online.

lx2.6 (Linux kernel 2.6 support) is considered experimental. It runs fine for me and a couple others that I know, but cannot say if it will work for you. There are certain things that WILL NOT work. Your best bet is to just try it.

Mind you these zones I run aren't heavily utilized, but I do know hash checking torrents doesn't give the CPU a break. It's nice seeing each process in a zone show up in my main OpenSolaris "top" process tree.

Check out this forum: http://opensolaris.org/jive/thread.jspa?messageID=466361&tstart=0 read "jwhitby3"'s post on using the openvz image.

The posts are from early October, and b131 wasn't even out then. jwhitby3 is reportedly using 2009.06.. So build 111b or so.

First login, you'll need to use zlogin -S to change the root pass. After that, it should run beautifully... Just probably not a good idea to run it in a true production environment.

Yes

Frankly, at this point, I don't care whether Oracle finally releases ZFS in a Linux-compatible license. (Although they might, in order to shoehorn it into Unbreakable Linux(tm) that they use. Which I think is the biggest chance that we'll see ZFS in Linux.)

ZFS has been around long enough now that the flaws are known. It's not the end-all be-all of file systems and storage. And some of the flaws are pretty nasty (can't shrink a zpool, which they've been "working" on a fix since 2007 for that).

And the flexibility of layers where RAID is separate from LVM which is separate from the file system offers other advantages. And headaches... but I do prefer the flexibility of keeping the layers more separate then ZFS does. Checksumming of data is pretty smexy though and I would like to see more of that to guard against bitrot.

ZFS is nice but it doesn't have an fsck, partly because of its design philosophy. I think this is an omission and http://www.osnews.com/story/22423/Should_ZFS_Have_a_fsck_Tool_ explains why (links to many examples where ZFS won't open a zpool after an abrupt shutdown, possibly due to ZFS bugs or disks that lie about flushing cache to disk).

There is a new zpool recovery feature - discussed in http://www.c0t0d0s0.org/archives/6071-No,-ZFS-really-doesnt-need-a-fsck.html - the command is "zpool clear -F data" which is a very specific sort of fsck - it just unwinds the last few transactions, enabling you to have a valid zpool but losing a few recent updates, which is usually better than a complete restore from backups. The feature is mentioned at http://www.c0t0d0s0.org/archives/6067-PSARC-2009479-zpool-recovery-a.html (PSARC 2009/479) and is available since Opensolaris build b128 (ref: http://opensolaris.org/jive/thread.jspa?threadID=127689&tstart=0 )

For those who want a ZFS based NAS, have a look at NexentaStor (which has a proprietary GUI, free for up to 12 TB of disk) or Nexenta Core (just the OS without GUI, and open source) - NexentaStore has some nice features to get you started quickly, or you can use the open source napp.it GUI with the Nexenta Core. Nexenta uses a very recent zpool version (v24) and is based on OpenSolaris build b134 so it includes the above zpool reocvery feature.

Nexenta generally will move to using the Illumos fork of OpenSolaris when that's stable, so it should have a future as long as NetApp don't sue them. If they do get sued you could move to a more community-based distro based on Illumos.

Key question is whether the ZFS on Linux port will be updated to the Solaris b134 code to include this feature. Without it, you are in for some painful recovery using zdb (filesystem debugger) - but in any case you need up to date backups of your entire zpool. FreeBSD does have ZFS but using a much older zpool version without this feature - from my point of view, it's best to use the latest Solaris ZFS code to get the best stability, despite the limitations of Solaris hardware support.

ZFS recovery is an interesting topic given commodity hardware - see http://opensolaris.org/jive/message.jspa?messageID=292794 - there are other failure modes not addressed buy this zpool recovery feature.

ZFS is nice but it doesn't have an fsck, partly because of its design philosophy. I think this is an omission and http://www.osnews.com/story/22423/Should_ZFS_Have_a_fsck_Tool_ explains why (links to many examples where ZFS won't open a zpool after an abrupt shutdown, possibly due to ZFS bugs or disks that lie about flushing cache to disk).

There is a new zpool recovery feature - discussed in http://www.c0t0d0s0.org/archives/6071-No,-ZFS-really-doesnt-need-a-fsck.html - the command is "zpool clear -F data" which is a very specific sort of fsck - it just unwinds the last few transactions, enabling you to have a valid zpool but losing a few recent updates, which is usually better than a complete restore from backups. The feature is mentioned at http://www.c0t0d0s0.org/archives/6067-PSARC-2009479-zpool-recovery-a.html (PSARC 2009/479) and is available since Opensolaris build b128 (ref: http://opensolaris.org/jive/thread.jspa?threadID=127689&tstart=0 )

For those who want a ZFS based NAS, have a look at NexentaStor (which has a proprietary GUI, free for up to 12 TB of disk) or Nexenta Core (just the OS without GUI, and open source) - NexentaStore has some nice features to get you started quickly, or you can use the open source napp.it GUI with the Nexenta Core. Nexenta uses a very recent zpool version (v24) and is based on OpenSolaris build b134 so it includes the above zpool reocvery feature.

Nexenta generally will move to using the Illumos fork of OpenSolaris when that's stable, so it should have a future as long as NetApp don't sue them. If they do get sued you could move to a more community-based distro based on Illumos.

Key question is whether the ZFS on Linux port will be updated to the Solaris b134 code to include this feature. Without it, you are in for some painful recovery using zdb (filesystem debugger) - but in any case you need up to date backups of your entire zpool. FreeBSD does have ZFS but using a much older zpool version without this feature - from my point of view, it's best to use the latest Solaris ZFS code to get the best stability, despite the limitations of Solaris hardware support.

ZFS recovery is an interesting topic given commodity hardware - see http://opensolaris.org/jive/message.jspa?messageID=292794 - there are other failure modes not addressed buy this zpool recovery feature.

OpenSolaris ZFS Screencast: 100 Mirrored Filesystems in 5 minutes

OpenSolaris Screencast: ZFS Self Healing

Oracle Demo: ZFS Discovery Day

Presentation: (PDF) ZFS: The Last Word in File Systems (2008)

Presentation (VIDEO) ZFS: The Last Word in File Systems" (2008)

Nexenta 3.0 webinar (Slide 18, Deduplication)

Sun ZFS drive destruction Demo

OpenSolaris ZFS Screencast: 100 Mirrored Filesystems in 5 minutes

OpenSolaris Screencast: ZFS Self Healing

Oracle Demo: ZFS Discovery Day

Presentation: (PDF) ZFS: The Last Word in File Systems (2008)

Presentation (VIDEO) ZFS: The Last Word in File Systems" (2008)

Nexenta 3.0 webinar (Slide 18, Deduplication)

Sun ZFS drive destruction Demo

OpenSolaris ZFS Screencast: 100 Mirrored Filesystems in 5 minutes

OpenSolaris Screencast: ZFS Self Healing

Oracle Demo: ZFS Discovery Day

Presentation: (PDF) ZFS: The Last Word in File Systems (2008)

Presentation (VIDEO) ZFS: The Last Word in File Systems" (2008)

Nexenta 3.0 webinar (Slide 18, Deduplication)

Sun ZFS drive destruction Demo

http://www.opensolaris.org/jive/thread.jspa?threadID=131604
http://www.opensolaris.org/jive/thread.jspa?messageID=270957

Long story short: disk pools in ZFS can only grow, so don't make any mistakes unless you can afford to do a full dump and restore. Sun had been "working on" this for years. Anyone heard any news lately?

http://www.opensolaris.org/jive/thread.jspa?threadID=131604
http://www.opensolaris.org/jive/thread.jspa?messageID=270957

Long story short: disk pools in ZFS can only grow, so don't make any mistakes unless you can afford to do a full dump and restore. Sun had been "working on" this for years. Anyone heard any news lately?

ZFS is used in production on FreeBSD by some people and I generally like the ZFS features, but I don't view ZFS as really production ready on any OS.

This is because ZFS on any OS does sometimes lose all access to the zpool (i.e. you lose the entire set of RAID volumes and filesystems on them, all at once) due to ZFS bugs, and there is no fsck. I can't think of another filesystem where you can (a) lose all access to your files and (b) there is no fsck. Same goes for RAID - even if you use RAID-1 with ZFS you can still lose your entire zpool due to a ZFS bug.

Given that the "no data loss by design" (can't find the reference for this, perhaps Sun/Oracle has stopped saying this) hasn't really worked out for ZFS on Solaris or FreeBSD, there is still a need to have a complete backup of any ZFS zpool (as with any other RAID / filesystem). The checksumming, COW, snapshots, and self-healing data (for RAID) are very nice, but losing your whole pool due to a ZFS bug means it isn't really a high availability solution. On the plus side, it does make it very easy to snapshot in order to take a backup, and makes incremental backups easy with zfs send.

Here are a few samples of complete zpool loss:

http://opensolaris.org/jive/thread.jspa?threadID=132089&tstart=120

http://superuser.com/posts/130822/revisions - FreeBSD

http://www.mail-archive.com/zfs-discuss@opensolaris.org/msg39578.html

My point is not that ZFS is a bad idea, but it really needs an fsck (see http://www.osnews.com/story/22423/Should_ZFS_Have_a_fsck_Tool_ ) and anyone using ZFS must have full backups onto another server of the whole zpool, perhaps into a non-ZFS filesystem to avoid software bugs that hit both the main and backup zpool. The need for backups isn't unique to ZFS but I haven't seen other filesystems/RAID implementations promising "no data loss by design"

http://breden.org.uk/2009/05/01/home-fileserver-a-year-in-zfs/ has some good info on using ZFS for a home NAS, with a separate backup server also using ZFS.

btrfs isn't mature yet, but its designer has said he will always make fsck a priority over new features: http://lkml.indiana.edu/hypermail/linux/kernel/0706.2/1284.html

> Solaris Zones is an example of operating system virtualisation. There is no direct equivalent on Linux.
You should check out VServers before you bet your house on that.

Not a direct equivalent. OpenSolaris has a FAQ on this:

http://hub.opensolaris.org/bin/view/Community+Group+zones/faq#HQArecontainerslikeLinuxvServers

Something or other is keeping them from allowing sparse roots, I imagine this has something to do with the new packaging system. As I recall, someone has gotten the inherit-pkg-dir properties to be allowed, and the resulting zone worked fine. I became curious when they didn't mention upgrade-ability, but then I became distracted and/or hungry and thought nothing more on the subject. This bug supports the pkg root cause though: http://defect.opensolaris.org/bz/show_bug.cgi?id=2550

Development on OpenSolaris has all but stopped

Except it hasn't?

I mean biweekly, binary development builds haven't been released since 134 in March, but development clearly marches on.
http://hub.opensolaris.org/bin/view/Main/
http://opensolaris.org/jive/thread.jspa?threadID=125446&tstart=0
http://cr.opensolaris.org/
http://hub.opensolaris.org/bin/view/Main/RecentChanges
Think for yourselves..

Community (outside Oracle) development may have been frozen, and it might be worthwhile to have a liberal, free spirited fork to try new things, but if Oracle wanted OpenSolaris dead, there's a very fast an efficient way of doing that, and they have not. Don't call something dead unless you're pretty darned sure it aint going to wake up the next morning.

Development on OpenSolaris has all but stopped

Except it hasn't?

I mean biweekly, binary development builds haven't been released since 134 in March, but development clearly marches on.
http://hub.opensolaris.org/bin/view/Main/
http://opensolaris.org/jive/thread.jspa?threadID=125446&tstart=0
http://cr.opensolaris.org/
http://hub.opensolaris.org/bin/view/Main/RecentChanges
Think for yourselves..

Community (outside Oracle) development may have been frozen, and it might be worthwhile to have a liberal, free spirited fork to try new things, but if Oracle wanted OpenSolaris dead, there's a very fast an efficient way of doing that, and they have not. Don't call something dead unless you're pretty darned sure it aint going to wake up the next morning.

Development on OpenSolaris has all but stopped

Except it hasn't?

I mean biweekly, binary development builds haven't been released since 134 in March, but development clearly marches on.
http://hub.opensolaris.org/bin/view/Main/
http://opensolaris.org/jive/thread.jspa?threadID=125446&tstart=0
http://cr.opensolaris.org/
http://hub.opensolaris.org/bin/view/Main/RecentChanges
Think for yourselves..

Community (outside Oracle) development may have been frozen, and it might be worthwhile to have a liberal, free spirited fork to try new things, but if Oracle wanted OpenSolaris dead, there's a very fast an efficient way of doing that, and they have not. Don't call something dead unless you're pretty darned sure it aint going to wake up the next morning.

Development on OpenSolaris has all but stopped

Except it hasn't?

I mean biweekly, binary development builds haven't been released since 134 in March, but development clearly marches on.
http://hub.opensolaris.org/bin/view/Main/
http://opensolaris.org/jive/thread.jspa?threadID=125446&tstart=0
http://cr.opensolaris.org/
http://hub.opensolaris.org/bin/view/Main/RecentChanges
Think for yourselves..

Community (outside Oracle) development may have been frozen, and it might be worthwhile to have a liberal, free spirited fork to try new things, but if Oracle wanted OpenSolaris dead, there's a very fast an efficient way of doing that, and they have not. Don't call something dead unless you're pretty darned sure it aint going to wake up the next morning.

If they treat any of them like they've treated OpenSolaris, then I'd say they would die a slow death.

At this point, the last release was June 2009. Development has stopped being exposed to the outside world, we were expecting a May release, and we're going on August now. There still has not been official announcement by Oracle on this topic either.

While OpenSolaris is not a true open source product, it has been mistreated since the Oracle take over. It is unclear why there has been nothing said on it, but I'd rather take a project death at this point than this continued silence. Several key people have left to move onto other projects as well, though others are saying that development is still continuing. And worst of all, it would be a pain in the ass to fork because of their particular license design choice.

The forums have been rather full of people complaining about it as well. Especially after the OpenSolaris board has threatened to kill itself off if Oracle doesn't make some key decisions.

Just bad news all around. And it would be so easy to fix too, just by giving us an official statement on it's future.

See the second post in the recent thread on zfs-discuss: Legality and the future of zfs...

It doesn't sound as if Netapp has a leg to stand on, so they are trying to shake down the companies while they can. Where have we seen this before?

Not sure what happened to the second link... Anyway, the terrible story of my struggles with OpenSolaris can be found here.

ZFS is buggy and unreliable:

http://www.mouldy.org/zfs-the-final-straw
http://opensolaris.org/jive/thread.jspa?messageID=473421&tstart=0
http://mail.opensolaris.org/pipermail/zfs-discuss/2008-January/016042.html
http://forums.freebsd.org/showthread.php?t=7682
http://markmail.org/message/4prch5ydto6nxquf

I'm interested in Tux3 and (particularly) Hammer though.

http://www.ntecs.de/blog/articles/2008/01/17/zfs-vs-hammerfs/

ZFS is buggy and unreliable:

http://www.mouldy.org/zfs-the-final-straw
http://opensolaris.org/jive/thread.jspa?messageID=473421&tstart=0
http://mail.opensolaris.org/pipermail/zfs-discuss/2008-January/016042.html
http://forums.freebsd.org/showthread.php?t=7682
http://markmail.org/message/4prch5ydto6nxquf

I'm interested in Tux3 and (particularly) Hammer though.

http://www.ntecs.de/blog/articles/2008/01/17/zfs-vs-hammerfs/

"(The following message is wholly my own, and doesn't represent anything from Oracle. While I'm an Oracle employee, I have no special privileged information or insight beyond what is already common knowledge.)"

This could be a random guy stirring the pot. What do we have to actually think management might ditch opensolaris?

Care to provide a link to some details of those components essential to running OpenSolaris but which are not open source?

Libc for example, I see code here for it
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/
Or is that not complete code for libc?

And if you read http://hub.opensolaris.org/bin/view/Main/no_source , which is the ACTUAL list of non-source-available components, you'll only see "libc_i18n" listed. Not libc.

For GPL works you take a distro, file off the serial numbers somebody else was using (usually this is just trademark logos and such), stamp your name on it, and it's DeadPixelOS. Of course, DeadPixelOS isn't going to get much of a following unless you're continuously developing some value-add as well as keeping up with the patch management of 1000+ packages. It's some work. For your first clone distro I'd start with a low-maintenance one like Pentoo.

The line is drawn in the license. For OpenSolaris, that would be here. If the license says you can do what you want with the code, then you can. If it says you can't, then you can't. And if it doesn't say, then it's all about how good your lawyer is and how much you want it.

http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/

rly?

Development still hasn't been opened and there is no public repository development model.

ON sources (i.e. the base sources + kernel, something like FreeBSD's /usr/src tree) are under Mercurial though, and one can easily clone the repository. So they're moving in the right direction.

During a co-op job I worked on a very large multi-platform app (several million lines of code)

the team had an LXR setup to do project wide searching, however it was aging and having problems, and is a bit difficult to work with.
As a side project intended for a report once I was back on campus, I set up OpenGrok, which worked brilliantly, and was reasonably easy to configure, and nicer to use once we got it setup. The team liked it enough that they switched to that permanently.
both are open source, and were built to handle large code bases (LXR was built for the linux kernel, OpenGrok for when Sun open sourced Solaris).

Another one I had tried, which was very easy to setup was Gonzui. It's also open source, but didn't really handle the huge codebase as well as OpenGrok or LXR. For under 100k lines, it's probably fine, and the ease of setup may be worth it.

All three provide a web interface, and do indexing as a separate process from search, so we would re-index the code base nightly. works very well for larger teams, might be overkill for what you need though.

Oh... I forgot a very good one: http://opensolaris.org/

Yes, because there are no open source, non-GPL'd, kernels around. They'd obviously have to start completely from scratch.

Or you could have ZFS where you don't even need to resize.. it just happens.

Right, except if you want to do something crazy like reduce pool capacity, which is impossible.

Opensolaris also has a native CIFS implementation. Don't forget COMSTAR which will allow you to turn the system into a native fibre-channel or iscsi target. I also don't think vimage goes to quite the extent crossbow does... but I've yet to find anything that goes in depth on the project.

http://hub.opensolaris.org/bin/view/Project+crossbow/

Sun has some very cool hardware and software, not to mention an open source friendly attitude...

Sun has a Machiavellian attitude towards open source. They are open-source friendly when it suits their needs (public image). They are certainly not friendly to all open source projects. Need an example? Look at GCC. They feel free to rip off the GCC front-end for GCCFSS. They contribute virtually nothing to the GCC or binutils software in return.

Want to know how the GCC devs feel about it? Read the mailing list thread.

All their customers want is a fast and portable compiler for Sun hardware. Sun's own compiler sucks for C++ development. You have to use a non-standard, obsolete and soon to be deprecated C++ standard library just to have a slight chance of compiling any modern C++ software.

If you want to see just how screwed up their C++ development environment is going to get, you just have to read this thread: http://opensolaris.org/jive/thread.jspa?messageID=289188&tstart=0

From the discussion in the mailing list, it seems fairly certain that this can happen without Virtualbox. However, hardware is not bug free either. The issue is that zfs doesn't gracefully handle these failures. Most of the data on the disk were not affected in any way, yet the whole filesystem was hosed. See also the thread: http://mail.opensolaris.org/pipermail/zfs-discuss/2009-February/026087.html where simply yanking a USB disk with no mounted filesystems resulted in catastrophic failure. But it appears that something has been done about this issue and the patches have just made it into snv_128. http://bugs.opensolaris.org/view_bug.do?bug_id=6667683 I will have to reconsider my options now. There many things that look enticing in zfs.

From the discussion in the mailing list, it seems fairly certain that this can happen without Virtualbox. However, hardware is not bug free either. The issue is that zfs doesn't gracefully handle these failures. Most of the data on the disk were not affected in any way, yet the whole filesystem was hosed. See also the thread: http://mail.opensolaris.org/pipermail/zfs-discuss/2009-February/026087.html where simply yanking a USB disk with no mounted filesystems resulted in catastrophic failure. But it appears that something has been done about this issue and the patches have just made it into snv_128. http://bugs.opensolaris.org/view_bug.do?bug_id=6667683 I will have to reconsider my options now. There many things that look enticing in zfs.

I am building a new home NAS and I have been seriously considering zfs. However, I most likely won't go this route because there exist zfs failures that are catastrophic.
http://www.opensolaris.org/jive/thread.jspa?threadID=108213&tstart=0

I really don't want to loose all my data in the filesystem because the machine locked up at the wrong time. I may reconsider zfs once automated recovery tools become available.

How alarmist and uninformed; borderline FUD. The reality is as follows...

First, you can't remove a vdev yet, but development is in progress, and support is expected very soon now.

The bug report for this problem goes back to at least April of 2003. With that background, and that I've been hearing ZFS proponents suggesting this is coming "very soon now" for years without a fix, I'll believe it when I see it. Raising awareness that Sun's development priorities clearly haven't been toward any shrinking operation isn't FUD, it's the truth. Now, to be fair, that class of operations isn't very well supported on anything short of really expensive hardware either, but if you need these capabilities the weaknesses of ZFS here do reduce its ability to work for every use case.

This is called "block pointer (bp) rewrite" in ZFS parlance. It was talked about at SNIA 2009 (p. 18):

http://www.snia.org/events/storage-developer2009/presentations/monday/JeffBonwick_zfs-What_Next-SDC09.pdf

As well as Kernel Conference Australia 2009 (~40:00):

http://blogs.sun.com/video/entry/kernel_conference_australia_2009_jeff

Jeff Bonwick and Bill Moore said that it'd be committed by the end of this year. (Along with dedupe (done) and crypto.) They're cutting it a bit close, but I think the issues mentioned GP will not be a problem Real Soon Now.

How alarmist and uninformed; borderline FUD. The reality is as follows...

First, you can't remove a vdev yet, but development is in progress, and support is expected very soon now.

The bug report for this problem goes back to at least April of 2003. With that background, and that I've been hearing ZFS proponents suggesting this is coming "very soon now" for years without a fix, I'll believe it when I see it. Raising awareness that Sun's development priorities clearly haven't been toward any shrinking operation isn't FUD, it's the truth. Now, to be fair, that class of operations isn't very well supported on anything short of really expensive hardware either, but if you need these capabilities the weaknesses of ZFS here do reduce its ability to work for every use case.