What's this ZFS thing?  Why would I want it on my computer?

ZFS is, bar none, the best file system ever invented.  It's better than ext4, better than XFS, and better than btrfs (which is, to date, the most advanced file system included in the Linux kernel).

If you want high reliability, data integrity and ease of administration for your computer, then you want to install Fedora atop ZFS.

I'll help you do exactly that.

Gather what you'll need

This guide should take about 25 to 30 minutes of your time, unless you're making a speed run.  You will need:

1. A computer with a hard disk (or SSD, same thing).  Conceivably, you could install on an USB drive too.  We'll stick to the hard disk in this case.
2. A USB drive or CD-ROM with Fedora 16 Live booting from it.  You can record a CD or use liveusb-creator to afford your USB the Live CD.

Install Fedora

We are going to install a Fedora copy on your computer.

Boot Fedora Live

Tell your computer that you want to boot from the USB drive or CD-ROM containing the Fedora Live installation you have at hand.  For this, the instructions will vary from computer to computer, so we won't say much about that.

Start the installation program

Now run the Install to Hard Disk program in the System tools menu.

You can use the installation program as usual.  We'll just have to make a quick stop on the partitioning part, where we'll hold your hands.  Select Create custom layout from the options:

Partition your disk correctly

OK, now that you're you're here, continue and create the following partition layout:

1. A BIOS boot partition, 2 MB in size
2. A /boot partition (ext4 or ext2, whatever you prefer) around 500 MB in size
3. A swap partition, probably twice as big as the RAM memory in your system.
4. An ext4 partition, mounted nowhere.  You must select Fill to maximum available size
5. Another ext4 partition, mounted nowhere.  You must select the same Fill option as before.
6. Once you have done this, select the very last partition, and change it so it mounts on /.

In sum: it's very important that the last partition on disk is the / partition, and that the swap partition be at the beginning of the disk.  This is how it will look like in the end:

Now hit Next.

Continue the installation after rebooting

You can continue the installation as normal.  When the installation is done, eject the CD or USB drive, and reboot.  After rebooting, complete the Fedora post-install wizard.  Here's the product of your work:

Disable SELinux

As root, edit /etc/selinux/config and disable SELinux by changing SELINUX to disabled.  Save the file.

Then disable enforcement for the duration of your current session by running the command:

setenforce 0

Note: yes, SELinux is important.  We know.  For the time being, however, your system will require that you disable SELinux until all issues preventing the use of SELinux with ZFS are ironed out.  Maybe you can help us fix them.

Install ZFS

Since the installation of ZFS is a bit involved, we'll give you a few steps to run by hand and then a script that will take care of ZFS just fine.  The following steps you will need to run as root, so open a terminal window and run the following commands as root.

Install dependencies first

You'll need to a series of dependencies to compile ZFS, so install them first:

yum install -y git patch kernel-devel gcc zlib-devel libuuid-devel libtool automake autoconf

Clone ZFS

OK, after doing this, clone the ZFS repositories:

cd /usr/src
git clone https://github.com/zfsonlinux/spl
git clone https://github.com/Rudd-O/zfs

This should net you two directories in /usr/src containing these sources.

Add the compile script

You will need to run the following script soon.  Save the contents of that file as /usr/src/deploy-zfs:  Don't forget to make it executable.

Patch GRUB to accept ZFS root file systems

OK, now it's time to patch GRUB.  Do the following steps:

cp /sbin/grub2-mkconfig /usr/src/grub-mkconfig.in
patch -p2 < /usr/src/zfs/grub2/grub-mkconfig-zfs-support.diff
mv /usr/src/grub-mkconfig.in /usr/src/grub2-mkconfig

Tell the system to run deploy-zfs on every kernel installation

To get this step done, do the following:

mkdir -p /etc/kernel/postinst.d
ln -s /usr/src/deploy-zfs /etc/kernel/postinst.d/

Run deploy-zfs

At this point, you're ready to install ZFS.  Run it:

/usr/src/deploy-zfs

Reboot

Since the kernel-devel package is only available for the latest kernel, the ZFS modules are only going to be available on the latest kernel.  So you are now going to reboot using the latest kernel.

Reboot your machine.  When it reboots, select the latest kernel.  After boot is done, confirm that you're using the latest kernel using the commands rpm -q kernel and uname -r.

Prepare the​ ZFS pool and file systems

OK.  You have rebooted.  Good.

Remember when we created a partition that was empty initially during the installation?  Excellent.  We're going to create a pool right there.  In the following example, we assume that your root file system is mounted in /dev/sda5 and the empty space is mounted in /dev/sda4.  It would be a good idea to check this fact with the mount and parted commands before you proceed.

Create the storage pool

Run the following commands:

zpool create pool -m none -o ashift=12 /dev/sda4

The -m none parameter tells the pool to not mount itself anywhere.  The -o ashift=12 parameter is optional, but it will make your pool perform better on advanced-format 4K sector disks (like SSDs and big hard disks).

If you did it right, you should be able to do the following and see a screen similar to this:

Create the root file system, along with other file systems

Strictly speaking, this step is optional.  You could use your pool exactly as it was when it was created.  However, it's a good idea to follow the next step because it allows you to carry multiple operating systems and system directories in your pool more easily, so it's recommended.

zfs create pool/ROOT
zfs create pool/ROOT/fedora

You should see something like this, after listing them:

pool/ROOT/fedora will be your root file system.  Feel free to create as many file systems underneath it as you would like, now.  pool/ROOT/fedora/home, pool/ROOT/fedora/var, go wild like this:

zfs create pool/ROOT/fedora/home
zfs create pool/ROOT/fedora/var

Note: there is an exception to this.  Remember that /usr cannot be an independent file system for now -- you can create it and set its canmount property to no, then create child file systems with canmount=yes within /usr, but you cannot directly mount any file system on /usr without your system breaking completely.  This issue will be addressed in the future by the ZFS team.  In the meantime. /usr must be available as part of the root file system.

Set optional properties on the pool

This is an optional step.  Now is the best time to set properties like compression or no access time updates on your pool.  If you have a decent CPU, compression will give you higher performance, especially with slower disks.  Disabling access time recording gives an extra boost.  This is the moment to set them:

zfs set compression=on pool
zfs set atime=off pool

OK.  Now every byte hitting your pool will be compressed.  Nice space savings!

Export the pool and reimport it with an alternate root

Run the following commands:

zpool export pool
zpool import -o altroot=/sysroot pool

This will make the ZFS system mount any file systems within the pool in /sysroot.

Mount the file system that will be the destination for your operating system

Set the mountpoint property on the root file system for your operating system:

zfs set mountpoint=/ root/POOL/fedora

Your file systems will now look like this:

Migrate and configure the operating system

