unRAID Server Release 6.0-beta7-x86_64 Available

Download

Please see

readme.txt

in the release zip file for installation/upgrade instructions.

Disclaimer: This is beta software.  While every effort has been made to ensure no data loss, use at your own risk!

This release took a lot longer than I hoped it would.  Chief time-suckers:

- unraid driver bug existing since day 1 and exposed trying to mkfs.xfs.

- unraid driver deadlock with btrfs, due to how linux block device "plugging" changed

- numerous corner-cases getting multi-device btrfs cache pool working.

Main features in this release:

- now can use btrfs, reiserfs, or xfs for array devices

- now can assign multiple devices to the cache pool

NOTE: I know one of the first things someone is going to do is add a second SSD their cache to form a btrfs-raid1.  This works fine, but in the process of mounting the btrfs file system, btrfs detects SSD and initiates a full-device TRIM operation on the new device.  This causes webGui to appear to hang at the "Mounting..." step during array Start.  It is NOT hung - let it go - the TRIM can take anywhere from several seconds to minutes depending on type/size of your SSD.  If you look at the system log in a terminal window you will see a log entry for this.  You will see similar Mounting delays as a result of other btrfs config changes such as removing a disk.  I will fix this in beta8.

Another NOTE: After making a btrfs cache pool device config change, please click on the 'cache' link on the Main page, and then click on 'Rebalance'.  This has to be done following Mount, and I didn't build this into Mount because it would make Mount take even longer (maybe hours depending on what devices and how full they are).  Again, this will be fixed in beta8.

Yet Another NOTE: there is no "conversion" between reiserfs and xfs/btrfs (or between xfs/btrfs).  If you want to change a device format from reiserfs to btrfs/xfs, you have to move all your data off the device first, click on the device, change the file system type, and then finally Start array.  The disk will come up 'Unformatted' and you will be able to Format as new file system type.  Careful of this however: http://lime-technology.com/forum/index.php?topic=34480.0

Yes One More NOTE: Our experience with btrfs is this: it seems really solid for single-device file systems, such as using for an array device.  It's really fast too, though we don't have much experience with nearly full file systems.  Multi-device btrfs file systems are "fun" - yeah let's use that word.  So far no huge problems have surfaced in normal usage.  But we have not tested every corner case yet.  Bear in mind the btrfs developers recommend keeping up-to-date backups.  We are committed to keep up with btrfs development and will incorporate the latest linux kernel where btrfs changes occur.

Other notable changes:

- Key handling is a little different.  We now look at all the ".key" files in /boot/config directory (the 'config' directory on the usb flash).  If a Pro key is found that matches your flash GUID, then you got Pro.  If no Pro key, we look for Plus.  If no key GUID matches flash GUID, or no key files, you got Basic (free version).  Nice thing about this is that you can put all your key files for all your usb flash devices in the same directory and unRaid OS will find the right one.  NOTE: the "undocumented" feature of looking in /boot has been removed.  If your key file is in the root of your flash, you must move it to the 'config' directory.

- webGUI: added ability to configure slots on the Main page.  You can assign 25 slots pretty much any way you want (well up to 24 to array).  This is true regardless of key type.  The different key types (Basic, Plus, Pro) restrict how many total devices can be assigned.

- webGUI: added "Check Filesytem" buttons for each device.  Added some btrfs pool operations for cache pool.  BTW, a cache "pool" is defined as any configuration where 2 or more slots are assigned to cache.

Numerous other updates, bug fixes and improvements went into this release.  "Thank You" to everyone who is participating in this beta series.

One More Thing: there is now a new forum category: "unRAID OS Version 6 Support" with these boards:

- Roadmap

- Defect Reports

- Support

PLEASE post any defects you see from now on in the Defect Report board, NOT in this Announcement thread.  Note there is a "standard" template for defect reports - refer to the Guidelines post.

Finally - time to throw AFP users a bone - latest netatalk almost got in here but should be in beta8, not done with testing yet.

unRAID Server Version 6.0-beta7 Release Notes
=============================================

Please note: THIS IS BETA SOFTWARE.  WHILE EVERY EFFORT HAS BEEN MADE
TO ENSURE NO DATA LOSS, USE AT YOUR OWN RISK.

See below for Upgrade and Installation instructions.

Summary of changes from 6.0-beta6 to 6.0-beta7
----------------------------------------------
- btrfs-progs: update to 3.14.2
- docker: update to 1.1.2
- emhttp: assign any number of slots to array and cache pool
- emhttp: implemented multi-device btrfs cache pool feature
- emhttp: support btrfs, reiserfs, xfs filesystems for array devices
- emhttp: handle multiple key files in /boot/config, but no more keys files in /boot
- emhttp: add indicator for shares that only exist on the cache
- libvirt: update to 1.2.7
- linux: update to version 3.16
  CONFIG_NR_CPUS: changed from 16 to 256
  CONFIG_XFS_FS: include XFS file system
  CONFIG_XFS_POSIX_ACL: include XFS ACL support
  add "pci: Enable overrides for missing ACS capabilities" patch (for KVM vfio/PCI pass-through)
