Slashdot Mirror

The addresses (known as DVAs, or "data virtual addresses") used in the SPA (storage pool allocator) are 128-bit. This is currently divided into a 63-bit offset within a vdev (virtual device), 32-bit vdev id, and some additional bits for implementing RAID-Z and fragmented (gang) blocks. For more information, see:

http://src.opensolaris.org/source/xref/onnv/onnv-g ate/usr/src/uts/common/fs/zfs/sys/spa.h#107

However, the ZPL (ZFS POSIX layer) and DMU (data management unit) currently use 64-bit object identifiers based largely on the fact that no 128-bit POSIX interfaces exist (open128, stat128, etc). This could be changed in the future without affecting the on-disk block pointers, but for the time being the maximum size of any filesystem is 2^64.

Sorry, it's Linux that's playing the license games, not Sun.

ZFS is on OpenSolaris and Sun has claimed to be considering GPL for OpenSolaris. Are they, or aren't they? On top of that, the FSF has muddied the waters through their activity on the GPLv3, further complicating the entire issue.

I don't think you can blame the whole situation on Linux's use of the GPL, which is not coincidentally the reason why many people contributed to Linux. Given that Linux is today considerably ahead of all BSDs in most ways, I think adoption of the GPL is likely the only reason Linux is here today.

Finally, if you don't care about software freedom, and only your freedom, why don't you go run BSD, and stop complaining about Linux?

On the OpenSolaris list, it is generally agreed that when 'Linux' was used, it was in the context of a Linux distribution and not the kernel. You are a sore loser.

http://mail.opensolaris.org/pipermail/opensolaris- discuss/2007-May/028665.html

Items that belong in 'Linux' are stuff outside the Linux kernel

http://mail.opensolaris.org/pipermail/opensolaris- discuss/2007-May/028679.html

Sun engineer clearly views Linux as the referring to the distro and not the kernel.

Plenty more from that thread.

Martin clearly has not made an erroneous statement like you did.

On the OpenSolaris list, it is generally agreed that when 'Linux' was used, it was in the context of a Linux distribution and not the kernel. You are a sore loser.

http://mail.opensolaris.org/pipermail/opensolaris- discuss/2007-May/028665.html

Items that belong in 'Linux' are stuff outside the Linux kernel

http://mail.opensolaris.org/pipermail/opensolaris- discuss/2007-May/028679.html

Sun engineer clearly views Linux as the referring to the distro and not the kernel.

Plenty more from that thread.

Martin clearly has not made an erroneous statement like you did.

http://www.opensolaris.org/os/community/arc/caselo g/2007/244/;jsessionid=4DEEAE13A4489C28E3C4644C989 86C1F

It's pretty clear the ZFS simply was not ready to ship. Leopard was to be "Feature Complete" by yesterday and ZFS was not ready, so it gets cut. Even Sun can't make it so that ZFS is bootable on a production version of Solaris. Also the "user land" utilities are not quite what a typical Mac user would want.

ZFS is bootable in recent OpenSolaris builds http://www.opensolaris.org/os/community/zfs/boot/. It may not be in Solaris 10 production systems yet, but it is clearly coming soon.

Speaking of Solaris 10 and ZFS, I've started moving a number of my servers over to Solaris 10 with ZFS. ZFS is probably going to keep us on Solaris for some time to come.

Preliminary ZFS support showed up in a Leopard build in April of 2006. Now, there's nothing to say it was ever going to ship, or if they were laying the groundwork for OS X 10.6 or what, but the bits were there (and apparently still are).

I'm still not convinced Apple has dropped it because of Schwartz' comments, however.

Jonathan *had* to know he might get burned for spilling the beans before Steve.

I'm not sure how Jonathan got burned. Sure, it'd look good for Sun to have ZFS integrated into Mac OS X, but at the end of the day it doesn't really do much for them. If anyone got screwed, it's the end-users. That's if Steve really did decide to pull it based on Jonathan's comments.

I'm not convinced ZFS support is far enough along to be included in Leopard.

Apparently, the work they've done is still in the WWDC beta build.

The way they point to the full read/write kext at developer.apple.com makes me think maybe Apple will ship it flagged as experimental or something (similar to FreeBSD).