Copy the operating system to /sysroot

The next step is straightforward and it only requires waiting a bit:

rsync -axv / /sysroot/

Note the slash in the end of /sysroot/!

Populate /dev

You'll need the device files too:

rsync -axv /dev/ /sysroot/dev/

Chroot into the /sysroot file system

That's it.  Use chroot to enter that directory as if it was the root.

Mount /boot, /sys and /proc

mount -t proc proc /proc
mount -t sysfs sys /sys
mount /boot

This is how your system should look like after mounting these file systems.

Edit fstab to fix the root file system

Now you'll be editng the root file system entry in fstab.  Edit the file /etc/fstab, and change the line that mounts / as follows:

pool/ROOT/fedora / zfs defaults 0 0

You may want to replace defaults with noatime for higher performance.  This is how it should look like:

Redo GRUB configuration

We will be using the special grub2-mkconfig that we patched earlier for this.  Run the following command:

/usr/src/grub2-mkconfig | tee /boot/grub2/grub.cfg

Your screen should look a bit like this.  Note the root=pool/ROOT/fedora parameter!

Regenerate the initial RAM disk

OK, now it's time to regenerate the initial RAM disk.  The following command accomplishes that:

dracut -f /boot/initramfs-`uname -r`.img `uname -r`

Ignore the errors it gives you about no such dataset.  These are temporary error messages because you are in a chroot.

Unmount mounted file systems inside the chroot, and exit the chroot

Clean up your chroot, and exit it.

umount /boot
umount /sys
umount /proc
exit

Export the pool

To ensure a clean system, export the pool now.

zpool export pool

If this process hangs, just wait thirty seconds, and then hard power off your machine.  ZFS won't lose a bit because of this.

Reboot

Reboot your operating system.  The system should boot normally.

Confirm that your system is now using ZFS as the root file system

Run the mount command.  It should show you the following, confirming that ZFS is now your root file system, and everything works normally:

Enlarge the pool to take the unused space up

The last and final step is short and sweet.  It involves nuking the ext4 partition and enlarging the ZFS partition to take up the empty space.  We'll show you how to do that right now.

Nuke the ext4 partition

Open parted on a terminal as root.  Follow these steps:

• Remove partition 5: rm 4
  This is the ext4 partition we created earlier that was mounted on /.