- misc: console coloring for kool kids
- php: update to 5.4.30
  add support for curl, openssl, zlib, bz2 and gmp
- qemu: update to 2.1.0
  add "Enable -cpu option to hide KVM" patch (for Nvidia)
- samba: update to 4.1.11
- shfs: fixed improper handling of cache floor
- slack: added htop-1.0.2
- slack: added xfsprogs-3.1.11
- unraid: correct overlapped I/O logic in driver; remove write-throttling algorithm
- webGui: add "check filesystem" functions on DiskInfo page.
- webGui: several misc. bug fixes

Known issues in this release
----------------------------
- emhttp: removed automatic file system expand when small drive is replaced by bigger drive.
  This will be put back in next release.
- emhttp: certain btrfs pool operations can cause mount to take a looooong time
- slack: bonding driver interaction with dhcpcd is flaky, introduced delay as workaround.
- slack: the time setting "(UTC+10:00) Brisbane" is wrong: Brisbane does not use daylight
  savings time like "(UTC+10:00) Camberra, Melbourne, Sydney".
- slack: no 32-bit executable support (a non-issue?)
- netatalk: update to 3.1.x didn't happen yet
- webGui: help incomplete; a few rough edges remain
- emhttp: any file that is world-readable is accessible via http://Tower/mnt/... (which is to say a
  file can be made non-accessible by making it non-world-readable).

Before someone brings this up (again), next release will concentrate on netatalk along with some of the "low hanging fruit" of misc. features such as native notifications.  It has lately become very important to get off 'reiserfs' for new systems and to implement redundancy for the cache pool - hence that is what we concentrated on.

Jon also has had way too much fun with GPU pass-through to VM's.  Actually it's quite amazing - look for his posts in the days to come.

Woo, I'm off to see whether Xen/nfs problem has gone away.

Oh for crying out loud, I was just about to go to bed!

Careful of this however: http://lime-technology.com/forum/index.php?topic=34480.0

Link is not available for viewing.

Careful of this however: http://lime-technology.com/forum/index.php?topic=34480.0

 

Link is not available for viewing.

Sorry about that, try it now.

I'd like to update from beta 6 to beta 7.

Can I just copy the update into my flash drive and load it up?

Will I loose all my dockers?

I'm new to unraid started with beta 6, so this would be my first update attempt.

Thanks

I'd like to update from beta 6 to beta 7.

 

Can I just copy the update into my flash drive and load it up?

 

Will I loose all my dockers?

 

I'm new to unraid started with beta 6, so this would be my first update attempt.

 

Thanks

"Please see readme.txt in the release zip file for installation/upgrade instructions."

I'd like to update from beta 6 to beta 7.

 

Can I just copy the update into my flash drive and load it up?

 

Will I loose all my dockers?

 

I'm new to unraid started with beta 6, so this would be my first update attempt.

 

Thanks

 

"Please see readme.txt in the release zip file for installation/upgrade instructions."

Oh didn't see that!

Thanks

Should there be a new topic button in the new 6.x support forum?  I had a config question, but I noticed none of the new forums allow posting a new topic.

It has lately become very important to get off 'reiserfs' for new systems and to implement redundancy for the cache pool - hence that is what we concentrated on.

That's an eye opener!  Any specifics?  Links are fine, I'd rather you spend more time coding than forum typing

Woo, I'm off to see whether Xen/nfs problem has gone away.

Please test quickly and let me know

Woo, I'm off to see whether Xen/nfs problem has gone away.

 

Please test quickly and let me know

I too am interested if this fixed the Xen network problem.  I'm out of town and can't try it myself.

I'm eager to hear others feedback on the Xen networking issues.  This beta encompasses some fixes for Xen from the 3.16 kernel and we believe some network-related patches for Xen were included as well.  My main ones are the SKB rides the rocket error.  Curious to see if anyone else experiences that still after this beta.

I'll try it myself here soon.  I can always revert.  PS is there a known way to replicate? I never went to beta6 myself.  Us it just heavy VM network activity like a few torrents?  I can do that easy.

I'll try it myself here soon.  I can always revert.  PS is there a known way to replicate? I never went to beta6 myself.  Us it just heavy VM network activity like a few torrents?  I can do that easy.

In my case it was just heavy network traffic to an Owncloud VM.

Woo, I'm off to see whether Xen/nfs problem has gone away.

 

Please test quickly and let me know

