opensolaris.org · Domains · Slashdot Mirror

Jeff Bonwick claims it was a licensing issue by Guy+Harris · 2009-10-25 06:27 · Score: 1 · on Apple Discontinues ZFS Project

In a message to the zfs-discuss list, he says that "the essence of [the issue]" was that Apple and Sun couldn't come to mutually agreeable terms on a license.

Re:Correction by TheRaven64 · 2009-10-24 02:14 · Score: 1 · on Apple Discontinues ZFS Project

If you'd like to read a bit more about ZFS, I'd recommend thispage on the OpenSolaris site and this article that I wrote a couple of years ago (somewhat out of date now; both of the limitations I listed have since been addressed). There are also some good presentations on how ZFS works linked to from the OpenSolaris docs. You will find a lot of criticisms of ZFS come from people who don't really understand how it works, or claim to need some esoteric feature that their current FS doesn't support either, but something like Veritas does.

Re:who's to blame. by jhol13 · 2009-10-19 02:39 · Score: 1 · on PulseAudio Creator Responds To Critics

Maybe that is one of the reasons for: http://opensolaris.org/os/project/opensound/?

Opensolaris Crossbow by anilg · 2009-10-15 19:31 · Score: 1 · on Affordably Aggregating ISP Connections?

Link aggregation made easy (_easy_ as in ZFS making filesystems easy)

http://opensolaris.org/os/project/crossbow/
Any opensolaris distribution with the latest builds should have this (including Nexenta).

Re:Where are the forks? by An+dochasac · 2009-09-14 22:35 · Score: 3, Informative · on OpenSolaris vs. Linux, For Linux Users

I'll take a look at OpenSolaris when there's at minimum 3 variants of it being developed.

Here is a list of 13 OpenSolaris distros as of March 2009:

Solaris Express Community Edition DVD (b110, GNOME 2.24.2,SPARC/x86)
OpenSolaris 2008.11 'preview' Live CD (b109, GNOME 2.24.2, SPARC/x86)
BeleniX 0.7.1 (b93, KDE 3.5.9)
Milax 0.3.3 (b105, JWM 2.0.1, SPARC/x86)
Pulsar 0.3a (b104)
MartUX Natamar 0.4 (b96, IceWM 1.2.35, SPARC)
SchilliX 0.6.7 (b92)
NexentaCore 1.0.1/2.0b2 (b85+/b104+)
NexentaStor 1.1.4 (b85+)
EON 0.58.9 (embeddable NAS, b104)
OpenSolaris for System z (release 20081023)
Polaris (OpenSolaris on PowerPC project, b104+)
AuroraUX (b101, Xorg 7.2)

Re:The cool kids don't care by Anonymous Coward · 2009-09-11 04:34 · Score: 1, Informative · on Oracle To Increase Investment In SPARC and Solaris

Solaris has no limit:

/*
* max_ncpus keeps the max cpus the system can have. Initially
* it's NCPU, but since most archs scan the devtree for cpus
* fairly early on during boot, the real max can be known before
* ncpus is set (useful for early NCPU based allocations).
*/
int max_ncpus = NCPU; /*
* platforms that set max_ncpus to maxiumum number of cpus that can be
* dynamically added will set boot_max_ncpus to the number of cpus found
* at device tree scan time during boot.
*/
int boot_max_ncpus = -1;
int boot_ncpus = -1;

Searching for NCPU in the code, you can see that it is set by the CPU driver. Honestly, Solaris has been able to run on multiple architectures for years and the kernel is really not that big. To say that Solaris can't do something without trying it is just idiotic.

Re:Not ZFS? by chudnall · 2009-09-02 03:13 · Score: 3, Interesting · on Build Your Own $2.8M Petabyte Disk Array For $117k

What do you mean by more expensive? OpenSolaris with ZFS costs the same as Linux. And yes, You'll have to get up a lot less often in the middle of the night, since a few bad sectors aren't going to force a fail of the entire disk.

Re:Typical redditor by Anonymous Coward · 2009-08-04 02:10 · Score: 0 · on Intel Confirms Data Corruption Bug, Halts New SSDs

Wrong..

Was that ever an interesting bug to run down. It dates back to pre-OpenSolaris days, so what you're seeing comes from closed source origins.

To make a long story short: On Sun 15K (top-end supercomputers at the time) a hardware issue would cause mkfs to fail some times, but only if data was accessed on a non-8-byte boundary.

The fix:
"Doctor, it hurts when I do this."
"So, don't do it."

Cheaper and faster then respinning silicon.

So yes, non-determinism does crop up.

Re:Looks promising by TheRaven64 · 2009-08-01 23:04 · Score: 1 · on A Short History of Btrfs

You know HFS+ is also fully documented right?

Yes, I've read the documentation. Fully is a bit of a stretch; it's just about enough for an alternative implementation, but it's horribly written. ZFS is also fully documented. If you want to read about it, start here and follow the links. You'll find a complete cross-referenced and explained copy of the source code as well as high-level descriptions.