• Resize partition 4 to take up the newly freed space:
  • Change to sectors unit: unit s
  • Show the list of partitions: p
  • Make a note of the starting size of partition 4, and the total size of the disk.
  • Remove partition 4: rm 4
    Ignore any errors.
  • Create a new partition: mkpart.
    • Give it no name.
    • Set its type to ext4 (doesn't matter, really).
    • Set its starting point to the old partition 4's starting point.
    • Set its ending point to the size of the disk in sectors minus 1.
    • Ignore all errors.

After all the changes, parted should look like this:

Reboot your machine now.  As long as the starting sector of the ZFS partition remains unchanged, ZFS will be unfazed by this change in partitions.

Enlarge the pool

After the reboot, run the command:

zpool online -e pool /dev/sda4

Once you have done that, the pool will have gobbled up the new space in the bigger partition.  Look:

That's it!

And that is it.  That is really the end.  You have a system that runs ZFS and boots from it.  Great job!

From now on, every time you update the kernel, the deploy-zfs script will be run right after the new kernel is deployed into place, allowing you to boot updated kernels with ZFS just fine.  In the future, the ZFS on Linux project will release more enhancements to get your system up and running with the latest version of ZFS without compilation.  For the moment, your system is going to do fine.  Make sure you update with git pull the spl and zfs source trees from time to time!

Good luck, and happy hacking!

Huge thanks to @shiinee for helping me with test-driving the entire process and documenting each step!

This article was culled from How to install Fedora on top of ZFS.

The reality is that, today, ZFS is way better than btrfs in a number of areas, in very concrete ways that make using ZFS a joy and make using btrfs a pain, and make ZFS the only choice for many workloads.  Even in single-disk laptop or desktop configurations, ZFS has a number of advantages over btrfs that will make your life much easier.

Here, I will examine in detail all the ways in which ZFS is better than btrfs.  Fundamentally, all of these advantages are practical consequences of user-centered design decisions that -- while technically possible to implement in btrfs -- were completely absent during the conception of btrfs.  We can only hope that, with a bit of luck, the btrfs developers will eventually fix these problems and produce a superior file system.

For the record, everything I've discussed here is available for Linux, both as the ZFS on Linux project and the ZFS-FUSE project as well.

ZFS organizes file systems as a flexible tree

btrfs does not allow you to organize subvolumes.  Subvolumes appear where you created them (whether through creation or snapshotting), and you can't move or rename them.  That's it.

ZFS organizes file systems within a pool as a flexible tree.  Of course -- just like with btrfs -- when you create a file system, the file system you created is always a child file system of another file system.  But you can rename and move them around freely, and you can reconfigure how they attach to your VFS anywhere, including points outside of the mount point where the pool was attached originally.  Also, snapshots do not attach themselves to the VFS automatically.

What do these facts allow you to do?

• You can organize your ZFS file systems in a tree, separate from snapshots themselves.  This comes more naturally because the VFS is already a tree.  You can't do that with btrfs.
• You can mount a ZFS file system without mounting its children.  What's more, mounting a ZFS file system with its children, whether they are file systems or snapshots, doesn't force you to see the children mounted underneath -- you can have the children be mounted somewhere else.  With ZFS, you choose where a file system is attached to the VFS tree; the initial mount point of the file system does not bind your wishes in any way.
• You can apply operations to an entire tree of file systems at once.  You have to apply those operations separately to each btrfs subvolume.
• You can set policy for an entire subtree of file systems at once.  You have to manually set policy for each btrfs subvolume.
• You can manage usage of disk space hierarchically.  You can't even view per-subvolume disk space usage on btrfs.
• You can view the entire tree of all active pools on your system with a single command.  With btrfs, you have to first discover which btrfs file systems are mounted, and then use one command per tree, which may not show you the entire tree (e.g. if you have mounted a subvolume rather than the root subvolume).

At first glance, these may sound like whining about "the way btrfs does things".  But all we have to do to understand they really are not, is ask ourselves: hy are these ZFS affordances important?

Because they allow you to discover, manage and tune data storage and organization with very little effort.  Sure, if you have two subvolumes vs. two ZFS file systems, it's not that important to have them organized in a tree, but if you have two hundred, then suddenly the ability to operate on whole swaths of file systems becomes vital.  And there are very good reasons you might want to have lots of file systems:

• Separating data according to security policies.
• Giving different quotas depending on the directory.
• Segregating data according to policy, churn, backup lifecycle, et cetera.
• Giving each user his own home directory.

These are all things you might want to do, but you'd have to ponder whether it is worth doing given the added effort to do them.  ZFS makes it effortless to use these features, without adding any additional work for you.  Thus, ZFS makes it possible to do what you want, whereas before with btrfs you would have said "naaah, that's too much work for very little benefit".  In this sense, ZFS offers advantages that make btrfs look as cumbersome as LVM in some scenarios.

File system operations in ZFS can apply recursively

Want to snapshot a ZFS file system and all its children together?  It's one command.  You can snapshot fifty or five thousand file systems this way.  Not possible with btrfs -- the snapshot operation applies exclusively to the file system you snapshotted.  If you have / and /var is a subvolume of /, snapshotting of / does not snapshot /var with it.

Want to relocate a subtree of twenty file systems into a new mountpoint?  Again, one command changing one property accomplishes it.   Not possible with btrfs.

Want to backup a specific subtree or mirror it to another machine?  No problem.  Again, one command.

You can't do any of these things with btrfs.  Which means you will think twice about creating many btrfs subvolumes.  Which means you won't benefit from the advantages of btrfs subvolumes as much.

Policy set on ZFS file systems is inherited by their children

One powerful feature of ZFS file systems is that any property set on it -- including the mount point -- will inherit to its children by default.

Say you want compression on all your file systems but a specific one.   No problem -- enable it on the root and disable it on the one you don't want to compress data.  You can even set different compression algorithms, and the policy will inherit properly.  You can't do any of that with btrfs.

You want to relocate a specific subtree of file systems somewhere else?  No problem -- change the mountpoint property on the parent of all those file systems, and ZFS will remount the parent in the new location, and all its children inside the new location too.

ZFS auto-mounts file systems by default

btrfs does not automatically mount file systems.  For each subvolume you create, you have to register it in the fstab so it is mounted on boot, unless it's a direct child of a mounted subvolume -- in which case you can't change its mount point!

This is not needed with ZFS.  ZFS automatically mounts each file system based on the mountpoint property assigned to it.  Since the mountpoint property is inherited too (but overridable), all child file systems are mounted at the right place as well.

This means you can forget about having to change fstab with ZFS, if you so choose.  Creating a file system?  No problem, ZFS will mount it in the right place.  Destroying a file system or a whole subtree?  No problem, ZFS will unmount them for you.  Relocating a file system subtree to another graft point in your VFS?  Easy peasy -- change one property in one file system and you're good to go.  At no point will you be required to change fstab or issue many mount and umount commands.

Of course, you can override that.  You can relocate specific portions of your ZFS tree of file systems to a different mountpoint.  Simply adjust the mountpoint property on the file system you want to move, and ZFS will unmount it and remount it in the new destination directory.  If the file system has any children, they will also be unmounted and remounted as subdirectories of the new location.

Heck, with the built-in dracut and systemd support in ZFS (my tree contains it), you can even boot your operating system on a ZFS file system root, and you won't have to register any file system (except perhaps for the root one) in fstab.  Using my tree, systemd will automatically take care of discovering all pools and mounting all file systems on boot, in the correct order (even if you have other file systems in fstab) and in parallel.  And yes, root file system on ZFS works fine.  You can kiss maintenance of fstab goodbye.  I have written a guide to do exactly this.

And, if you don't like this, you can even tell ZFS that certain file systems are legacy and should not be mounted automatically, then use fstab for them.

Not having the auto-mount feature or inheritable mountpoint properties in btrfs, again, means that managing many subvolumes is cumbersome at best.  Which means you won't take advantage of subvolumes in practice.

ZFS tracks used space per file system

btrfs cannot show you how much disk space is being referred to by each subvolume, as its used and free space tracking is only per pool.  The only way to see how much space a particular subvolume is taking is to use du, which gets slower the bigger the subvolume gets.

ZFS can, and it will do so instantaneously, regardless of the size or amount of your filesystems.  The command zfs list will show you how much disk space is being referred to by each dataset, by its snapshots, and by all child snapshots of the dataset.

This is good because you can designate different areas or categories, mounted at different points of the VFS structure, and then rapidly see which ones are taking the most space and how intensive is the "churn" (change in time), simply by visually comparing the used space with the used space of previous snapshots of your datasets.  Want to know how much space your /var is taking?  As long as you created it as a ZFS file system, no problem -- it will be instantaneous.  Want to know how much its data has changed since the last snapshot?  zfs list will tell you that.

Suppose you have:

pool/shared
pool/shared/Movies
pool/shared/Music
pool/shared/TV shows

A single zfs list command will let you know, instantaneously:

• How much disk space you have free
• How much disk space Movies, Music and TV shows take
• How much disk space the whole of pool/shared takes
• How much disk space is being used exclusively by pool/shared but not by any of its children
• How much disk space the snapshots of each one of those file systems are taking

In a very easy to read list.

This is made possible because of the "virtual memory-like" DMU abstraction layer in ZFS.

Oh, I almost forgot: df actually does work properly with ZFS file systems.

ZFS distinguishes snapshots from file systems

btrfs pollutes the file system namespace by keeping snapshots and file systems in the same location.  A snapshot appears as a "copy-on-write" (and writable!) directory which is a sibling of the directory containing the subvolume you just snapshotted.  What happens if you don't like that, or you would like the snapshot to be invisible to users?  What happens is that you're screwed -- you can't prevent that from happening.  Cue ten /home directories!

In contrast, ZFS intelligently separates snapshots from file systems, which makes it possible for ZFS not to list them by default, or to list them separately from file systems.  The name of the snapshot is distinct and separate from the name of the file system that was snapshotted.  ZFS also doesn't auto-mount snapshots or allow modifications to it, unless you request otherwise.  To get the snapshot to be writable (which you presumably might want in certain circumstances), you have to explicitly clone it into the file system namespace.

This lack of clutter makes ZFS more efficacious for you to manage large numbers of snapshots with large numbers of file systems, and less likely for you to touch data you snapshotted for backup purposes.

ZFS lets you specify compression and other properties per file system subtree

btrfs only lets you specify compression for the whole pool, or for individual files, or for specific file systems (and only as a mount option).  ZFS lets you specify compression as an intrinsic property of a file system.  Of course, coupled with property inheritance, this means you can compress a whole subtree, or compress the entire pool but for a specific subtree, with one or two commands.

Same goes for every other file system tuning option, like the block size for I/O or mount options like noatime.

ZFS is more stable

ZFS has simply had orders of magnitude more testing.  It was written as a user-space program to begin with, and it's runnable for testing purposes as a user-space program, which means that fast automated testing was there from day one.

ZFS has RAIDZ

btrfs has nothing equivalent to RAID5.  You can only do RAID10, RAID1 and RAID0.  ZFS has them all plus a RAID5 implementation called RAIDZ that is invulnerable to the write hole problem (which will make you lose your entire array under certain circumstances).

ZFS has send and receive

ZFS lets you mirror an entire pool or subtrees of that pool by incrementally transferring changed data between snapshots.  btrfs does not have that yet, though it's in the works.  It remains to be seen if btrfs's implementation of send and receive will be as easy to use as ZFS's implementation is -- judging from current facts, it is unlikely.

ZFS is better documented

There is a wealth of documentation on ZFS.  Its man pages are impeccable and explain very well what ZFS is, the core concepts, how they relate with each other, and details on the behavior of each command.  The documentation is written in such a way that you don't have to piece facts together to get a comprehensive view of the whole subsystem, and you won't have as many doubts as to the effect of each action you take.

ZFS uses atomic writes and barriers

Every write in ZFS is an atomic transaction, because ZFS makes use of barriers to complete transactions.  This prevents reordering of writes that might cause inconsistencies due to incomplete writes.  This also makes it unnecessary to disable the disk write cache, an operation that would reduce your disk subsystem write performance substantially.

You can yank the power cord of your machine -- you will never lose a single byte of anything committed to the disk.  ZFS is always consistent on disk, and never trusts any faulty data (that might have become damaged because of hardware issues).  This is why people say ZFS requires no fsck to check for consistency, and faulty data never causes kernel panics.

We do not yet know with certainity if that is the case with btrfs, but -- unlike with ZFS -- we do know of many btrfs pools that have gone bad, and of btrfs inconsistencies that have caused kernel panics.

ZFS will actually tell you what went bad in no uncertain terms, and help you fix it

ZFS includes an administrative function in zpool status, that will let you check the status of your pool and its component devices.

This command will list any damage that your pool has sustained, the type of damage (read, write or checksum error), and which device suffered the damage.  In addition to that, ZFS will tell you if you actually lost any data due to the damage, and which files were lost.  If no data was lost as a consequence of the damage, because ZFS managed to repair the damage, ZFS will tell you "everything is okay, I have repaired the data, but this device is still faulty".

The same command will also tell you which devices are online, offline, faulted, and spares for your pool.  If any device is offline or faulted, ZFS will explain why (because of absence of the device, deadlock, or too many errors detected from the device).

Finally, ZFS will give you helpful hints right there in the command line, informing you of the best course of action and linking you to an extended explanation of what happened.

btrfs has nothing of the sort.  You are forced to stalk the kernel ring buffer if you want to find out about such things.

ZFS increases random read performance with advanced memory and disk caches

Unlike btrfs, which is limited to the system's cache, ZFS will take advantage of fast SSDs or other fast memory technology devices, as a second level cache (L2ARC).  This cache is very effective because it is geared toward serving random reads at very high performance (so large streaming reads won't evict or trash other hot objects in the cache).

