unRAID Server release 4.5-beta7 available

Direct download

 

Bug fixes & linux updates.

 

unRAID Server 4.5-beta7 Release Notes
=====================================

Changes from 4.5-beta6 to 4.5-beta7
-----------------------------------

Bug fixes:
- If 'config/style.css' is not present, then don't tell browser to load it.
- Fixed kernel crash when number of drives > 17, now correctly supports up to 20 drives ('Pro' issue only).

Other changes:
- Prevent disks appearing 'unformatted' as a result of incomplete Stop Array operation.
- Add driver for Adaptec 2410SA PCI RAID card (untested).
- Upgrade linux kernel to 2.6.30.8
- Upgrade samba to 3.3.7
- Upgrade fuse to 2.8.1


Changes from 4.5-beta5 to 4.5-beta6
-----------------------------------

Bug fixes:
- Fix ntp startup problem.
- Fix bogus temperature values being displayed when disks are spun down (bug introduced in -beta5).

Other changes:
- Permit spaces in Active Directory account login username.  Any valid AD character should now be possible EXCEPT for the percent '%' symbol.  This is because the '%' symbol is used by linux 'net' command as a separator between username and password, as in:
net ads join -U username%password


Changes from 4.5-beta4 to 4.5-beta5
-----------------------------------

New features:
- Added new share allocation method called "Fill-up".
- Added "Min free space" setting for each share.
- Special handling of split level explictly set to "0".
- The 'mover' will now delete empty directories on the cache disk.
- After looking in the 'config' directory on the Flash for the license key file (for backward compatibility), if not found, unRAID Server OS will look in the root of the Flash.  This allows easier backup/restore of the 'config' directory contents.

Bug fixes:
- Fix wrong 'memtest' in zip file - oops.
- Fix powerdown script.
- Fixed problem where drives would sometimes spin down immediately following spin up.

Other changes:
- Don't store AD adminstrator password, and don't display personal information in the system log.
- Can now use any printable characters in password strings.
- When disabling NCQ don't try to set queue_depth to 1 if it's already set to 0.
- Upgrade ntp from version to 4.2.4p0 to 4.2.4p6.  Also save/restore ntp drift file to/from Flash.
- Upgrade linux kernel to 2.6.29.1
- Support Marvell SAS driver.


Changes from 4.5-beta3 to 4.5-beta4
-----------------------------------

New features:
- Increased maximum number of array devices from 16 to 20 (Pro only).
- Pressing Power button gracefully shuts down the server.
- Disable NCQ on all disk devices that support NCQ.  This typically results in much better write throughput.  A setting called "Force NCQ disabled [yes/no]" is also available in the Disk section of the Settings page of the System Management Utility to override this new behavior.  That is, if this setting is 'yes', then we force NCQ off; if setting is 'no', we leave NCQ queue_depth as-is, ie, whatever linux driver sets it to.

Bug fixes:
- Fixed syslog rotation problem - syslog was rotated, but then syslogd was not restarted.

Other changes:
- Support SAS (Serially-Attached SCSI).
- Support Initio 162x SATA chipset.
- Support the motherboard speaker (beeping).
- Added 'lm_sensors' package.
- Upgrade Samba to version 3.3.3.
- Upgrade memtest to version 2.11 in release zip file.


Changes from 4.5-beta2 to 4.5-beta3
-----------------------------------

Known issues:
- The 'reiserfs' file system is built with kernel-option to enable extended attribute support.  This is necessary for Active Directory.  Even if file system is not mounted with extended attributes, reiserfs still seems to create a hidden file called '.reiserfs_priv' in the volume root. This file is harmless and does not appear in any share.

Bug fixes:
- Fixed problem where all Flash files appeared to have Hidden/System/Archive all set.
- Fixed upgrade problem where 'simple security' was not being initialized properly.
- After formatting a new disk, the 'File system type' was not being updated.
- If cache disk present, should allow 'use cache disk' option in creating new share.
- Fixed problem with mover not moving.

Other changes:
- Changed name of samba include file introduced in -beta2 from 'boot/config/smb.extra' to 'boot/config/smb-extra.conf'.
- Upgrade Samba to (patched) version 3.3.2.  The patch is a bug fix that prevented windows client from removing Read-only attribute (previous versions of samba 3.3.x fail with 'Access denied').
- If security model is not Active Directory don't mount the data disks with acl & extended attributes enabled.
- Prevent recording (ie, writing) 'last access time' when directories and files are read on the Flash.
- Added 'lsof' command.
- Include 'Hardware Monitoring' in the linux kernel build along with this device support:
  AMD Athlon64/FX or Opteron temperature sensor
  Intel Core (2) Duo/Solo temperature sensor
  ITE IT87xx and compatibles
  Winbond W83627HF, W83627THF, W83637HF, W83687THF, W83697HF
  Winbond W83627EHF/DHG


