unRAID Server Release 6.0-beta9-x86_64 Available

[fiscalcon]

Ok, let's give this a whirl:

 

Paste this URL into the "Install Extension" box on the Extensions page and then click Install.  This will download dockerMan with the my-* edit bug fixed.

 

https://raw.githubusercontent.com/limetech/dockerMan/master/dockerMan.plg

 

Thanks! Worked for me.

[limetech]

There are some directories in the Docker vdisk mounted at /var/lib/docker that you can get rid of you want:

 

/var/lib/docker/unraid-templates  [after you move your my-* files to /boot/config/plugins/docker/templates-user]

/var/lib/docker/community-templates

/var/lib/docker/images

 

They don't take much space so you can just leave 'em as well.

 

The file /var/lib/docker/unraid-autostart is still used so don't delete that one.

 

You see what we did here: when Docker starts for the first time with a blank vdisk, it creates the directory tree you see mounted at /var/lib/docker.  So really, /var/lib/docker is *private* to Docker - a new Docker release could add anything in there.

 

At first I thought the template files should be stored there because they are specific to the containers therein.  But gfjardim made a good point they're part of "config data" and should be kept in /boot/config/plugins/docker.  Once unraid 6 hits -rc1 it will be much more difficult to make design changes, best to do it while still in beta.  Hence starting with beta9 this is what we're doing.

 

I apologize for not making that clear in release notes.  We pretty much entered scramble-mode with this reiserfs fiasco and this info got left out.

 

[Mettbrot]

Seems there are a number of folks having struggles with Docker and beta9.  Would it be helpful if we created an IRC channel to temporarily help folks who need it?  Is there another medium that folks would prefer to use?  I want to make sue everyone gets the help they need to get to beta 9 and back up and running with all their containers and templates intact.

 

Or join the existing one?

 

nice, I have always wondered if there is a channel for fast little support questions. I was always looking under #limtech though... Nevertheless, it would be nice if some officials would be there too.

[bkastner]

I am still having an issue with beta9 which is confusing me.

 

I had been moving data around with beta8 between disks before you threw up the big stop sign, so I figured I would wait until beta9 and then continue what I was doing.

 

I had noticed that when moving files folders with beta8 that empty folders would be left behind. For example I am moving the root /tv folder off of disk3 onto disk 10. A number of the shows under /tv would still have season folders and metadata folders under that, but all the directories would be blank.

 

I figured this was just an oddity of beta8 and so left it alone. I am now on beta9 and am trying to re-move /tv from disk3 to disk10. I am around 50% done of copying over 418GB, and when checking the GUI I was surprised the free space wasn't increasing, so I started digging into the folders again, and have noticed that these empty folders have not cleaned up, and even shows that still had data are actually copying, not moving.

 

So, here is a window of the move:

 

 

If I look at the season folder under Californication as in the picture it's not actually deleting the files on disk3. It looks like it's moving them, but it's not. I now see the same content on disk3 as I do on disk10.

 

Prior to the beta8 issues I have never seen this before, and am not sure how best to fix it.

 

Any suggestions on what I can do here? Also, I am curious if anyone else is noticing anything similar.

[StevenD]

Any suggestions on what I can do here? Also, I am curious if anyone else is noticing anything similar.

 

It wont delete the source files and free up the space until the job is complete.

[bkastner]

Any suggestions on what I can do here? Also, I am curious if anyone else is noticing anything similar.

 

It wont delete the source files and free up the space until the job is complete.

 

So if I am moving 500GB of stuff it won't clean anything up until all 500GB are moved? This isn't how I thought it had behaved previously. I had thought as each folder (i.e. TV) was moved the source was removed.

 

[Dephcon]

what you'd probably want to do is mv /mnt/disk3/tv/* /mnt/disk10/tv/

 

this will remove each show folder as it completes.

[limetech]

what you'd probably want to do is mv /mnt/disk3/tv/* /mnt/disk10/tv/

 

this will remove each show folder as it completes.

 

Actually I would do all this via windows explorer - sure it might take longer but it's reliable and gives me an excuse to go have a beer while the move is proceeding.

 

If you have to do via command line, I would do

 