The L2ARC also cooperates with the very effective ARC (adaptive replacement cache) in main memory, to prevent unnecessary data duplication and to keep the hottest data in the fastest location.  Finally, the L2ARC won't destroy your cache device with unlimited writes -- write speeds to the L2ARC are judiciously limited so the memory cells in your cache device won't sustain inordinate wear.

btrfs has nothing even remotely close to this.  You want to cache a large working set being consumed by random reads, but you don't have a machine that will accept 256 GB RAM?  Sorry, you're out of luck.

ZFS increases random and synchronous write performance with log devices

ZFS has the ability to designate a fast SSD as a SLOG device.  This SLOG device lets clients complete synchronous writes instantaneously and return to the clients immediately, without bogging down the main disks (which would be slow under any copy-on-write file system because of random seeks).  After a short period, the transactions committed to the SLOG device are committed to the rotating disks in streaming fashion.  The SLOG device is, effectively, a very effective mechanism to commit a huge volume of small synchronous transactions, which would destroy IOPS performance, in a sequentialized fashion.

btrfs?  Nothing like that there, move along.

ZFS supports thin-provisioned virtual block devices

Virtualizing a large number of machines?  Testing other file systems?  Consolidating many machines in a single storage unit?

No problem.  ZFS (in its ZFS on Linux incarnation) lets you allocate block devices called ZVOLs backed by portions of your pool.  ZVOLs are thin-provisioned, so you can create any number of them, and create any kind of file systems on top of them.  TRIM commands from clients using those volumes release unused space on the ZVOLs back to the pool, so you can continue enjoying the advantages of thin provisioning.  What's even better, ZFS will let you share ZVOLs using iSCSI, no extra configuration or mucking around with configuration files required.

Of course, all of the benefits of ZFS (including deduplication, snapshotting, and incremental send/receive) are available to be used with ZVOLs.  A client of a ZVOL writes a sector -- whether iSCSI, or a VM, or a local file system created on top of the volume -- and that sector will get compressed, deduplicated, and backed up using your established snapshot and send / receive policy.

To even come close to this kind of thing on btrfs, you would have to create big-ass qcow or other block storage backing files, then turn them into block devices using iSCSI or other technologies like qemu.  Which means that every disk read or write incurs an extra 2 context switches.  And don't forget the editing of configuration files...

ZFS helps you share

Sharing data?

No matter the mechanism, ZFS will help you there.  ZFS will share, upon your request, file systems over CIFS (SAMBA), NFS or iSCSI without any special kind of configuration:

zfs set sharesmb=on pool/shared/Movies
zfs set sharenfs=on pool/shared/Movies
zfs set shareiscsi=on pool/virtualmachines/fedorarootfilesystem

btrfs can't do that.  You must manually alter daemon configuration and reload services if you want to share something.  ZFS does it automatically for you.

Don't be a misanthrope.  Share!

ZFS can save you terabytes by deduplicating your data

Yes, it's memory-hungry, and yes, it can reduce your write performance a bit.  But at least you can use it.

btrfs?  Nope.

Some of this information was culled from the ZFS Gentoo overlay FAQ.  Many thanks to Richard Yao.

This article was culled from How ZFS continues to be better than btrfs.

Here are the steps to work around that:

• Download this file: http://people.canonical.com/~diwic/temp/alsa-hda-diwic-asus-g73jh-dkms_1.0.23.diwic_all.deb
• Unpack it using ark or some other archiver.  Inside of it there will be two files:
  • control.tar.gz
  • data.tar.gz
