OSNews

w00t! w00t!

The ZFS support is only available for the -CURRENT branch at the moment, which is unstable, state of the art and NOT recommended for production use. I don't think ZFS will be backported to the 6.x branch, so we'll have to wait for the 7.0 release.

Nobody with a sane mind would be using a new ported filesystem in a production environment.

Support for reading it must be done in bootloader (GRUB for Solaris x86). So one have reimplement part of filesystem, in pretty hostile environment (bootloader is simple compared with fullblown OS with memory management and stuff). Also volume management part of ZFS makes it harder -- you can't just read some sectors of hard drive, you have to recreate stripes, mirrors, raids first.

But it's doable. Solaris people were working on it ( http://opensolaris.org/os/project/zfsboot/ ) and it's now possible to boot Solaris from ZFS on x86 ( http://www.opensolaris.org/os/community/on/flag-days/pages/20070328... ).

"ZFS is one of the most interesting things to come out of Sun recently and is a much needed tune up to the Solaris filesystem."

I like the idea of soon having the great things from Solaris to be used in BSD as well. FreeBSD will surely become a concentrate of the best aspects of itself and other OSes (Solaris, OpenBSD etc.). I can't wait to see version 7 available for download.

"Journaling UFS, although not bad, is not my first choice as when the power goes down, you might still end up losing data or making the system unstable."

Just as I sidenote, I'd like to say that I did not encounter such problems, allthough my boss is one who likes to flip the main power switch of his FreeBSD (UFS2) workstation without shutting it down properly. The fsck works without user interaction, repairing minor problems by itself, but data loss? No.

UFS / UFS2 is quite safe because the on disk status is always in a consistent state between the writing operations. It uses soft updates instead of journaling. Metadata is written asynchronously in a definite order. In journaling, as you surely know it from EXT3FS, metadata is written twice, once into the journal, once to the file system, asynchronously. After writing operation to the file system is finished, the information is deleted from the journal. An interruption within this process may lead files to disappear without any warning.

"I'm glad FreeBSD has been able to incorporate dtrace as well. It seems to be making a great OS even better."

I'm glad I'm not the only one who thinks so. :-)

I like the idea of soon having the great things from Solaris to be used in BSD as well. FreeBSD will surely become a concentrate of the best aspects of itself and other OSes (Solaris, OpenBSD etc.).

If Sun and the OpenSolaris community have their way, Solaris will become the best of other operating systems too Lets see who gets there first

I think this is a better one-line summary from the ZFS FAQ on OpenSolaris.org:

But also the distros that are derived from it such as Dragonfly BSD and DesktopBSD.

IIRC then DragonflyBSD is fork from FreeBSD and DesktopBSD *is* FreeBSD just like PC-BSD.

Journaling filesystems like Gjournal and ZFS is godsent for desktop users because usually desktop computers have no UPS and in case of power failure they are first victims with messed filesystems and lost files.

Oh okay good call. I was trying to find the other name (PC-BSD) but I couldn't recall it so I thought it was Dragonfly BSD.

Either way, I agree. I also see this being really great for a fast recovery system along with a backup system. Also with the ability to write those add ons so easily with the API they provide, we could see some really neat other tools blossom it seems like.

there's no plan to port ZFS to DragonflyBSD in the future. the kernels are too much different by now and Matt's going on with his own implementation of a 'cluster filesystem'...

I wish that the Linux developers considered it as well, especially now that the Reiser4 future is totally unknown.

I wish it too, but if something has not changed since the last time i checked, there were licensing problem in including ZFS code within the Linux kernel.

However, there is a good working implementation of ZFS for FUSE to be used with Linux.

It is still in beta stage, and it will never be like having it in the kernel, however is a very interesting project.

I think that if the license of ZFS change, it won't be too hard to have ZFS in the kernel thanks to the work that Ricardo Correia is doing with ZFS on FUSE.

Check it out at this address:
http://zfs-on-fuse.blogspot.com/

"""
And ZFS important for the desktop? What a nonsense ...
"""

Well, ZFS does seem already to have easier administration tools than the Linux Partitioning/RAID/LVM/EXT3 stack.

There is no reason that all those layers could not be easily controlled through a simple gui. But I'm beginning to despair of it ever happening. It's not like any one of those layers is new. And still, adding a new drive to an existing filesystem is rocket science.

It's not just that you have to drop to the command line to do it. It's that you have to drop to the command line and make the new drive a physical volume, add the physical volume to the volume group, expand the logical volume, and then online resize the filesystem. Oh, and you'd better do all that by UUID or label, and not device name, because you are not guaranteed that the device name will remain constant. Simple, isn't it?

I envision plain old end users being able to just plug another USB drive into their machine, and have it simply added to their existing filesystem.

They can already do this with RAM. Just plug it in and they have 2GB whereas they used to have 1GB.

They should be able to do the same with storage.

Again, there is no reason we *can't* do this in Linux. But it looks to me like ZFS has at least made some progress toward simplifying FS administration for people who don't happen to be experts.

Regarding your other claim. I tend to agree, as things stand today.

But, I suspect that composited desktops will gain some actual value once the silly and useless effects are dropped (retaining any features which are actually useful that may sift out), more cards support them, stability increases substantially, and they are considered mundane enough that no one talks about them any more. (And users come down hard on anyone who tries to reintroduce silliness like wobbly windows).

But I suppose this is not really the place to have that discussion.

Edited 2007-04-07 03:09