unRAID Server Release 6.0-beta6-x86_64 Available

[dmacias]

PHP extensions still omitted from this build:

 

  /usr/lib64/php/extensions/  is empty

You could just extract the extensions from the same version of php slackware package.  I have an apache plugin that works by doing that.

[NAS]

Anyone with a btrfs cache drive seeing a slow down in a move from cache to array cache.

 

e.g. if I move a file from "/mnt/cache/download" to "/mnt/user/tv" the move only runs at say 100MB/s. That sounds fast but when essentially it is actually just renaming the file path to /mnt/cache/tv" it is very slow, it should be instant.

 

Can produce some numbers if needed but want to make sure I aint doing something silly first.

 

 

[itimpi]

Anyone with a btrfs cache drive seeing a slow down in a move from cache to array cache.

 

e.g. if I move a file from "/mnt/cache/download" to "/mnt/user/tv" the move only runs at say 100MB/s. That sounds fast but when essentially it is actually just renaming the file path to /mnt/cache/tv" it is very slow, it should be instant.

 

Can produce some numbers if needed but want to make sure I aint doing something silly first.

I am not sure that the system realises that this could be accomplished with a simple move and thus does a copy/delete.  If you want the speed use /mnt/cache type paths for both source and destination.

[NAS]

I see what you are saying but I am not sure I agree. (caveat: I am prepared to accept I am wrong)

 

In my example the file starts on the cache drive and ends on the cache drive (until the mover later puts it on the array using user0).

 

Any move within the cache drive should be instant. I am reasonably certain it used to be with reiser.

 

Edit: your " copy/delete." idea certainly fits the symptoms I am just not sure why its happening now and not before.

Edit 2: The reason i am only reasonably certain is that on top of this Perl rename cant handle btrfs to the array now whereas before it 100% could

[jumperalex]

I can't speak to your EDIT2 ... but consider that because you are copying through FUSE by copying to /mnt/user/... the system does indeed think it is copying to a new device.

 

Easy test, manually run the move command as is.  Then repeat by changing the path so that it explicitly uses /mnt/cache/... on both sides of the operation.  If you see a difference then Today You Learned ...

[bubbaQ]

PHP extensions still omitted from this build:

 

  /usr/lib64/php/extensions/  is empty

You could just extract the extensions from the same version of php slackware package.  I have an apache plugin that works by doing that.

 

No, that won't work.  You have to overwrite the full PHP install which leads to other problems.

[NAS]

I can't speak to your EDIT2 ... but consider that because you are copying through FUSE by copying to /mnt/user/... the system does indeed think it is copying to a new device.

 

Easy test, manually run the move command as is.  Then repeat by changing the path so that it explicitly uses /mnt/cache/... on both sides of the operation.  If you see a difference then Today You Learned ...

 

Thats fair enough but with why is this btrfs specific?

 

Also at no time do i issue a copy copy i only do a mv. If a copy then delete happens then it is the system failing to do a move directly and copying as some sort of fallback without me explicitly asking for it.

 

I really dont want to revert to reiser just to prove myself right or wrong but maybe I have to unless someone else can replicate that has a rieser cache drive still

 

Edit: sorry for the edits dealing with a sick kid at same time as this. I realise a mv is a copy and delete when jumping disks but I was sure this used to be instant before with this cache <>cache scenario. Problem is to move to 6b6 I had to change a load of things and 6b6 is a big change in itself so there are a lot of deltas. And i could be imagining it.

 

 

[kal]

fwiw, on 5.0.5, the mv command is instant when doing;

 