So, if a person reading filesystem specs for entertaintment didn't know about these and only knew about enterprise features of ZFS, perhaps there is a problem with how ZFS is advertised to OS X community

There's a massive difference between reading filesystem specs and reading marketing material. You'd know about the things I described if you'd read the introduction to the source tour which discusses the three layers in ZFS and what goes in each one. Even if you just looked at the pretty picture (top-right), you'd see that the POSIX compatibility code is in the interface layer, right next to the block-device emulation code, and the transactional object layer and storage pool layers both go under this.

and the stuff you talk about not being implemented at all.

Well, obviously. The port to OS X is not yet finished. If you look at the TODO section on macosforge, you'll see a number of missing bits. Generally, you don't add new features to a port until after you've completed the actual porting part of the job. OS X doesn't really need resource forks anymore; the VFS layer maps them to hidden files if they are not supported by the underlying filesystem and their use is discouraged in favour of bundles by new apps. Creator codes and so on can easily be stored in POSIX extended attributes, so modifying the ZPL may not be the best option; they may just add some transparent mappings in the top of the VFS layer.

Re:Looks promising by TheRaven64 · 2009-08-01 23:04 · Score: 1 · on A Short History of Btrfs

You know HFS+ is also fully documented right?

Yes, I've read the documentation. Fully is a bit of a stretch; it's just about enough for an alternative implementation, but it's horribly written. ZFS is also fully documented. If you want to read about it, start here and follow the links. You'll find a complete cross-referenced and explained copy of the source code as well as high-level descriptions.

So, if a person reading filesystem specs for entertaintment didn't know about these and only knew about enterprise features of ZFS, perhaps there is a problem with how ZFS is advertised to OS X community

There's a massive difference between reading filesystem specs and reading marketing material. You'd know about the things I described if you'd read the introduction to the source tour which discusses the three layers in ZFS and what goes in each one. Even if you just looked at the pretty picture (top-right), you'd see that the POSIX compatibility code is in the interface layer, right next to the block-device emulation code, and the transactional object layer and storage pool layers both go under this.

and the stuff you talk about not being implemented at all.

Well, obviously. The port to OS X is not yet finished. If you look at the TODO section on macosforge, you'll see a number of missing bits. Generally, you don't add new features to a port until after you've completed the actual porting part of the job. OS X doesn't really need resource forks anymore; the VFS layer maps them to hidden files if they are not supported by the underlying filesystem and their use is discouraged in favour of bundles by new apps. Creator codes and so on can easily be stored in POSIX extended attributes, so modifying the ZPL may not be the best option; they may just add some transparent mappings in the top of the VFS layer.

Re:Oh great by toby · 2009-08-01 08:35 · Score: 4, Interesting · on A Short History of Btrfs

I'd rephrase that. It eliminates the common cases where you'd need fsck on a conventional filesystem.

ZFS' design makes consistency failure extremely unlikely. I understand why they claim it doesn't need fsck ("always consistent on disk"). There is controversy over whether there should be a scavenging tool. Some people want one for peace of mind.

But again, most cases of ZFS pool loss where some believe a scavenger may have saved them, may actually have been solved by more aggressive rollback (I believe work is being done on this).

Anyone interested in this issue should follow the ZFS mailing list.

Re:Oh great by toby · 2009-08-01 08:35 · Score: 4, Interesting · on A Short History of Btrfs

I'd rephrase that. It eliminates the common cases where you'd need fsck on a conventional filesystem.

ZFS' design makes consistency failure extremely unlikely. I understand why they claim it doesn't need fsck ("always consistent on disk"). There is controversy over whether there should be a scavenging tool. Some people want one for peace of mind.

But again, most cases of ZFS pool loss where some believe a scavenger may have saved them, may actually have been solved by more aggressive rollback (I believe work is being done on this).

Anyone interested in this issue should follow the ZFS mailing list.

Re:Wut by Captain+Segfault · 2009-06-23 12:15 · Score: 1 · on Best eSATA JBOD?

When I google JBOD, from the *first page* of results:

http://www.aberdeeninc.com/abcatg/kitjbod-1003.htm

http://opensolaris.org/jive/thread.jspa?threadID=83108&tstart=0

http://blogs.sun.com/brendan/entry/jbod_analytics_example

Re:Perhaps it will BE ZFS just not BE CALLED ZFS by saleenS281 · 2009-06-10 10:13 · Score: 1 · on Apple Removes Nearly All Reference To ZFS

What are you talking about? The COMSTAR project will present LUNs out to host devices via FCP or iSCSI. It doesn't matter what OS the host computer is running.

Re:Death knell by diegocgteleline.es · 2009-06-10 02:24 · Score: 4, Informative · on Apple Removes Nearly All Reference To ZFS

I have been following the zfs-discuss list for years, and almost no one has lost data.