• Unpack data.tar.gz in a temporary directory.  You'll note a directory usr was created
• Inside that directory, there is a src/alsa-hda-diwic-asus-g73jh-1.0.23.diwic -- move that alsa-hda... directory into /usr/src, and change its ownership to root using chown -R
• Inside that directory which you just moved to /usr/src, there is a dkms.conf file with an OBSOLETE line -- bump the version number in that OBSOLETE line to 3.99.1 or something high
• Install the dkms RPM using yum install -- also install the RPM called kernel-devel
• Now run the command dkms add alsa-hda-diwic-asus-g73jh/1.0.23.diwic
• Now run the command dkms install alsa-hda-diwic-asus-g73jh/1.0.23.diwic
• Now let's test -- to test, kill all applications using the audio devices (like PulseAudio), rmmod snd-hda-intel snd-hda-codec-hdmi snd-hda-codec-realtek, modprobe snd-hda-intel and start PulseAudio or other audio playback applications again.  Play some audio -- you should hear and feel the subwoofer playing now
• Reboot to the same kernel (or redo the procedure above for the newer kernel you just rebooted into), and your audio drivers should have enabled the subwoofer

This article was culled from Does the subwoofer in your ASUS laptop not work under Fedora?.

Here are the steps:

Keep cron jobs in check

Check your crontab, /etc/cron.hourly and /etc/cron.d directories. Neutralize or modify any cron jobs that take place more than one time a day, so they happen at the same time.

Check for daemons that do periodic scans

Make them defer their scans for later, or configure them so they scan all together at the same time.

Disable unnecessary daemons

Self-explanatory.

Mount all your filesystems noatime

For regular filesystems, you can set mount option noatime in fstab. For ZFS, a zfs set atime=off poolname command will accomplish the same.

Find files modified in the last day or so

Now that you have no reason to worry about access time updates causing disk writes, you can issue this command:

find / -mmin -1

This find command will give you an idea of what files have been modified in the last day. Check for on-disk directories or files that are modified recently (in other words, ignore anything coming from pseudo-filesystems like /dev, /proc or /sys). We'll be moving them to flash storage.

Relocate directories and files to non-rotating media

Get a cheap USB drive (does not need to be big) and format it as ext4 (technically, you could set up another ZFS pool there too). Then, set it to be mounted in /var/volatile on your fstab.

You can now move directories that contain frequently modified files there. After you're done moving those directories, you can symlink them from their original location. So, for example, you would move /var/log to /var/volatile/log, then creating a symbolic link to /var/volatile/log named /var/log.

At this point, it would be wise to make a cron job to nightly back the contents of this USB drive up (think rsync -a) to a backups directory somewhere in your pool.

OK. If you've moved the most frequently modified files to /var/volatile, your disks will be idle unless you are actually using your file server. Now it's time to take advantage of that idleness.

Finally, tell your disks to power off when they're idle

In your /etc/rc.d/rc.local file, you can add one of these commands for each one of your rotating disks (sda, sdb...):

hdparm -S 120 /dev/sda

The -S 120 parameter tells the disk to go to sleep every ten minutes. So, if nothing has read or written to the disk for ten minutes, the disk will enter a non-rotating, very low-power mode.

This article was culled from Tip: letting your ZFS pool sleep.

That is: become root, then link the library into /usr/lib64/kde4

This article was culled from Does your Adobe Flash Player icon in the KDE System Settings malfunction?.

This article was culled from Does your wireless (WiFi) network connection glitch / stop / interrupt every two minutes?.

That's it.

Now what is it?  What does it do?  How does it work?

OK.  Let's explain in English.  You put these five rules in your iptables table filter (the default table).

1. The first rule tells the system:
   TCP packets are going to come in, that will attempt to establish an SSH connection.  Mark them as SSH.  Pay attention to the source of the packet.
2. The second rule says:
   If a packet attempting to establish an SSH connection comes, and it's the fourth packet to come from the same source in thirty seconds, just reject it with prejudice and stop thinking about it.
3. The third and fourth rules mean:
   If an SSH connection packet comes in, and it's the third attempt from the same guy in thirty seconds, log it to the system log once, then immediately reject it and forget about it.
4. The fifth rule says:
   Any SSH packet not stopped so far, just accept it.

And that's all.  You may want to change your network interface (-i eth0.103) to the public-facing network interface in your computer / server.  You may also want to adjust the number of seconds and hitcount to your tastes.  Remember that the second rule has a hitcount that is one higher than the ones following it -- this is a precaution to stop the packet from continuing down the chain of rules, so brute forcing won't spam your logs.  Spamming your logs may not be a problem to you, but it is a problem in my environment because the server literally speaks attacks out loud.

This article was culled from A better way to block brute force attacks on your SSH server.

For a blow-by-blow feature comparison against the 3GS, go here.

Edit: and the promo video is to die for!

This article was culled from Nokia N900: check it out on this video..

1. You uninstall a product.
2. Plone detects this, and to prevent malfunctions, any of the content types in the product get registered in a secret exclusion list.  Whenever the navigation is shown, this list is consulted so as to not make Plone fail because the type of the uninstalled objects can't be found.
3. You install the product again.
4. Items remain in this secret list, and do not get removed no matter how hard you tinker with the Navigation control panel.

The solution is to remove the excluded content types in the portal_properties folder of your Zope Management Interface:

1. Open your ZMI.
2. Browse to portal_properties within your Plone site.
3. Go to the Properties tab and look for the list parentMetaTypesNotToQuery.
4. Remove the content types that got added there.

That's it!  Now, why isn't this documented somewhere?

This article was culled from Help! I uninstalled a Plone product, reinstalled it and now some of my content doesn't show up in the navigation!.

* Thu Dec 11 2008 Warren Togami <wtogami@redhat.com> - 2.0.22-1
  - Show good names in Session menu
  - Use and write to user .dmrc
    It is now possible to set a default session that is not GNOME.
    Set LDM_GLOBAL_DMRC=/etc/ltsp/ldm-global-dmrc in lts.conf
      and specify your choice in /etc/ltsp/ldm-global-dmrc on the server.

I wanted to understand how a file in the server filesystem, not exported via NFS to the client, gets to affect the configuration of the terminal itself.

My first look was inside the ldminfod RPM package -- a companion package to the LDM greeter that goes in the terminal and serves some information the terminal needs to display to the user on the greeter.  Since that file is distributed inside the ldminfod RPM package, that was the logical step, right?  But said file does not appear to be read by the ldminfod on-demand xinetd daemon, so I was left stumped and wondering where and how it's read.

In case you wanted to know, it's read by the terminal client itself upon LDM login, when it's time to set up the desktop session, in the script /opt/ltsp/i386/usr/share/ldm/rc.d/X50-dmrc-processing.

The way that the script works is rather convoluted (I would have expected the LDM info daemon to give out the information in the file to the LDM greeter).  The script specified in /var/lib/tftpboot/ltsp/i386/lts.conf in the variable LDM_GLOBAL_DMRC (which defaults to the file name in the first paragraph) is copied via scp to a temporary location into the terminal memory, along with the .dmrc of the user.  Those files are then merged, and finally a decision on desktop environment and language is made upon the merged content of those files.