cp -rp /mnt/disk3/tv/* /mnt/disk10/tv

 

Verify everything looks good, then

 

rm -r /mnt/disk3/tv

 

Use MC as last resort imho.

[jumperalex]

Use MC as last resort imho.

 

I think that was a shot at you jonp

[bkastner]

what you'd probably want to do is mv /mnt/disk3/tv/* /mnt/disk10/tv/

 

this will remove each show folder as it completes.

 

Ahh... this is what I've usually done in the past now that you mention it - highlighted a number of sub-folders, not the root. That is likely the cause of the change in behaviour.

[bkastner]

what you'd probably want to do is mv /mnt/disk3/tv/* /mnt/disk10/tv/

 

this will remove each show folder as it completes.

 

Actually I would do all this via windows explorer - sure it might take longer but it's reliable and gives me an excuse to go have a beer while the move is proceeding.

 

If you have to do via command line, I would do

 

cp -rp /mnt/disk3/tv/* /mnt/disk10/tv

 

Verify everything looks good, then

 

rm -r /mnt/disk3/tv

 

Use MC as last resort imho.

 

Okay... good advice. I've always just used MC as it's faster than doing it via Windows and it's much more visual than command line.

 

You make a good point on the verification though.

[jphipps]

I usually use rsync with the --remove-source-files option.  Then it will copy the files and remove them once the file is successfully copied.  Since you are using rsync, you can restart if you need to...

[sparkysplace]

I usually use rsync with the --remove-source-files option.  Then it will copy the files and remove them once the file is successfully copied.  Since you are using rsync, you can restart if you need to...

 

I'm actually doing this now, bouncing stuff around and converting each disk to xfs.

 

The thing thats killing me is the damn parity (well, I'm assuming it's parity). I'm using 'rsync --progress -avzh /dev/disk1 /dev/disk4' and it bounces anywhere between 2.5MB/s and 20MB/s. It is quite erratic.

 

Anyway, the data isn't mission critical, but I do want to avoid restoring from backups and I want to avoid thrashing the parity drive. Does anyone have any suggestions on temporarily disabling/removing parity so I can get the moves done then rebuild parity once complete?

[jphipps]

I would drop the "z".  I found it slowed it down alot and there is no real need to compress since you aren't going over a network..

[jumperalex]

I would drop the "z".  I found it slowed it down alot and there is no real need to compress since you aren't going over a network..

 

You beat me to it   We learned this when working up the VMBackup script a few months back.

[sparkysplace]

I would drop the "z".  I found it slowed it down alot and there is no real need to compress since you aren't going over a network..

 

You beat me to it   We learned this when working up the VMBackup script a few months back.

 

Thanks for that, it never even crossed my mind - I use rsync every day at work, and the z flag is one of those muscle memory things.

 

So, now I'm floating between 2.5MB/s and 70MB/s. Files are finishing on average around 15MB/s. So a little faster, but parity is still the bottleneck. I'd still love to disable parity as my 3TB drives are next and I don't want to wait 30 hours for these to finish copying.

[PeterB]

So, now I'm floating between 2.5MB/s and 70MB/s. Files are finishing on average around 15MB/s. So a little faster, but parity is still the bottleneck. I'd still love to disable parity as my 3TB drives are next and I don't want to wait 30 hours for these to finish copying.

 

I'm experiencing much the same and cannot understand why it should be sooooo s--l--o--w.

 

I'm using: rsync -aHAXv --progress /mnt/disk5/* /mnt/disk3

[jphipps]

Me too...  -avz was always my standard until I happened to try it without the "z"...

 

If you aren't too worried about the parity protection, you can always stop the array, and mount the filesystems and do the copy disk to disk, and then start with a new config and then rebuild parity.  I just go the slow route and copy with parity... The data is still accessable during the copy, so I figure it doesn't really matter how long it takes.  I would get a drive done every day or so...

[mr-hexen]

In beta9 the mdcmd write method flag can be set again, no?

[htpcnewbie]

Had a painless move from beta8 to beta9. Took precautions to copy the cache drive as a backup but everything worked fine.

 

Stopped docker, stopped all plugins, moved the docker templates folder as suggested, installed the dockerman plg as suggested by LT in pg4, copied the upgrade files to flash drive and rebooted.

 

All the docker containers were in there and plugins from the /boot/config/plugins also showed up in the plugins webgui.

 

Thank you LT!

[thestewman]

I updated from 6.0-beta 8 to 6.0 beta 9 and now every night i receive this emailed  error message.

I would appreciate if someone would interpret the error message and tell me how to fix it.

 

Message Title:

cron for user root /usr/bin/run-parts /etc/cron.daily 1> /dev/null

 

Message:

error: syslog:1 duplicate log entry for /var/log/syslog

 

Syslog:

 

Sep 12 20:19:53 Tower emhttp: shcmd (80): /usr/sbin/hdparm -y /dev/sdc &> /dev/null (Drive related)

Sep 13 00:58:07 Tower unmenu[1607]: cat: /sys/block/loo/stat: No such file or directory

Sep 13 00:58:39 Tower unmenu[1607]: cat: /sys/block/loo/stat: No such file or directory

Sep 13 01:01:43 Tower unmenu[1607]: cat: /sys/block/loo/stat: No such file or directory

Sep 13 02:02:36 Tower kernel: mdcmd (59): spindown 1 (Routine)

Sep 13 02:02:46 Tower kernel: mdcmd (60): spindown 4 (Routine)

Sep 13 03:30:01 Tower logger: mover started

Sep 13 03:30:01 Tower logger: skipping docker/

Sep 13 03:30:01 Tower logger: mover finished

Sep 13 04:40:01 Tower sSMTP[11134]: Creating SSL connection to host

Sep 13 04:40:01 Tower sSMTP[11134]: SSL connection using ECDHE-RSA-AES128-GCM-SHA256

Sep 13 04:40:04 Tower sSMTP[11134]: Sent mail for [email protected] (221 2.0.0 closing connection rq5sm3951625igb.12 - gsmtp) uid=0 username=root outbytes=501

Sep 13 09:29:36 Tower unmenu[1607]: cat: /sys/block/loo/stat: No such file or directory

 

[itimpi]

This looks like it is due to the fact that the current version of unMenu gets confused by the loopback device introduced for handling docker.

[bondoo0]

I think the issue is in the title about from having a problem with syslog.  The unmenu issue with the loopback just happens to be in syslog.  I was getting the unmenu error before, but the syslog issue listed looks to me like a problem when the syslog is rolled over, and started showing up on my system with beta 9.

[limetech]

I think the issue is in the title about from having a problem with syslog.  The unmenu issue with the loopback just happens to be in syslog.  I was getting the unmenu error before, but the syslog issue listed looks to me like a problem when the syslog is rolled over, and started showing up on my system with beta 9.

syslog rotate indeed has a bug and fixed in next release.

[Thornwood]

Hi I was wondering if btrfs has growing overhead? I migrated all my data to the cashe drive that only showed 1gb overhead prior, I then migrated all data off. Then it showed 5gb when empty is this normal?

 

Thank you in advance.