Changes from 4.4.2 to 4.5-beta2
-------------------------------

New features:
- Support Active Directory Service (ADS).  This lets an unRAID server join an Active Directory (AD) domain.
- System Management Utility will now use a CSS style sheet file on the Flash (config/style.css) if present.
- May now read syslog directly via browser by referencing 'http://tower/log/syslog' (substitute 'tower' with your server name).  Actually any 'file' in the /var/log directory can be read via 'http://tower/log/file'.
- May now read arbitrary files on disk and user shares via http protocol by referencing URL 'http://tower/share/<diskN>/...' or 'http://tower/share/user/<sharename>/...' (substitute 'tower' with your server name).
- Samba configuration now 'includes' the file on the Flash 'config/smb.extra' if present.  This is included at the end of the 'global' section just before the share definitions.  This may be used to customize the Samba configuration.
- Added control to enable/disable 'mover' logging.

Bug fixes:
- With user mode security enabled, would not accept 'root' share login until password was set at least once.
- Fixed problem in 'mover' script where mover would attempt to move objects in a top-level directory staring with a '.' character.  These would all fail and cause excessive syslog messages.
- Fixed bug in 'logrotate' which would prevent syslog from rotating.

Other changes:
- Part of adding AD support: Removed "User security [enabled/disabled]" control from Shares page, and added "Share security [simple/User Level/Active Directory]" control to Settings page:
  unRAID 'Basic' (free version) supports only 'Simple' share security model;
  unRAID 'Plus' supports 'Simple' and 'User Level' share security models only;
  unRAID 'Pro' supports all share security models ('Simple', 'User Level', and 'Active Directory').
- Removed System Management Utility control for setting SMB ports; this can be done via 'config/smb.extra' if desired.
- Change spin-down logic to account for external programs spinning drives up/down.
- Per user request, added '/usr/lib/libstdc++.so.6.0.9'
- Upgraded to linux kernel 2.6.28.4.
- Upgraded to samba 3.3.0.


Upgrade Instructions (Please Read Carefully)
============================================

If you are currently running unRAID Server 4.2-beta1 or higher (including 4.2.x 'final'), please copy the following files from the new release to the root of your Flash device:
    bzimage
    bzroot

If you are currently running unRAID server 4.0 or 4.1, please copy the following files from the new release to the root of your Flash device:
    bzimage
    bzroot
    syslinux.cfg
    menu.c32
    memtest

This can be done either by plugging the Flash into your PC or, by copying the files to the 'flash' share on your running server.  The server must then be rebooted.

If you are currently running unRAID Server 3.0-beta1 or higher, please follow these steps to upgrade:

1. Referring to the System Management Utility 'Main' page, make a note of each disks's model/serial number; you will need this information later.

2. Shut down your server, remove the Flash and plug it into your PC.

3. Right-click your Flash device listed under My Computer and select Properties.  Make sure the volume label is set to "UNRAID" (without the quotes) and click OK.  You do NOT need to format the Flash.

4. Copy the files from the new release to the root of your Flash device.

5. Right-click your Flash device listed under My Computer and select Eject.  Remove the Flash, install in your server and power-up.

6. After your server has booted up, the System Management Utility 'Main' page will probably show no devices; this is OK, navigate to the 'Devices' page. Using the model/serial number information gathered in step 1, assign each of your hard drives to the correct disk slot.

7. Go back to the 'Main' page and your devices should appear correctly.  You may now Start the array.


If you are installing this release to a new Flash, please refer to instructions on our website at:

http://www.lime-technology.com/wordpress/?page_id=19

Upgrade linux kernel to 2.6.30.8

 

You folks with S3 suspend issues, and some chipset/driver problems will DEFINITELY like this.... all 4 of my bench systems suspend/resume with unRAID using this kernel.

I just successfully upgraded my unRaid Slackware-Current installation to kernel 2.6.31.3 and Samba to 3.4.2 this past weekend. I thought I was done tinkering for a while. I guess not. Time to pull down 4.5b7 and try out the newer md drivers and emHttp. Let the fun begin. 

Upgrade linux kernel to 2.6.30.8

 

You folks with S3 suspend issues, and some chipset/driver problems will DEFINITELY like this.... all 4 of my bench systems suspend/resume with unRAID using this kernel.

 

That's good to hear :-) - I was waiting and hoping for those improvements, cause I have read about powermanagement fixes in newer kernels - but since it took long I already exchanged my 2 systems to new hardware properly supporting S3 with beta 6 already :-( ...