How did I discover this?  Thanks to the audit subsystem.  I set a watch on the file of interest, and watched it be fetched by the terminal when I logged on to it.

I admit: this scp shenanigan is rather ingenious.  However, unless having a user .dmrc is so important, I think it's overengineering; in my humble opinion, the LDM info daemon should export that information instead; after all, it's just security-insensitive defaults.

In fact, this whole LDM_GLOBAL_DMRC problem could be easily bypassed if LTSP simply obeyed the global terminal server configuration.  I don't see why I should need to specify a default language in a separate file, when that default language has already been specified in the system configuration via the LANG environment variable.  I also do not see why I should need to specify a default desktop environment, when that information has already been specified via distribution methods -- just run whatever gets me the session that I use when I logon locally and that's it!

For example, in Fedora, you just launch the Xsession script with the name of the desktop session that you want to run.  Which is, all in all, what the terminal ends up remoting via SSH on the server, so the session piggybacks to the client display.  The whole thing could be done by serving a "default" session line in the LDM info daemon output before all the lines of the other sessions, and serving the default language as the first line as well.  Then LDM can use the first choice of language as the default language, and the default session gets to be the default system session.  It would all work integrated with the Fedora X Window System client startup subsystem.

This article was culled from Arcana of /etc/ltsp/ldm-global-dmrc.

Starting up PulseAudio on boot

Put this text in the file /etc/event.d/pulseaudio:

start on runlevel [2345]
stop on runlevel [016]

exec pulseaudio --system --realtime --log-target=syslog

respawn

description "PulseAudio system server"

pre-start script
	for a in `seq 60` ; do
		sleep 1
		killall -0 hald && killall -0 dbus-daemon && break
	done
end script

post-start script
	( sleep 1 ; paplay /usr/share/sounds/login.wav ) &
end script

The text in italics is optional -- either don't include it, or replace it with something that will play a sound file confirming that PulseAudio has started.

As you can see, this is a straightforward script that waits until hald and D-Bus are active before starting PulseAudio (both are needed to get the hardware list), and then starts it up.

Setting up default client settings

Add these lines in the file /etc/pulse/client.conf:

default-server = /var/run/pulse/native
autospawn = no

Allowing users access to the audio service

Add every user that is allowed to use the audio device to the group pulse-access.

Allowing PulseAudio access to Bluetooth

In order to pair up with Bluetooth devices, you need to add the following text to the file /etc/dbus-1/system.d/pulse.conf:

<!DOCTYPE busconfig PUBLIC
 "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
	<policy user="root">
		<allow own="org.pulseaudio.Server"/>
                <allow send_destination="org.bluez"/>
                <allow send_interface="org.bluez.Manager"/>
	</policy>
	<policy user="pulse">
		<allow own="org.pulseaudio.Server"/>
                <allow send_destination="org.bluez"/>
                <allow send_interface="org.bluez.Manager"/>
	</policy>
	<policy context="default">
                <deny own="org.pulseaudio.Server"/>
                <deny send_destination="org.bluez"/>
                <deny send_interface="org.bluez.Manager"/>
        </policy>
</busconfig>

Preventing PulseAudio from starting on graphical logon

A pesky program tries to start PulseAudio every time you log on, which may cause conflicts.  Prevent this by running the following command as root:

chmod -x /usr/bin/start-pulseaudio-x11

You may need to run this command whenever you upgrade your system and, in the course of the upgrade, PulseAudio itself is upgraded.

I've submitted a patch for PulseAudio that will render this step unnecessary soon, if it's accepted. It's logged as ticket 606 in the PulseAudio bug tracker.

That's it!

Close your session and reboot your machine.  PulseAudio should start on boot now, and all applications will be able to play sound, whether they are console or graphical applications, and without the need to actually log on beforehand.  In addition, if PulseAudio dies, it will be automatically restarted and you will hear a confirmatory sound (provided you actually put the italicized text with a command to play audio).

This article was culled from How to make PulseAudio run once at boot for all your users.

Here, we'll learn how to set that up with Fedora 11 -- with the advantage that this solution works with PulseAudio just fine.  Users of other distributions may adapt these instructions to their packaging and configuration.  We assume, of course, that you don't have a home theater installed in your system -- rather, you only have a set of headphones plugged into your stereo or sound card.

Step 1: install the requisite software

Launch your software installer tool and look for a package named alsa-plugins-vdownmix.  Install it.  For those of you who like to use the command line:

yum install -y alsa-plugins-vdownmix

Step 2: set the software up

By default, this plugin comes with a neutered configuration that you have to explicitly request in your application.  This is silly.  The way we're going to set it up is rather simple: we're going to tell ALSA to disregard the standard multichannel outputs in the cards with this short ALSA configuration script:

pcm.!surround51 {
        @args [ CARD DEV ]
        @args.CARD {
                type string
                default {
                        @func getenv
                        vars [
                                ALSA_SURROUND51_CARD
                                ALSA_PCM_CARD
                                ALSA_CARD
                        ]
                        default {
                                @func refer
                                name defaults.pcm.surround51.card
                        }
                }
        }
        @args.DEV {
                type integer
                default {
                        @func igetenv
                        vars [
                                ALSA_SURROUND51_DEVICE
                        ]
                        default {
                                @func refer
                                name defaults.pcm.surround51.device
                        }
                }
        }
        type vdownmix
        slave.pcm {
                @func refer
                name {
                        @func concat
                        strings [
                                "cards."
                                {
                                        @func card_driver
                                        card $CARD
                                }
                                ".pcm.surround51." $DEV ":CARD=" $CARD
                        ]
                }
        }
        hint {
                description "Downmix to stereo 5.1 Surround output to Front, Center, Rear and Subwoofer speakers"
                device $DEV
        }
}

pcm.!surround40 {
        @args [ CARD DEV ]
        @args.CARD {
                type string
                default {
                        @func getenv
                        vars [
                                ALSA_SURROUND51_CARD
                                ALSA_PCM_CARD
                                ALSA_CARD
                        ]
                        default {
                                @func refer
                                name defaults.pcm.surround40.card
                        }
                }
        }
        @args.DEV {
                type integer
                default {
                        @func igetenv
                        vars [
                                ALSA_SURROUND51_DEVICE
                        ]
                        default {
                                @func refer
                                name defaults.pcm.surround40.device
                        }
                }
        }
        type vdownmix
        slave.pcm {
                @func refer
                name {
                        @func concat
                        strings [
                                "cards."
                                {
                                        @func card_driver
                                        card $CARD
                                }
                                ".pcm.surround51." $DEV ":CARD=" $CARD
                        ]
                }
        }
        hint {
                description "Downmix to stereo 4.0 Surround output to Front, Center, Rear and Subwoofer speakers"
                device $DEV
        }
}

 Save the contents of this script in the file /etc/alsa/pcm/vdownmix.conf (do this as root, obviously). Now we're going to tell ALSA to pick this configuration file up, by editing the file /etc/asound.conf. The original file should look like this:

#
# Place your global alsa-lib configuration here...
#

@hooks [
        {
                func load
                files [
                        "/etc/alsa/pulse-default.conf"
                ]
                errors false
        }
]

Add a new line as per this example:

#
# Place your global alsa-lib configuration here...
#

@hooks [
        {
                func load
                files [
                        "/etc/alsa/pcm/vdownmix.conf"
                        "/etc/alsa/pulse-default.conf"
                ]
                errors false
        }
]

You're finished with the setup. You can verify that the configuration has been picked up properly by running the command aplay -L on a console -- you should see the description of the surround51 definition begin with Downmix....

And that's it.  Your system is now properly set up to virtualize surround sound to your headphones. 

Now, you should know this configuration is not applied by default: PulseAudio still needs to be informed when you intend to play multichannel audio, otherwise PulseAudio performs non-spatialized mixdown of your multichannel audio.  Here's how you prevent that from happening.

How to activate and deactivate virtualization on the fly

Whenever you want to listen to multichannel audio on your headphones, you will want to tell PulseAudio to output multichannel audio on your gear.  You do this by:

1. Opening the PulseAudio Volume Control
2. Going to the Configuration tab (the last tab in the application)
3. Selecting Output Analog 5.1 on the drop-down of your sound card

This lets PulseAudio know that you have a "surround-sound capable" sound card, which makes PulseAudio relay each sound channel straight into the ALSA downmixer, which in turn mixes each channel down to the correct virtual position.

Finally: when you go back to your speakers or to listening stereo music, select Output Analog Stereo again, and the spatialization will be disabled.

And that's it!

This article was culled from How to get virtual surround sound on your headphones plugged to your Linux rig.

The stable KDE 4.2 release is a phenomenal work of art that lets every application share and modify metadata using an unified ontology, all mediated through the great D-Bus protocol.  This is known as NEPOMUK and the way it works is as follows:

• There is a daemon that starts up when your desktop environment starts.  This daemon (the NEPOMUK daemon) starts a bunch of little services -- storage backends, query server, indexer (known as Strigi).
• This daemon latches onto the D-Bus session associated with your desktop environment.  It sits there listening to queries -- they can be questions in SPARQL, or method calls to get/set specific pieces of metadata.
• The daemon mediates the job of searching the storage backends and manipulating the data.
• Applications query it through D-Bus using a standardized interface that works for full-text-search queries and other sorts of metadata-related queries.

This provides a central location which applications can access the metadata, either directly through D-Bus or abstracted through the available application libraries.  It's a rather powerful idea, since applications no longer need to link directly to metadata libraries or use ad-hoc methods like stat calls to piece together metadata for files in your computer.

Couple this with a KIO slave called nepomuksearch:, and you have live searches or data feeds for your applications.  That's right, you can put a list of files tagged TO-DO or a list of files with the word rabbit right on your desktop.

Or at least you ought to be able to.

The problem

The problem is that NEPOMUK simply does not work in KDE 4.2 as it was supposed to work.

The database technology used in NEPOMUK is called Soprano.  It was chosen because it has several pluggable backends (sort of on-disk formats).  The problem with Soprano is that its default backend (the Redland one) does not support certain query methods on its database, methods that NEPOMUK requires.  So the NEPOMUK developers decided to use the Sesame2 backend, which is feature-complete and fast enough for their needs.

One problem, though: Sesame2 is a Java library that almost nobody in the distribution world has bothered to package for almost no distributions.  And with good reason too -- most distributions require a compilation from source, while the Sesame2 backend is being distributed as a JAR file instead.

The result is clear:  nepomuksearch: (the whole point behind NEPOMUK) does not work in any distribution except perhaps for Mandriva.

And, in that manner, the NEPOMUK developers royally tied themselves up into a Gordian Knot.

The fix

...is already deployed in the latest Fedora 15 and 16, which includes KDE 4.7 and a staggering number of bug fixes to NEPOMUK.

This article was culled from KDE 4.2, NEPOMUK and Linux distributions.

How to interpret

Explanation

Conficker (aka Downadup, Kido) is known to block access to over 100 anti-virus and security websites.

If you are blocked from loading the remote images in the first row of the top table above (AV/security sites) but not blocked from loading the remote images in the second row (websites of alternative operating systems) then your Windows PC may be infected by Conficker (or some other malicious software).

If you can see all six images in both rows of the top table -- or at least the top ones, as the bottom ones seem to be DDoSed at the time -- you are either not infected by Conficker, or you may be using a proxy server, in which case you will not be able to use this test to make an accurate determination, since Conficker will be unable to block you from viewing the AV/security sites.

Detecting Conficker on your network through a port scanner

Net-Security suggests that, to scan for Conficker, you can a command such as:

 nmap -PN -T4 -p139,445 -n -v --script=smb-check-vulns --script-args safe=1 [targetnetworks]

Credits

F-Secure and the F-Secure Logo are trademarks of F-Secure Corporation.
SecureWorks and the SecureWorks Logo are registered trademarks of SecureWorks Inc.
Trend Micro and the T-Ball logo are trademarks or registered trademarks of Trend Micro Inc.
The Conficker Eye Chart is a concept by Joe Stewart. This derivative work was set up to help Joe Stewart's efforts.
Copyleft 2009.