Have you actually *used* ZFS? It is not CPU intensive in the least. I've run it on a 700MHz PIII with no problems. From the developer's mouth: "Assume 1 2GHz Opteron for every 200 MB/s, including ZFS *and* the NFS stack". 200 MB/s is an order of magnitude (10x) faster than any hard disk installed in a desktop or laptop. And, that's for a continuous I/O load, which most users never see.

If you're having CPU issues with ZFS, you're in the HD video business, in which case you'll have a dual CPU machine anyway.

HFS+ may date only from System 8.1, but HFS is considerably older - nearly 22 years now. It's very mature and stable code, even the POSIX stuff they bolted on later for HFS+.

Well, we can wait a bit longer for ZFS. If you can't wait, grab a Solaris 10, Solaris Express, or OpenSolaris distribution and start playing today! I'm not comfortable committing precious data to anything else.

One day most of our day-to-day filesystems will incorporate the ideas in ZFS - one or two have been seen before, but never in such a devastating ensemble. The 'Z' may as well stand for 'Zen': Grokking why ZFS is revolutionary seems to be a Zen-like enlightenment :) Many people still wonder "huh? what's the fuss?", as happens with any generational change...

HFS+ may date only from System 8.1, but HFS is considerably older - nearly 22 years now. It's very mature and stable code, even the POSIX stuff they bolted on later for HFS+.

Well, we can wait a bit longer for ZFS. If you can't wait, grab a Solaris 10, Solaris Express, or OpenSolaris distribution and start playing today! I'm not comfortable committing precious data to anything else.

One day most of our day-to-day filesystems will incorporate the ideas in ZFS - one or two have been seen before, but never in such a devastating ensemble. The 'Z' may as well stand for 'Zen': Grokking why ZFS is revolutionary seems to be a Zen-like enlightenment :) Many people still wonder "huh? what's the fuss?", as happens with any generational change...

It is not feature complete. ZFS support is read-only.

http://www.solarisinternals.com/wiki/index.php/ZFS _Best_Practices_Guide#Memory_and_Dynamic_Reconfigu ration_Recommendations

is a good place to start looking, but as you can see here:

http://www.opensolaris.org/jive/thread.jspa?messag eID=122983

You can use the command located here:
http://milek.blogspot.com/2006/09/how-much-memory- does-zfs-consume.html

to show how much is being consumed by ZIO buffers.

No, no and no.