Initial signs are good. Beta6 failed within five minutes every time I tried it.  Beta7 uptime has already comfortably exceeded that and no problems so far.

I have an ArchVM running deluged with several active torrents, and minidlnad serving photos to a digital photoframe, plus a few other daemons.

The rocket-riding seems to have stopped, too!

Tom, can you elaborate on this one ...

- emhttp: removed automatic file system expand when small drive is replaced by bigger drive.

Does this mean that if you are upsizing a disk, say from 2T to 4T, the 4T would continue to be limited to 2T? Can it be manually expanded? Will beta8 detect this condition and auto-expand any replaced disks? Would you advise users to boot back into 6b6 to do the replacement?

Somewhat related - if you add a btrfs or xfs disk in 6b7, can you boot back into 6b6? (I realize the XFS and BRTFS disks would appear unformatted and their contents not accessible, but would parity be maintained and therefore ability to do a disk rebuild?)

Should there be a new topic button in the new 6.x support forum?  I had a config question, but I noticed none of the new forums allow posting a new topic.

Right, sorry about that.  Should be fixed.  All the new boards should function normally except for the Roadmap child boards which are like the Announcement board: anyone can post but only admin/mod can create new topics.

Tom, can you elaborate on this one ...

- emhttp: removed automatic file system expand when small drive is replaced by bigger drive.

 

Does this mean that if you are upsizing a disk, say from 2T to 4T, the 4T would continue to be limited to 2T? Can it be manually expanded? Will beta8 detect this condition and auto-expand any replaced disks? Would you advise users to boot back into 6b6 to do the replacement?

Code used to just do an unconditional "resize" upon every mount, and that was not an issue because with reiserfs it just was a no-op.  But with btrfs/xfs there needs to be a little more sophistication in the coding.  I didn't want to delay beta7 another week to get this in, so left auto-resize out until next release.  If someone needs to do an expansion before beta8 I will post instructions.

Somewhat related - if you add a btrfs or xfs disk in 6b7, can you boot back into 6b6? (I realize the XFS and BRTFS disks would appear unformatted and their contents not accessible, but would parity be maintained and therefore ability to do a disk rebuild?)

Yes.

Thanks!

One more question - maybe not appropriate for this thread but will be on users' minds and your thoughts would be very helpful.

Users now have a choice of 3 file systems - RFS, XFS, and BTRFS for array disks.

Can you list, from your experience, the relative best users of each? (E.g. XFS for static disks with little data duplication, BTRFS for Backups). etc.

Which file system will you personally will be using on new disks going forward?

Update - Tom responded to similar question HERE

Has anything changed (since b5a) which would stop the fan_speed plugin working?

My fans appear to be running at full speed with no evidence of any control.

Thanks!

 

One more question - maybe not appropriate for this thread but will be on users' minds and your thoughts would be very helpful.

 

Users now have a choice of 3 file systems - RFS, XFS, and BTRFS for array disks.

 

Can you list, from your experience, the relative best users of each? (E.g. XFS for static disks with little data duplication, BTRFS for Backups). etc.

 

Which file system will you personally will be using on new disks going forward?

If btrfs was not still marked "experimental", no question I'd use btrfs for everything.  Single-device btrfs does seem solid.  Most reports you see of file system corruption are with multi-disk configurations.  More and more momentum is getting behind btrfs in the linux world and it appears will be the file system of choice in the future.

That said, for new arrays for 'production' use I would go with XFS because it's far more mature.  Maybe one array device with btrfs to store your docker containers.

reiserfs is still a viable choice.  It's works fine and the ability resurrect corrupted file systems is excellent.  The problem is that no further development is occurring with it.  For example, around release of linux 3.0 they redesigned "block device plugging".  This is the code that looks at I/O queues and lets them fill up a bit before sending down to the device drivers, in hope of being able to combine commands and/or re-order, etc, to boost overall performance.  Well reiserfs didn't get the most efficient changes for this - it works, but could be better.  The other problem is that as fewer and fewer people use reiserfs in the linux world, cases of little bugs that crop up due to kernel changes will be found/fixed slower.  Anyway, it's clear we needed to offer alternatives.

One other thing with btrfs: at present everything with shares works the same: when you create a new share, it creates a new top-level directory.  We will be adding a checkbox that says, "Instead of creating a top-level directory to define this share, create a top-level subvolume to define this share."  This will give you the ability to create share "snapshots".

Has anything changed (since b5a) which would stop the fan_speed plugin working?

 

My fans appear to be running at full speed with no evidence of any control.

No.  Please post this in the new Defect Reports board.

http://lime-technology.com/forum/index.php?board=61.0

If you are currently running 6.0-beta1/2/3/4

Might want to update this for clarity ... unless there really are different update instructions for betas 5a and 6.