If this machine survives the current hundreds-of-hits per second traffic storm, consider GPLHost for your next Web service venture (I'm using a 768 MB RAM VPS).  And, for your next consulting need, consider me.  Back in the day, I used WordPress; today, I use Plone.  So far, I seem to know what I'm doing to serve big traffic, and I hope you'll let me do that for you too.

This article was culled from Conficker eye chart -- reloaded. Also known (in the great tradition) as: Spread this chart.

Before anybody accuses me of using a beta for this rant, bear in mind that the rest of the KDE 4 applications in this system are functioning correctly.  Of course, if you want to skip the rant, click here for the solution.

The launch -- failure #1

I launched Amarok 2.

No cookie.  It didn't even launch -- it ended with a SIGSEGV after an St9_bad_alloc C++ exception.  What could be going on?

Turns out it was my security configuration.  I have my system set up to never grant more than 1 GB of RAM to any application, using the ulimit command; and for good reason too, since Kopete every once in a while decides to run away with all system memory and freeze my machine.

But this only lets me ask the question: why would a music player need to allocate in excess of one gigabyte of RAM just to start up?  I am appalled at this.  It makes me want to go back to MS-DOS .OVL files as a memory management strategy.

Well, never mind, let's increase that to 2 GB and try again. 

The import -- failure #2

This time around, Amarok launches, and presents me with a collection configuration screen.  I check the folders I had checked in the old Amarok 1 configuration, then click Import.  The importer appears -- I feed it my database information and I hit Next.  It starts importing.  This import function is vital to me, since my entire music collection habit and mobile music experience is powered by Amarok 1 statistics and other metadata like tags.

The importer takes 5 minutes to list all of my music, spitting quite a few TagLib errors on the console.  And then... it just spins.  It spins using 100% of one CPU core for twenty minutes.  I am about to terminate Amarok 2... and then the Finish button on the importer lights up.  I hit Finish.  Remember, I'm now half an hour trying to get this junk to work, and so far nothing.

Now, like any regular person, I'd expect the importer to have succeeded.  Surprise, surprise, the collection pane is empty.  Not a single song has been imported!

Drag and drop, Ogg edition -- failure #3

So, okay, maybe the statistics were imported but not the collection itself, which may need a rescan, right?

Let's move on to the file browser panel.  In Amarok 1, I had a series of bookmarks pointing to commonly accessed directories.  No such luck in Amarok 2!

That's okay, I know my way around my collection, so let's browse to an Ace of Base folder which contains several tracks I listen frequently.  Let's drag the song Beautiful life.ogg to the playlist... wait... why isn't my favorite Ace of Base song showing up in the pane?

What?  Only MP3 files are showing up!  All the Ogg files are gone!

I launch Dolphin and browse to the folder and, sure enough, the Ogg files are there!  Why would Amarok not show me my Ogg files?

OK so let's try and drag the file in question from Dolphin to Amarok's playlist... nice, the drop target shows a black bar where it's going to be inserted.  Let's release the mouse button... nothing!  Amarok plainly refuses to accept Ogg files dropped into it!

By now I'm furious.

OK, maybe at least Amarok will let me drop an MP3 file.  So I try with Angel eyes.mp3.  Sure enough, the black bar appears, and this time the file gets actually added...

Metadata fail -- failure #4

...only there's something funny about the playlist.  It doesn't show me any info except for the file name.  No album, no artist, no track, no number, no nothing!

I right-click the file and select the option to edit tags (which shows me a number of things, not just the tags).  Whaddya know?  Amarok thinks the file is zero bytes long and the only things that it shows correctly are:

1. The path to the file
2. The number of plays that song has seen

Aha.  Well, will it play the song?  Let's double-click it... and bingo, sound!

OK, so let's go fix the collection thing.  Let's request a collection update.  I do that... and boom, segfault again.  Despite that taking place, there are several amarokcollectionscanner processes running amok on my system and slowing it down to a nearly unusable crawl.

So, in the words of a friend wise beyond his years, a la verga los pastores, se acabó la Navidad.  killall -9 amarokcollectionscanner && rpm -e amarok.

The recap

1. Amarok 2 refuses to load when limited to less than one gigabyte of RAM.
2. The importer doesn't work.
3. You can't play Ogg files.
4. If you so much as sneeze, it dies and leaves mongrels that make your system unusable.

Let me remind you, the Amarok developers have the audacity to call this the second bug fix release of the second version.

If I, a Linux developer with 12 years of experience who knows his way around UNIX like the back of his hand, can't get this ersatz "music player", with elementarily dumb oversights, mistakenly shipped by the Fedora release managers as stable software, what can a regular user who just wants to play music have in the way of hope?

Now I go to the IRC channel in Freenode where the Amarok developers dwell, and voice my complaints.  They tell me to stop complaining and file bugs.  What for?  It isn't the first bug I have filed about Amarok, and bugs take months or even years to be sorted out.

This on top of a number of regressions I discovered months ago that I'm pretty sure aren't fixed yet:

1. Playlist import didn't work.  Especially if one of your playlists had a track entry that had been moved and is no longer in the collection.  In fact, you cannot even put a song outside your collection in a playlist, since the database doesn't store paths but rather IDs from songs in the collection.  So you had to manually fix all of your playlists in order to prevent data loss.  Fortunately, I scripted this task so I did do it months ago in the good faith that I would be able to use Amarok 2 some day.
   
2. Any statistics (ratings, labels, play counts, scores) for songs outside your collection is lost.  Lost.  If you have been listening to songs outside your collection folder, expect to say goodbye to all track metadata applied to these tracks.  The reason it is lost is, again, because Amarok does who knows what with the imported statistics data that used to show (not anymore!  so you can say this is a bug atop a bug!)  on the playlist when a non-collection track was first added, but gets utterly reset when the non-collection track finishes playing.
   
3. Intelligent playlists weren't imported either.  If you were feeding your iPod using one of these, bye bye.
4. There is no way to mass-edit tag information right from the playlist, something I very much frequently did when using Amarok 1.
   

Systemic failure.  That's all I can say.  A group of developers set out to write a music player that has less features than the old generation one, and has more bugs than an ant colony.  Then they code code code without any meaningful testing.  Then they ship it implying it is stable software under the banner of "we need more testers", but with no working migration path from the old version of the software, and double the hardware requirements.  Good-willed people in charge of distributing good software get duped into shipping this bag of FAIL, updating perfectly-working software already-deployed into millions of users' workstations.  And when the users complain, some people have the gall to say that we are rude.

Lenin would be proud.

If you want to accuse me of being an ungrateful son of a bitch, can that accusation.  Not only is my criticism valid in a world where you're validated by how good the results of your work is -- regardless of end-user price -- I have actually gone out of my way to provide a solution for you and help you avoid these disasters.  Scroll down.

The solution

Well, since I cannot live without Amarok 1, I decided to built it for Fedora 11.  I had to patch a number of deficiencies in the Amarok 1 source code (namely, the use of obsolete libraries and C include practices) with patches I found around the globe for Gentoo and other distributions.  It wasn't that hard, but it wasn't easy either.  The RPM packages ready to install are on The missing RPMs repository (which I do not recommend you actually add to your Yum configuration if you're using Fedora 11) and you can get them here directly:

1. Amarok 1.4.10 for Fedora 11 64 bits.
2. Amarok 1.4.10 source package to rebuild for Fedora 11 or Fedora 10 (32 or 64 bits).
   

You install them by downloading them and then using the rpm -Uvh --oldpackage command, so this package actually replaces the newer Amarok package.  After doing that, you're strongly encouraged to lock Amarok from being upgraded with yum by putting a line exclude=amarok in your /etc/yum.conf file.

Tip: if you use the Smart package manager, you can install the package using point-and-click, and it will automatically erase the newer version for you, no need for funny commands or anything.  After installing the package, lock the version of the newly installed Amarok package so it won't get upgraded in future upgrade cycles.

This article was culled from Amarok 2: a story of disappointment -- with a solution for Fedora 11.