• ZFS will have case-insensitive support if it is used in Mac OS X (closed approved fast-track 05/09/2007).
• HFS+ has case-sensitity as an option, so if you want to, you can have a case-sensitive Mac.
• Case-sensitivity is a stupid idea for regular users and will never be on by default on Macs (there's no reason why "My Letter to Aunt Emma" should be a different file from "My letter to Aunt Emma")

Please let it be case-insensitive and case-preserving.

You are free to reimplement ZFS for Linux, not in FUSE. You might even start from the GPL'd code in GRUB at http://src.opensolaris.org/source/xref/onnv/onnv-g ate/usr/src/grub/grub-0.95/stage2/ .

If you don't know, why don't you just take a look:

http://www.opensolaris.org/os/community/zfs/demos/ basics/

When was this functionality added?

I use FreeNAS [http://www.freenas.org/] I have a mirrored 120G RAID setup going, and it has all the bells and whistles to let you sync in many ways; highly recommended if you need a backup server of any type, but if you really want a solution that doesn't hem you in like the RAID size can't be bigger than the smallest drive in the array, go for ZFS. Check out the demos here to get an idea of what it can do: http://www.opensolaris.org/os/community/zfs/demos/ ;jsessionid=7E22552C4800B7688DFD8FD771896B4B Granted it's new, but drop OpenSolaris on a box and get it configured and running...that's an option you can grow with. Also, FreeBSD has experiemental support for ZFS, and it should (?) be available on the upcoming 7.0 release. I'm sure someone will provide a web GUI to configure it, heck, that'd be a coup for the FreeNAS team, and then you'd really be all set.

While you're there, check out how http://en.wikipedia.org/wiki/ZFS can make most of the issues other posters are point out irrelevant, or at least nothing to be worried about.

While Solaris might be a dirty word among the Slashdot crowd, if all the OP needs is a way to store a bunch of files, ZFS is an excellent solution. Check out http://www.opensolaris.org/os/community/zfs/whatis / and in particular the demos linked on the left side.

Then, if you're still not convinced how appropriate ZFS might be for a somewhat clueless user, read about how it can save your ass from flaky hardware and data corruption: http://blogs.sun.com/elowe/entry/zfs_saves_the_day _ta

The raid 5 "write hole" problem (I should have used the double quotes like this, instead of around the term raid 5) is mentioned here [1] and on pages 16-17 of this presentation [2].

The raid 5 "write hole" problem (I should have used the double quotes like this, instead of around the term raid 5) is mentioned here [1] and on pages 16-17 of this presentation [2].

Actually, the problem is that you can't grow the number of columns in your RAIDZ set. This means that if you have a 4-disk RAIDZ storage, you can't make it a 5-disk RAIDZ storage.

What you can do however, is replace the disks one by one by bigger disks. This will give you a bigger RAIDZ pool with the same number of disks.

See a thread discussing this and other options here:
http://www.opensolaris.org/jive/message.jspa?messa geID=118614#118614

Wout.

Note i work on ZFS.

For the fsync() issue, we actually have code going through final code review comments which will allow you to specify separate devices for the "ZIL" (ZFS intent log). The ZIL is responsible for pushing out the synchronous writes. With a separate log device in place, the asynchronous writes won't interfer with the synchronous ones. See:
http://bugs.opensolaris.org/view_bug.do?bug_id=633 9640

I know the compression is no longer single threaded as i fixed that back in February (build snv_59). See:
http://bugs.opensolaris.org/view_bug.do?bug_id=646 0622

The configurable blocksize is actually an advantage, not a disadvantage. ZFS's blocksize is dynamic (it can grow on demand from 512B to 128KB). This is really nice for very large files (less indirect blocks). But yes it causes problems for workloads such as databases that do random aligned I/O (typically 8k). If your blocksize was 128KB and not cached, then its silly to have to read in 128KB to modify 8KB, when all you wanted to do was just a single 8KB write. Allowing the user specify the maximum blocksize is a win for workloads (such as Oracle). I see it as a disadvantage that other filesystems can't do this on the fly (no recompiling, ZFS can do this online).

Note, back in March we added gzip as a compression algorithm (snv_62). See:
http://bugs.opensolaris.org/view_bug.do?bug_id=653 6606

I'm not sure what "ZFS eats a lot of CPU when doing small writes" really refers to. If someone has done or can do some initial performance analysis, feel free to send your results to zfs-discuss@opensolaris.org. If its a real bug, we'd like to fix it.

The issue of "ZFS only offlines a faulty harddisk if it can't be opened" is true and the fix is going through final development.

I encourage everyone to take a look at our documentation (pdf overview, admin guide, on-disk format guide, and source tour) at:
http://opensolaris.org/os/community/zfs/

The filesystem space is really at an interesting point in time (not just inside Sun), and hopefully we will see more innovation (besides just ZFS). I know the Linux community is very active in this space. I look foward to seeing what future filesystem(s) they come up with.

eric

Note i work on ZFS.

For the fsync() issue, we actually have code going through final code review comments which will allow you to specify separate devices for the "ZIL" (ZFS intent log). The ZIL is responsible for pushing out the synchronous writes. With a separate log device in place, the asynchronous writes won't interfer with the synchronous ones. See:
http://bugs.opensolaris.org/view_bug.do?bug_id=633 9640

I know the compression is no longer single threaded as i fixed that back in February (build snv_59). See:
http://bugs.opensolaris.org/view_bug.do?bug_id=646 0622

The configurable blocksize is actually an advantage, not a disadvantage. ZFS's blocksize is dynamic (it can grow on demand from 512B to 128KB). This is really nice for very large files (less indirect blocks). But yes it causes problems for workloads such as databases that do random aligned I/O (typically 8k). If your blocksize was 128KB and not cached, then its silly to have to read in 128KB to modify 8KB, when all you wanted to do was just a single 8KB write. Allowing the user specify the maximum blocksize is a win for workloads (such as Oracle). I see it as a disadvantage that other filesystems can't do this on the fly (no recompiling, ZFS can do this online).

Note, back in March we added gzip as a compression algorithm (snv_62). See:
http://bugs.opensolaris.org/view_bug.do?bug_id=653 6606

I'm not sure what "ZFS eats a lot of CPU when doing small writes" really refers to. If someone has done or can do some initial performance analysis, feel free to send your results to zfs-discuss@opensolaris.org. If its a real bug, we'd like to fix it.

The issue of "ZFS only offlines a faulty harddisk if it can't be opened" is true and the fix is going through final development.

I encourage everyone to take a look at our documentation (pdf overview, admin guide, on-disk format guide, and source tour) at:
http://opensolaris.org/os/community/zfs/

The filesystem space is really at an interesting point in time (not just inside Sun), and hopefully we will see more innovation (besides just ZFS). I know the Linux community is very active in this space. I look foward to seeing what future filesystem(s) they come up with.

eric

Note i work on ZFS.

For the fsync() issue, we actually have code going through final code review comments which will allow you to specify separate devices for the "ZIL" (ZFS intent log). The ZIL is responsible for pushing out the synchronous writes. With a separate log device in place, the asynchronous writes won't interfer with the synchronous ones. See:
http://bugs.opensolaris.org/view_bug.do?bug_id=633 9640

I know the compression is no longer single threaded as i fixed that back in February (build snv_59). See:
http://bugs.opensolaris.org/view_bug.do?bug_id=646 0622

The configurable blocksize is actually an advantage, not a disadvantage. ZFS's blocksize is dynamic (it can grow on demand from 512B to 128KB). This is really nice for very large files (less indirect blocks). But yes it causes problems for workloads such as databases that do random aligned I/O (typically 8k). If your blocksize was 128KB and not cached, then its silly to have to read in 128KB to modify 8KB, when all you wanted to do was just a single 8KB write. Allowing the user specify the maximum blocksize is a win for workloads (such as Oracle). I see it as a disadvantage that other filesystems can't do this on the fly (no recompiling, ZFS can do this online).

Note, back in March we added gzip as a compression algorithm (snv_62). See:
http://bugs.opensolaris.org/view_bug.do?bug_id=653 6606

I'm not sure what "ZFS eats a lot of CPU when doing small writes" really refers to. If someone has done or can do some initial performance analysis, feel free to send your results to zfs-discuss@opensolaris.org. If its a real bug, we'd like to fix it.

The issue of "ZFS only offlines a faulty harddisk if it can't be opened" is true and the fix is going through final development.

I encourage everyone to take a look at our documentation (pdf overview, admin guide, on-disk format guide, and source tour) at:
http://opensolaris.org/os/community/zfs/

The filesystem space is really at an interesting point in time (not just inside Sun), and hopefully we will see more innovation (besides just ZFS). I know the Linux community is very active in this space. I look foward to seeing what future filesystem(s) they come up with.

eric

Note i work on ZFS.

For the fsync() issue, we actually have code going through final code review comments which will allow you to specify separate devices for the "ZIL" (ZFS intent log). The ZIL is responsible for pushing out the synchronous writes. With a separate log device in place, the asynchronous writes won't interfer with the synchronous ones. See:
http://bugs.opensolaris.org/view_bug.do?bug_id=633 9640

I know the compression is no longer single threaded as i fixed that back in February (build snv_59). See:
http://bugs.opensolaris.org/view_bug.do?bug_id=646 0622

The configurable blocksize is actually an advantage, not a disadvantage. ZFS's blocksize is dynamic (it can grow on demand from 512B to 128KB). This is really nice for very large files (less indirect blocks). But yes it causes problems for workloads such as databases that do random aligned I/O (typically 8k). If your blocksize was 128KB and not cached, then its silly to have to read in 128KB to modify 8KB, when all you wanted to do was just a single 8KB write. Allowing the user specify the maximum blocksize is a win for workloads (such as Oracle). I see it as a disadvantage that other filesystems can't do this on the fly (no recompiling, ZFS can do this online).

Note, back in March we added gzip as a compression algorithm (snv_62). See:
http://bugs.opensolaris.org/view_bug.do?bug_id=653 6606

I'm not sure what "ZFS eats a lot of CPU when doing small writes" really refers to. If someone has done or can do some initial performance analysis, feel free to send your results to zfs-discuss@opensolaris.org. If its a real bug, we'd like to fix it.

The issue of "ZFS only offlines a faulty harddisk if it can't be opened" is true and the fix is going through final development.

I encourage everyone to take a look at our documentation (pdf overview, admin guide, on-disk format guide, and source tour) at:
http://opensolaris.org/os/community/zfs/

The filesystem space is really at an interesting point in time (not just inside Sun), and hopefully we will see more innovation (besides just ZFS). I know the Linux community is very active in this space. I look foward to seeing what future filesystem(s) they come up with.

eric

See for yourself.

OK:

• ZFS w/flaky hardware (scary): http://blogs.sun.com/elowe/entry/zfs_saves_the_day _ta

• Self Healing with ZFS: http://www.opensolaris.org/os/community/zfs/demos/ selfheal/

• 100 Mirrored Filesystems in 5 minutes: http://www.opensolaris.org/os/community/zfs/demos/ basics/

OK:

• ZFS w/flaky hardware (scary): http://blogs.sun.com/elowe/entry/zfs_saves_the_day _ta

• Self Healing with ZFS: http://www.opensolaris.org/os/community/zfs/demos/ selfheal/

• 100 Mirrored Filesystems in 5 minutes: http://www.opensolaris.org/os/community/zfs/demos/ basics/

There have been updates on the online repository and you can upgrade with "apt-get update && apt-get dist-upgrade". For example, see http://mail.opensolaris.org/pipermail/opensolaris- announce/2007-April/000968.html

Could you point out some of them? I used to use Solaris a lot, a long time ago, but that was never as a system administrator. It was rather good then, but over the last 7 years I've moved to linux, OS X and OpenBSD. Last time I used Solaris for work was in 2003. What's better with Solaris these days?

Stability, Scalability. Though more relevant for production machines.

dtrace, if I (mis-)understand correctly, is mainly useful for kernel work and is available on other platforms. What other uses might there be, if any?

If you are a pure end-user, maybe not relevant to you, right.

zfs seems to have some kind of RAID capabilities, but last I heard can't be used as the root file system.

The latest can. Wait a few more months.
Read http://www.opensolaris.org/os/community/zfs/ for plenty of advantages !

zones seem intriguing, but a cursory examination does make it stand out over other virtualization / paravirtualization methods.

If you stick to Solaris, a zone contains by default around 3 MB of data. There is almost no virtualisation loss.

If Ian Murdock is able to get Sun to adopt apt, that would bring me and a lot of others in again. If they can make the install as easy as Debian or Ubuntu, then that will pull in a lot of the curious: as of a few weeks ago the installation process required a serious time commitment and patience.

[It is getting boring here, but try Nexenta ! It is SunOS with apt ...]

it's just a pain in the ass after using almost any Linux distro.

Actually, using a Linux distro after using/administering Solaris for 10+ years is a pain in the ass. It is just a matter of what you are used to.

Sun's problem is that not only is everything surrounding that kernel stagnant, but that it really hasn't done the basic things needed to build a real community.

See, and there is where you and I differ in our opinions. I am more concerned about technical support. There is a user community out there (Open Solaris, comp.unix.solaris in Usenet, Sun Managers mailing list, Big Admin, etc.) but those are not central for the seasoned Solaris sys admin. They sure are useful but having kick-ass technical support and a stable and reliable user and sys admin experience is much more important for a Solaris admins.

ZFS? DTrace? Zones?

May I add: Fault Management Framework [1], Crossbow [2], pNFS [3], stable device driver interface (one of the biggest point driver developers complain about in Linux). Clearly the GP has no idea about the number of technological advances Sun is pushing in OpenSolaris.

ZFS? DTrace? Zones?

May I add: Fault Management Framework [1], Crossbow [2], pNFS [3], stable device driver interface (one of the biggest point driver developers complain about in Linux). Clearly the GP has no idea about the number of technological advances Sun is pushing in OpenSolaris.

ZFS? DTrace? Zones?

May I add: Fault Management Framework [1], Crossbow [2], pNFS [3], stable device driver interface (one of the biggest point driver developers complain about in Linux). Clearly the GP has no idea about the number of technological advances Sun is pushing in OpenSolaris.

Solaris is open source and free. http://www.opensolaris.org/os/

Also consider that some of the better solaris features have been added to FreeBSD recently. dtrace and zfs are available for FreeBSD 7 current.

<OT>

</OT>

UNIX and Linux have been careful about avoiding simplistic designs. ZFS is a simple, obvious answer to a problem: just pack all the functionality into one big codeball and start hacking.

Wrong, wrong, and wrong. Why don't you read about something before you start shooting your mouth off? ZFS is layered. You can even, y'know, read the source before you start making ignorant claims. I guess this wouldn't be Slashdot if people did that, though.

That would be ZFS, built from the scratch to avoid the problems faced by traditional filesystems. It is, in fact, a volume-manager+file system, with RAID built into it. Not to mention the very easy to use commands.

COW has been present for a long time in ZFS since Solaris 10. The overhead there is negligible and its quite stable. Last I heard, it was being ported to FUSE on linux. Upcoming in the next releases of FreeBSD and OSX. Wiki has a pretty good article.

You can even run Linux binaries in a Linux-branded zone on Solaris 10. No need to recompile from scratch.

Seems that ZFS will be available for FreeBSD here soon. Available now for the adventurous, which I imagine is not how the poster is feeling. As a FreeBSD user I'm definitely looking forward to a stable ZFS on there.

Sun wanted to free Solaris, a SysVR4 derived OS, which obviously required clearing the licenses first. Hurting Linux may or may not have been a side benefit, but for a company like Sun releasing their "crown jewels" will have been the main issue.

Funny thing about the 'act' that was passed is it has a clause about congressional review. So at some point, congress could have said "This is stupid" and undone the DST change. Everyone was waiting for the fall session to start, I suspect, to ensure the DST change was going to stick.

Further, if your running Solaris it's not just a TZ patch. There's libc changes:

http://src.opensolaris.org/source/diff/onnv/onnv-g ate/usr/src/lib/libc/port/gen/localtime.c?r1=1138& r2=0

There's also glibc issues in RHEL 2.1 but they're not quite the same as Solaris.
http://kbase.redhat.com/faq/FAQ_41_9949

Cheers,
Rich

OMG! You're right!

I strongly agree: the fix for any version of Solaris, and in principle any other machine with zic and zdump, is

• Download the northamerica zoneinfo file from the Open Solaris site as /usr/share/lib/zoneinfo/src/northamerica.2007
• As root, run
  # /usr/sbin/zic /usr/share/lib/zoneinfo/src/northamerica.2007
  # /usr/sbin/zic /usr/share/lib/zoneinfo/src/backward
• Test it with
  $ zdump -v Canada/Eastern | grep 2007
• If the dates are Mar 11 and Nov 4, it worked.
  
• If they are still April 1 and October 28, it didn't.
• Optionally go back to the 2006 settings with
  # /usr/sbin/zic /usr/share/lib/zoneinfo/src/northamerica
  # /usr/sbin/zic /usr/share/lib/zoneinfo/src/backward
• Thanks and a tip of the hatlo hat go to rweeks of the Open Solaris sysadmin forum for the "zic backward" line above which made the Canadian time zones work.
  
  

I strongly agree: the fix for any version of Solaris, and in principle any other machine with zic and zdump, is

• Download the northamerica zoneinfo file from the Open Solaris site as /usr/share/lib/zoneinfo/src/northamerica.2007
• As root, run
  # /usr/sbin/zic /usr/share/lib/zoneinfo/src/northamerica.2007
  # /usr/sbin/zic /usr/share/lib/zoneinfo/src/backward
• Test it with
  $ zdump -v Canada/Eastern | grep 2007
• If the dates are Mar 11 and Nov 4, it worked.
  
• If they are still April 1 and October 28, it didn't.
• Optionally go back to the 2006 settings with
  # /usr/sbin/zic /usr/share/lib/zoneinfo/src/northamerica
  # /usr/sbin/zic /usr/share/lib/zoneinfo/src/backward
• Thanks and a tip of the hatlo hat go to rweeks of the Open Solaris sysadmin forum for the "zic backward" line above which made the Canadian time zones work.
  
  

But every system I've ever had to use, and not had source code for, I've run into the limits of.

Solaris is open source.

why would I want to leave the "L" (Linux) out of the Apache/MySql/Php stack?