Is there also improvement in the realtek NIC driver? Can't remember, which kernel should improve this.

 

I just successfully upgraded my unRaid Slackware-Current installation to kernel 2.6.31.3 and Samba to 3.4.2 this past weekend. I thought I was done tinkering for a while. I guess not. Time to pull down 4.5b7 and try out the newer md drivers and emHttp. Let the fun begin. 

 

Where did you get samba 3.4.2?  Built from source?

I just successfully upgraded my unRaid Slackware-Current installation to kernel 2.6.31.3 and Samba to 3.4.2 this past weekend. I thought I was done tinkering for a while. I guess not. Time to pull down 4.5b7 and try out the newer md drivers and emHttp. Let the fun begin. 

 

Where did you get samba 3.4.2?  Built from source?

 

Installed via upgradepkg from a Slackware-Current mirror [ http://slackware.mirrors.tds.net/pub/slackware/slackware-current/ ]. They upgraded to Samba 3.4.2 on October 4th. From the Changelog:

 

n/samba-3.4.2-i486-1.txz:  Upgraded.

  This update fixes the following security issues.

  A misconfigured /etc/passwd with no defined home directory could allow

  security restrictions to be bypassed.

  mount.cifs could allow a local user to read the first line of an arbitrary

  file if installed setuid.  (On Slackware, it was not installed setuid)

  Specially crafted SMB requests could cause a denial of service.

  For more information, see:

    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2813

    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2948

    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2906

  (* Security fix *)

BRiT - ok, right.  Note that the slackware samba build does not include Active Directory support.

Yeah!  I am now preclearing drive #17 and in a few hours, will be adding it to the array.  Thanks Tom!

 

Regards,  Peter

Writes to user shares with the cache drive are up to 57 MB/s now from the bugged 15~ MB/s. Writing directly to the cache drive is still much faster at 97 MB/s. Most of my data is configured to write directly to a cache drive path so this is mostly a non-issue for me. I might pick up a Spinpoint F3 for the extra space and 20% faster writes than my Velociraptor(!!!).

 

I don't recall how the fast 4.4 transfers were because I've been moving huge files directly the the cache drive for a while now. 4.4's leaving the empty directories behavior was actually convenient for that, but all the hidden application files cluttered up the log file.

limetech, correct; currently I do not use active directory. It's on my 'get working' eventually list that have been sidetracked by other projects.

 

I upgraded to fuse 2.8.1, recompiled my 2.6.31.3 kernel with the 4.5beta7 md drivers, copied over the new emHttp, and rebooted. The unRAID array functions. It's in process of running a full parity check. It should complete in about 7 hours if it operates close to previous check speed final results of ~ 76,000 KB/sec.

On my setup writing to user shares with a cache drive went from ~15MB/sec to a sustained 40MB/sec.

Direct download

 

Bug fixes & linux updates.

 

unRAID Server 4.5-beta7 Release Notes
=====================================
Changes from 4.5-beta6 to 4.5-beta7
-----------------------------------
<snip>
- Prevent disks appearing 'unformatted' as a result of incomplete Stop Array operation.

I just tested this new change in behavior.

 

I had "cache_dirs" running, It is coded to make ALL disks busy,  and I also had a DVD ISO file-system "loop mounted" using the new unMENU plug-in.

 

I pressed the "Stop" array button.  From the syslog, it appears as if SAMBA is stopped and then unRAID attempts to un-mount the file-systems.

 

Since cache_dirs had all the disks "busy," no disks could be un-mounted, and when I pressed "Refresh" on the web-interface it looked like this with unRAID saying "Unmounting" on all the disks.

From the syslog, it appeared as if unRAID was looping, waiting for the process keeping the disk busy to exit.  I think it will wait forever here, filling the syslog eventually 

Oct 12 17:45:44 Tower emhttp: shcmd (50): /etc/rc.d/rc.samba stop | logger
Oct 12 17:45:44 Tower emhttp: shcmd (51): /etc/rc.d/rc.nfsd stop | logger
Oct 12 17:45:45 Tower emhttp: Spinning up all drives...
Oct 12 17:45:45 Tower emhttp: shcmd (52): sync
Oct 12 17:45:46 Tower emhttp: shcmd (53): umount /mnt/user >/dev/null 2>&1
Oct 12 17:45:46 Tower emhttp: shcmd (54): rmdir /mnt/user >/dev/null 2>&1
Oct 12 17:45:46 Tower emhttp: shcmd (55): umount /mnt/disk1 >/dev/null 2>&1
Oct 12 17:45:46 Tower emhttp: _shcmd: shcmd (55): exit status: 1
Oct 12 17:45:46 Tower emhttp: shcmd (56): rmdir /mnt/disk1 >/dev/null 2>&1
Oct 12 17:45:46 Tower emhttp: _shcmd: shcmd (56): exit status: 1
Oct 12 17:45:46 Tower emhttp: shcmd (57): umount /mnt/disk2 >/dev/null 2>&1
Oct 12 17:45:46 Tower emhttp: _shcmd: shcmd (57): exit status: 1
Oct 12 17:45:46 Tower emhttp: shcmd (58): rmdir /mnt/disk2 >/dev/null 2>&1
Oct 12 17:45:46 Tower emhttp: _shcmd: shcmd (58): exit status: 1
Oct 12 17:45:46 Tower emhttp: shcmd (59): umount /mnt/disk3 >/dev/null 2>&1
Oct 12 17:45:46 Tower emhttp: _shcmd: shcmd (59): exit status: 1
Oct 12 17:45:46 Tower emhttp: shcmd (60): rmdir /mnt/disk3 >/dev/null 2>&1
Oct 12 17:45:46 Tower emhttp: _shcmd: shcmd (60): exit status: 1
Oct 12 17:45:46 Tower emhttp: shcmd (61): umount /mnt/disk4 >/dev/null 2>&1
Oct 12 17:45:46 Tower emhttp: _shcmd: shcmd (61): exit status: 1
Oct 12 17:45:46 Tower emhttp: shcmd (62): rmdir /mnt/disk4 >/dev/null 2>&1
Oct 12 17:45:46 Tower emhttp: _shcmd: shcmd (62): exit status: 1
Oct 12 17:45:46 Tower emhttp: shcmd (63): umount /mnt/disk5 >/dev/null 2>&1
Oct 12 17:45:46 Tower emhttp: _shcmd: shcmd (63): exit status: 1
Oct 12 17:45:46 Tower emhttp: shcmd (64): rmdir /mnt/disk5 >/dev/null 2>&1
Oct 12 17:45:46 Tower emhttp: _shcmd: shcmd (64): exit status: 1
Oct 12 17:45:46 Tower emhttp: shcmd (65): umount /mnt/disk6 >/dev/null 2>&1
Oct 12 17:45:46 Tower emhttp: _shcmd: shcmd (65): exit status: 1
Oct 12 17:45:46 Tower emhttp: shcmd (66): rmdir /mnt/disk6 >/dev/null 2>&1
Oct 12 17:45:46 Tower emhttp: _shcmd: shcmd (66): exit status: 1
Oct 12 17:45:46 Tower emhttp: shcmd (67): umount /mnt/disk7 >/dev/null 2>&1
Oct 12 17:45:46 Tower emhttp: _shcmd: shcmd (67): exit status: 1
Oct 12 17:45:46 Tower emhttp: shcmd (68): rmdir /mnt/disk7 >/dev/null 2>&1
Oct 12 17:45:46 Tower emhttp: _shcmd: shcmd (68): exit status: 1
Oct 12 17:45:46 Tower emhttp: shcmd (69): umount /mnt/disk8 >/dev/null 2>&1
Oct 12 17:45:46 Tower emhttp: _shcmd: shcmd (69): exit status: 1
Oct 12 17:45:46 Tower emhttp: shcmd (70): rmdir /mnt/disk8 >/dev/null 2>&1
Oct 12 17:45:46 Tower emhttp: _shcmd: shcmd (70): exit status: 1
Oct 12 17:45:46 Tower emhttp: shcmd (71): umount /mnt/disk10 >/dev/null 2>&1
Oct 12 17:45:46 Tower emhttp: _shcmd: shcmd (71): exit status: 1
Oct 12 17:45:46 Tower emhttp: shcmd (72): rmdir /mnt/disk10 >/dev/null 2>&1
Oct 12 17:45:46 Tower emhttp: _shcmd: shcmd (72): exit status: 1
Oct 12 17:45:46 Tower emhttp: shcmd (73): umount /mnt/disk11 >/dev/null 2>&1
Oct 12 17:45:46 Tower emhttp: shcmd (73): umount /mnt/disk11 >/dev/null 2>&1
Oct 12 17:45:46 Tower emhttp: _shcmd: shcmd (73): exit status: 1
Oct 12 17:45:46 Tower emhttp: shcmd (74): rmdir /mnt/disk11 >/dev/null 2>&1
Oct 12 17:45:46 Tower emhttp: _shcmd: shcmd (74): exit status: 1
Oct 12 17:45:47 Tower emhttp: Retry unmounting disk share(s)...
Oct 12 17:45:48 Tower emhttp: shcmd (75): umount /mnt/disk1 >/dev/null 2>&1
Oct 12 17:45:48 Tower emhttp: _shcmd: shcmd (75): exit status: 1
Oct 12 17:45:48 Tower emhttp: shcmd (76): rmdir /mnt/disk1 >/dev/null 2>&1
....looping forever here...

I did not leave it looping forever, but it stayed looping for several minutes until I logged in via telnet and terminated the cache_dirs program by typing "cache_dirs -q"

 

It then looped in the syslog trying to un-mount the last drive where I had a loop device connected to an ISO image.

Oct 12 17:52:39 Tower cache_dirs: killing cache_dirs process 3284
Oct 12 17:52:40 Tower emhttp: Retry unmounting disk share(s)...
Oct 12 17:52:41 Tower emhttp: shcmd (3975): umount /mnt/disk1 >/dev/null 2>&1
Oct 12 17:52:41 Tower emhttp: _shcmd: shcmd (3975): exit status: 1
Oct 12 17:52:41 Tower emhttp: shcmd (3976): rmdir /mnt/disk1 >/dev/null 2>&1
Oct 12 17:52:41 Tower emhttp: _shcmd: shcmd (3976): exit status: 1
Oct 12 17:52:41 Tower emhttp: shcmd (3977): umount /mnt/disk2 >/dev/null 2>&1
Oct 12 17:52:41 Tower emhttp: shcmd (3978): rmdir /mnt/disk2 >/dev/null 2>&1
Oct 12 17:52:41 Tower emhttp: shcmd (3979): umount /mnt/disk3 >/dev/null 2>&1
Oct 12 17:52:41 Tower emhttp: shcmd (3980): rmdir /mnt/disk3 >/dev/null 2>&1
Oct 12 17:52:41 Tower emhttp: shcmd (3981): umount /mnt/disk4 >/dev/null 2>&1
Oct 12 17:52:41 Tower emhttp: shcmd (3982): rmdir /mnt/disk4 >/dev/null 2>&1
Oct 12 17:52:41 Tower emhttp: shcmd (3983): umount /mnt/disk5 >/dev/null 2>&1
Oct 12 17:52:41 Tower emhttp: shcmd (3984): rmdir /mnt/disk5 >/dev/null 2>&1
Oct 12 17:52:41 Tower emhttp: shcmd (3985): umount /mnt/disk6 >/dev/null 2>&1
Oct 12 17:52:42 Tower emhttp: shcmd (3986): rmdir /mnt/disk6 >/dev/null 2>&1
Oct 12 17:52:42 Tower emhttp: shcmd (3987): umount /mnt/disk7 >/dev/null 2>&1
Oct 12 17:52:42 Tower emhttp: shcmd (3988): rmdir /mnt/disk7 >/dev/null 2>&1
Oct 12 17:52:42 Tower emhttp: shcmd (3989): umount /mnt/disk8 >/dev/null 2>&1
Oct 12 17:52:42 Tower emhttp: shcmd (3990): rmdir /mnt/disk8 >/dev/null 2>&1
Oct 12 17:52:42 Tower emhttp: shcmd (3991): umount /mnt/disk10 >/dev/null 2>&1
Oct 12 17:52:42 Tower emhttp: shcmd (3992): rmdir /mnt/disk10 >/dev/null 2>&1
Oct 12 17:52:42 Tower emhttp: shcmd (3993): umount /mnt/disk11 >/dev/null 2>&1
Oct 12 17:52:43 Tower emhttp: shcmd (3994): rmdir /mnt/disk11 >/dev/null 2>&1
Oct 12 17:52:44 Tower emhttp: Retry unmounting disk share(s)...
Oct 12 17:52:45 Tower emhttp: shcmd (3995): umount /mnt/disk1 >/dev/null 2>&1
Oct 12 17:52:45 Tower emhttp: _shcmd: shcmd (3995): exit status: 1
Oct 12 17:52:45 Tower emhttp: shcmd (3996): rmdir /mnt/disk1 >/dev/null 2>&1
Oct 12 17:52:45 Tower emhttp: _shcmd: shcmd (3996): exit status: 1
Oct 12 17:52:46 Tower emhttp: Retry unmounting disk share(s)...
Oct 12 17:52:47 Tower emhttp: shcmd (3997): umount /mnt/disk1 >/dev/null 2>&1
Oct 12 17:52:47 Tower emhttp: _shcmd: shcmd (3997): exit status: 1
Oct 12 17:52:47 Tower emhttp: shcmd (3998): rmdir /mnt/disk1 >/dev/null 2>&1

When I next refreshed the unRAID web-interface, it now showed "Unmounting" on the one disk where I had a loop-file-system connected to an ISO image on that disk.

It looked like this:

I then was able to use the unMENU page to UnShare the ISO image... once I did that, the unRAID server stopped.

Oct 12 17:54:25 Tower emhttp: Retry unmounting disk share(s)...
Oct 12 17:54:26 Tower emhttp: shcmd (4095): umount /mnt/disk1 >/dev/null 2>&1
Oct 12 17:54:27 Tower emhttp: shcmd (4096): rmdir /mnt/disk1 >/dev/null 2>&1
Oct 12 17:54:27 Tower kernel: mdcmd (39): stop
Oct 12 17:54:27 Tower kernel: md1: stopping
Oct 12 17:54:27 Tower kernel: md2: stopping
Oct 12 17:54:27 Tower kernel: md3: stopping
Oct 12 17:54:27 Tower kernel: md4: stopping
Oct 12 17:54:27 Tower kernel: md5: stopping
Oct 12 17:54:27 Tower kernel: md6: stopping
Oct 12 17:54:27 Tower kernel: md7: stopping
Oct 12 17:54:27 Tower kernel: md8: stopping
Oct 12 17:54:27 Tower kernel: md10: stopping
Oct 12 17:54:27 Tower kernel: md11: stopping

It appears as if it does not attempt to terminate any process on it own.  Is this true Tom?  But that it simply does not stop the array fully until we terminate the processes holding the disks busy?

 

I'll need to change cache_dirs a tiny bit, to check for the un-mount attempts by the management console, but I think that will be just a matter of looking for the new status message.

In the interim, until we can get an event trigger from the 5.0 unRAID api to stop the array, it looks as if we will need to manually stop whatever we started that holds a disk busy.  In any case, this is a LOT better than seeing un-formatted. 

Thanks Tom.

 

Joe L.

It appears as if it does not attempt to terminate any process on it own.  Is this true Tom?  But that it simply does not stop the array fully until we terminate the processes holding the disks busy?

 

That is correct.  This is a tricky business.  At first I coded it to start killing processes that were causing the disk(s) to not un-mount.  However, when you have a file mounted via loop back, there is no process to kill.  While it is possible to locate the loop-mounted filesystem & force an unmount, it occurred to me that this is not right because it could lead to data loss.  Might make another change to this before 4.5 final, but probably not since most users will never see this issue & the proper solution lies elsewhere (5.0).

  Might make another change to this before 4.5 final, but probably not since most users will never see this issue & the proper solution lies elsewhere (5.0).

 

I disagree, more and more forum users are using addons and something like this is needed.

At the very least call out to a script we can adjust ourselves. Like the mover script.

 

One script after the array has started, one script just before shutdown.

 

You do not have to do anything other then calling a shell script that the user can modify.

 

This has been requested for a long time. It does not need to wait for 5.0.

 

 

 

bittorrent available here

 

http://linuxtracker.org/index.php?page=torrent-details&id=1f14a69f2483d80ee88b715c56f363a4fb006766

While it is possible to locate the loop-mounted filesystem & force an unmount, it occurred to me that this is not right because it could lead to data loss.

 

True.  To handle that possibility I put some code in the safer-shutdown script to alert the user of the situation, and accept user input to "force" unmounts.

It appears as if it does not attempt to terminate any process on it own.  Is this true Tom?  But that it simply does not stop the array fully until we terminate the processes holding the disks busy?

 

That is correct.  This is a tricky business.  At first I coded it to start killing processes that were causing the disk(s) to not un-mount.  However, when you have a file mounted via loop back, there is no process to kill. 

True... as I learned a long time ago... and possibly no open file descriptor either.  (if I remember correctly, as it was over a year ago when it caught me by surprise)

While it is possible to locate the loop-mounted filesystem & force an unmount, it occurred to me that this is not right because it could lead to data loss.

True, some will use a truCrypt file, looped as a file-system.  Others may use file-system images... too many possibilities for you to have to deal with without knowing the proper shut-down sequence. 

Might make another change to this before 4.5 final, but probably not since most users will never see this issue & the proper solution lies elsewhere (5.0).

I'd rather you not try to kill anything, but simply enhance a bit on what you are doing. 

 

The changes would be invoking a shutdown script as already requested before you start to stop and un-mount anything.  If it does not exist, continue as you currently coded, waiting for whatever is busy to finish.  We've already had one user find their "mover" script got caught when they attempted to stop the array.  It is not necessarily anything we add, it could be your own script keeping a disk busy, and you would want it to finish.

 

If the shutdown script exists (on the flash drive?  We've suggested /boot/custom/etc/rc.d/rc.unRAID as the shell script, and you can invoke it as rc.unRAID stop) invoke it and wait for it to finish.  If it exits with exit status 0, continue, if exit status 1, display its standard output (and possibly stderr) to the user as a informative message.  Example:  "Unable to stop server at this time... too many zombies"

 

At that point, you still have SMB running, you've done nothing to stop the server or un-mount the drives. The user is informed, and it is up to them to do what is appropriate.

 

In the same way, after you have the array established, if the same script exists in /boot/custom/etc/rc.d/rc.unRAID, invoke it as rc.unRAID start  This time you can just send its output to the syslog. 

 

Oh yes, after looping for a minute when un-mounting, you can suppress the syslog output except for once every hundred loops or so in the attempt to un-mount drives... Otherwise, syslog will fill and the attempt to stop the array will eventually crash the server when it runs out of memory to write the syslog.

 

I do like the "Unmounting" message you now have... it is informative and far less worrying to a novice unRAID user.

 

Joe L.

I upgraded to fuse 2.8.1, recompiled my 2.6.31.3 kernel with the 4.5beta7 md drivers, copied over the new emHttp, and rebooted. The unRAID array functions. It's in process of running a full parity check. It should complete in about 7 hours if it operates close to previous check speed final results of ~ 76,000 KB/sec.

 

Parity check finished without issue. It performs the same as 4.5beta6.

 

Oct 12 16:39:24 Reaver kernel: mdcmd (36): check
Oct 12 16:39:24 Reaver kernel: md: recovery thread woken up ...
Oct 12 16:39:24 Reaver kernel: md: recovery thread checking parity...
Oct 12 16:39:24 Reaver kernel: md: using 1152k window, over a total of 1953514552 blocks.
Oct 12 23:51:57 Reaver kernel: md: sync done. time=25952sec rate=75274K/sec
Oct 12 23:51:57 Reaver kernel: md: recovery thread sync completion status: 0

Has anyone tried unmounting / stopping the filesystem as the cacher disk is moving files to the array? If my theory is correct, it would unmount all disks except the one in use.

The changes would be invoking a shutdown script as already requested before you start to stop and un-mount anything.  If it does not exist, continue as you currently coded, waiting for whatever is busy to finish.  We've already had one user find their "mover" script got caught when they attempted to stop the array.  It is not necessarily anything we add, it could be your own script keeping a disk busy, and you would want it to finish.

 

If the shutdown script exists (on the flash drive?  We've suggested /boot/custom/etc/rc.d/rc.unRAID as the shell script, and you can invoke it as rc.unRAID stop) invoke it and wait for it to finish.  If it exits with exit status 0, continue, if exit status 1, display its standard output (and possibly stderr) to the user as a informative message.  Example:  "Unable to stop server at this time... too many zombies"

 

At that point, you still have SMB running, you've done nothing to stop the server or un-mount the drives. The user is informed, and it is up to them to do what is appropriate.

 

In the same way, after you have the array established, if the same script exists in /boot/custom/etc/rc.d/rc.unRAID, invoke it as rc.unRAID start  This time you can just send its output to the syslog.

 

Oh yes, after looping for a minute when un-mounting, you can suppress the syslog output except for once every hundred loops or so in the attempt to un-mount drives... Otherwise, syslog will fill and the attempt to stop the array will eventually crash the server when it runs out of memory to write the syslog.

 

As Joe suggests,  calling a script right after successful array start and right before array stop would give us the hooks for third party addons.

 

As far as saving stderr/stdout and showing it to the user. I think that would make this request more complicated.

Instead, pipe stderr/stdout to logger(i.e. sysllog). (my rc.unRAID already sends it's messages to syslog).

 

Add a menu item at the top that shows the current syslog (make it easier for users to see what's going on in the system).

 

So if rc.unRAID exits non zero you can say start or stop operation received an error, see syslog.

And there would be a menu item in emhttp to show it.

 

I know it's possible to see syslog now, but that is hidden and a menu option would be helpful.

The changes would be invoking a shutdown script as already requested before you start to stop and un-mount anything.  If it does not exist, continue as you currently coded, waiting for whatever is busy to finish.  We've already had one user find their "mover" script got caught when they attempted to stop the array.  It is not necessarily anything we add, it could be your own script keeping a disk busy, and you would want it to finish.

 

If the shutdown script exists (on the flash drive?  We've suggested /boot/custom/etc/rc.d/rc.unRAID as the shell script, and you can invoke it as rc.unRAID stop) invoke it and wait for it to finish.  If it exits with exit status 0, continue, if exit status 1, display its standard output (and possibly stderr) to the user as a informative message.  Example:  "Unable to stop server at this time... too many zombies"

 

At that point, you still have SMB running, you've done nothing to stop the server or un-mount the drives. The user is informed, and it is up to them to do what is appropriate.

 

In the same way, after you have the array established, if the same script exists in /boot/custom/etc/rc.d/rc.unRAID, invoke it as rc.unRAID start  This time you can just send its output to the syslog.

 

Oh yes, after looping for a minute when un-mounting, you can suppress the syslog output except for once every hundred loops or so in the attempt to un-mount drives... Otherwise, syslog will fill and the attempt to stop the array will eventually crash the server when it runs out of memory to write the syslog.

 

As Joe suggests,  calling a script right after successful array start and right before array stop would give us the hooks for third party addons.

 

As far as saving stderr/stdout and showing it to the user. I think that would make this request more complicated.

Instead, pipe stderr/stdout to logger(i.e. sysllog). (my rc.unRAID already sends it's messages to syslog).

 

Add a menu item at the top that shows the current syslog (make it easier for users to see what's going on in the system).

 

So if rc.unRAID exits non zero you can say start or stop operation received an error, see syslog.

And there would be a menu item in emhttp to show it.

 

I know it's possible to see syslog now, but that is hidden and a menu option would be helpful.

It is a good idea to log any messages to the syslog, but if you saw how quickly it was being filled as emhttp loops several times a second, logging hundreds of error messages, a simple "add-on-whatever is is still running... "  to the screen is far more helpful.  I expect only to put a short message to the screen from the output of whatever "rc.unRAID stop" script. to direct the user on how to proceed.. 

 

Example... when I went stop my array the first message was logged as

(line 1121 in my syslog)  Oct 12 17:45:44 Tower emhttp: shcmd (50): /etc/rc.d/rc.samba stop | logger

 

then it looped attempting to un-mount the drives until I logged in and quit cache_dirs. I did that here (7 minutes later, as I did a screen capture, etc trying to learn what it was doing):

(line 9164 in my syslog)  Oct 12 17:52:39 Tower cache_dirs: killing cache_dirs process 3284 

 

Each minute it had logged a bit over 1100 messages to the syslog as it looped trying to un-mount the disks.  Any message keeping a disk busy would be lost quickly in the middle of the stream of messages being logged.

 

I do like the idea of a "syslog" link on the top menu... it would be a nice addition.

Well, I can confirm the drive limit issue is resolved.  I have 19 drives running currently.

Just out of curiosity:

 

Tom, what ended up being the problem with the 20 drive support issue and what did you have to do to fix it?  The programmer in me kinda wants to know

Just out of curiosity:

 

Tom, what ended up being the problem with the 20 drive support issue and what did you have to do to fix it?  The programmer in me kinda wants to know

 

There are optimized XOR functions built into the linux kernel that are part of the crypto package, but are also used to calculate parity.  These functions had an argument list like this: (size, count, ptr) where size is the buffer size, ptr is an array of buffer pointers, and count is the number of pointers in ptr.  By convention, ptr[0] is the destination buffer into which buffers ptr[1], ptr[2], etc were XOR'ed.  Well somewhere along the line, someone changed the argument list to be this: (size, count, dest, ptr), where everything is the same except that the destination buffer is specified as it's own argument and the ptr list only specifies 'source' buffers.  Well the unraid bug was that instead of including the proper kernel crypto header files, I had just copied the xor function declaration into a private header file, so the code did not pick up the change in the argument definition.  So to fix this I had to 'include' the proper kernel header file and then change the code to conform to the new xor function argument list.... make sense?

Just out of curiosity:

 

Tom, what ended up being the problem with the 20 drive support issue and what did you have to do to fix it?  The programmer in me kinda wants to know

 

There are optimized XOR functions built into the linux kernel that are part of the crypto package, but are also used to calculate parity.  These functions had an argument list like this: (size, count, ptr) where size is the buffer size, ptr is an array of buffer pointers, and count is the number of pointers in ptr.  By convention, ptr[0] is the destination buffer into which buffers ptr[1], ptr[2], etc were XOR'ed.  Well somewhere along the line, someone changed the argument list to be this: (size, count, dest, ptr), where everything is the same except that the destination buffer is specified as it's own argument and the ptr list only specifies 'source' buffers.  Well the unraid bug was that instead of including the proper kernel crypto header files, I had just copied the xor function declaration into a private header file, so the code did not pick up the change in the argument definition.  So to fix this I had to 'include' the proper kernel header file and then change the code to conform to the new xor function argument list.... make sense?

 

I KNEW IT!  I thought it was that all along.