mv /mnt/cache/.custom/transmission/torrents/complete/* /mnt/user/Series

 

/edit for me anyway. Series is a cached share of course

 

/edit redacted...! 

[NAS]

fwiw, on 5.0.5, the mv command is instant when doing;

 

mv /mnt/cache/.custom/transmission/torrents/complete/* /mnt/user/Series

 

/edit for me anyway. Series is a cached share of course

 

Thanks for that it means I am not going mad.

 

Can anyone test that has btrfs to make sure its not a problem with my specific setup.

 

appreciated

[jumperalex]

I can't speak to your EDIT2 ... but consider that because you are copying through FUSE by copying to /mnt/user/... the system does indeed think it is copying to a new device.

 

Easy test, manually run the move command as is.  Then repeat by changing the path so that it explicitly uses /mnt/cache/... on both sides of the operation.  If you see a difference then Today You Learned ...

 

Thats fair enough but with why is this btrfs specific?

 

Also at no time do i issue a copy copy i only do a mv. If a copy then delete happens then it is the system failing to do a move directly and copying as some sort of fallback without me explicitly asking for it.

 

I really dont want to revert to reiser just to prove myself right or wrong but maybe I have to unless someone else can replicate that has a rieser cache drive still

 

Edit: sorry for the edits dealing with a sick kid at same time as this. I realise a mv is a copy and delete when jumping disks but I was sure this used to be instant before with this cache <>cache scenario. Problem is to move to 6b6 I had to change a load of things and 6b6 is a big change in itself so there are a lot of deltas. And i could be imagining it.

 

Oh I wasn't suggesting to go back to v5, I was just offering the test all in b6 to see what happens when you 1) expect the OS to know you are moving within the same device vs 2) you explicitly tell it to move within the same device.

 

I use "device" for a reason: I'm pretty sure as far as the OS is concerned, /mnt/cache/[$share only on cache 1] and /mnt/user/[$share only on cache 2] are not the same device because underlying all of that the /mnt/cache is /dev/sdg1 while /mnt/user is shfs

 

So ya know ... for science ... I just tried it myself in b5a.

root@Tower:~# ls -l /mnt/cache/download-CacheOnly/
-rw-rw-rw- 1 nobody users 738911468 Dec 16  2012 Dave\ Chappelle\ Killin'\ Em\ Softly.avi

root@Tower:~# mv /mnt/cache/download-CacheOnly/Dave\ Chappelle\ Killin\'\ Em\ Softly.avi /mnt/user/TV-CacheOnly/

That took 20 Seconds according to my smartphones stopwatch.  At 35MB/s that is annoyingly slow, but more importantly ... I moved the file back and tried again but this time:

root@Tower:~# mv /mnt/cache/download-CacheOnly/Dave\ Chappelle\ Killin\'\ Em\ Softly.avi /mnt/cache/TV-CacheOnly/

and it was literally done before I could hit the stopwatch stop button.

[NAS]

Yeah if i explicitly dont use a fuse user share and mv from and to /mnt/cache/* it is instant as you would expect.

 

Somewhere along the line though I at least lost this same speed when using fuse layer and I "think" it was the move to btrfs that caused it.

 

Anyone with b6 and a resiser cache drive able to do a quick test?

[kal]

fwiw, on 5.0.5, the mv command is instant when doing;

 

mv /mnt/cache/.custom/transmission/torrents/complete/* /mnt/user/Series

 

/edit for me anyway. Series is a cached share of course

 

actually apologies, Im working through some tests now, and this mightnt be the case

 

have more shortly

[Freddie]

fwiw, on 5.0.5, the mv command is instant when doing;

 

mv /mnt/cache/.custom/transmission/torrents/complete/* /mnt/user/Series

 

/edit for me anyway. Series is a cached share of course

 

I get the same slow mv on both 5.0.5(reiserfs) and 6.0-beta6(btrfs).  From 5.0.5:

root@Tower:~# ls -l /mnt/cache/.custom/
total 1049600
-rw-rw-rw- 1 nobody users 1073741824 2014-06-26 09:55 af
root@Tower:~# time { mv -v /mnt/cache/.custom/* /mnt/user/dwnld/; }
`/mnt/cache/.custom/af' -> `/mnt/user/dwnld/af'
removed `/mnt/cache/.custom/af'

real	0m21.119s
user	0m0.020s
sys	0m1.500s
root@Tower:~# ls -l /mnt/cache/dwnld/af 
-rw-rw-rw- 1 nobody users 1073741824 2014-06-26 09:55 /mnt/cache/dwnld/af

 

I have no idea what could cause the difference between kal's results and mine.

[kal]

Yea Im getting similar to you Im afraid freddie - apologies for muddying the water 

 

[jumperalex]

Yeah if i explicitly dont use a fuse user share and mv from and to /mnt/cache/* it is instant as you would expect.

 

Somewhere along the line though I at least lost this same speed when using fuse layer and I "think" it was the move to btrfs that caused it.

 

Anyone with b6 and a resiser cache drive able to do a quick test?

 

My test says it isn't BTRFS or B6.  I know Kal's earlier test shows the "good" behavior in both test cases but mine at least shows that it is indeed possible to have "bad" behavior on RFS in b5a when moving from /mnt/cache/ to /mnt/user/[cache only share]

 

Now if there is a way to fix that behavior I'm ALL FOR IT.  I'm just saying it isn't a BTRFS-only thing.

 

EDIT: I just saw that Kal has recanted

[kal]

Yea sorry folks - its all making a lot more sense (jumperalex, your statement in particular '..not the same device because underlying all of that the /mnt/cache is /dev/sdg1 while /mnt/user is shfs')

 

 

I was mucking around with moves the other day trying to get to the bottom of similar issue:

 

http://lime-technology.com/forum/index.php?topic=33667.msg313812#msg313812

 

but looks like my memory wasnt the best

[NAS]

hmm so maybe I am going mad then. lol

 

Limetech do we have any options here as it would be ideal to teach fuse that a mv from a cache only share to a fuse share that has using the same cache is instant.

[jumperalex]

are you doing this from a script?  Something you can modify to test for the actual location of a share? And of course in this case since you know it is a cache share just go ahead and always use /mnt/cache instead of /mnt/user  [shrug]

 

Seems that might be your most likely path to goodness in the short term.  I think it would require a change to mv and not fuse, but I'm out of my depth and just guessing.

[NAS]

are you doing this from a script?  Something you can modify to test for the actual location of a share? And of course in this case since you know it is a cache share just go ahead and always use /mnt/cache instead of /mnt/user  [shrug]

 

Seems that might be your most likely path to goodness in the short term.  I think it would require a change to mv and not fuse, but I'm out of my depth and just guessing.

 

Actually that is a rather clever idea although I always prefer a fix for all rather than a fix for just me.

 

Seems like an area of refinement assuming there are no technology hurdles stopping it.

 

Update: altered my scripting to do the FUSE part itself. What was fast is now instant. Still think this is something that should happen automatically

[JarDo]

I noticed that packages I place in /boot/extra are not being installed at boot time.  Could I possibly be doing something wrong, or did something change in v6 that I'm not aware of?

 

EDIT: Syslog attached

 

EDIT2: 

Nevermind - I was wrong  

My packages in /boot/extra are installing just fine.  I had misdiagnosed my original issue. 

All is good now

[jumperalex]

need to see your syslog.

[itimpi]

I find that as the number of boot option proliferates, it is not always easy to remember which boot option you selected this time around.    I was wondering if it was possible to pass through an option from the syslinux.cfg file that could later be displayed in the GUI to identify which boot option was used.  I was thinking of either using the value of the 'label' entry, or perhaps a string passed through in a similar way to the way the SafeBoot option is passed though (something like bootoption="text describing option"), and that this could later be displayed at the top of the WebGUI pages?

 

I could also see it being useful from a support perspective when users post a screenshot of their unRAID GUI.

 

What do others think?

 

[jonp]

I find that as the number of boot option proliferates, it is not always easy to remember which boot option you selected this time around.    I was wondering if it was possible to pass through an option from the syslinux.cfg file that could later be displayed in the GUI to identify which boot option was used.  I was thinking of either using the value of the 'label' entry, or perhaps a string passed through in a similar way to the way the SafeBoot option is passed though (something like bootoption="text describing option"), and that this could later be displayed at the top of the WebGUI pages?

 

I could also see it being useful from a support perspective when users post a screenshot of their unRAID GUI.

 

What do others think?

 

Great idea, easy enough to do, and I myself have had this problem before.  Will discuss with the team for review.

[JustinChase]

jonp, I believe I've read that you were able to get GPU passthru working with KVM.  Would you please provide the xml file you used to do so?  I've been trying to use Peter_sm's xml file, but it's just not working for me.  I've read and read and read other sites and tried to better understand the (not easy) language of these xml files, but I'm just not getting anywhere.

 

If you could provide something that has worked for you, perhaps I can modify if to work for me.

 

If not, can you give me some ideas as to why my XEN windows session is dropping the internet connection after a few minutes?  It was working mostly fine, but I installed the gplpv drivers, then the drivers for my video card, and now I lose internet in the VM.  This means I currently have no working windows VM, which makes the family upset.

 

Thanks, I appreciate any help.

[flintlock1]

Hi All,

I have a problem, discovered this morning, Last night After Disk 6 failed with red ball,  i did the disk swap and parity rebuild onto the new 2 tb drive, now when i look at my shares from my pc, there seems to be a lot of data missing.

for example my "Share1" media share now seems to my windows machine to be totally empty.

I have checked using midnight commander on unraid system , that all my data drives "seem" to have the data still there under the individual drives.

System is just booted, i have not done anything to it. could anyone please help with a suggestion what to do now please.

syslog.txt