July 5, 201313 yr An interesting rc16b syslog line... Jul 4 13:52:38 unRAID kernel: Btrfs loaded Let the fun begin!
July 5, 201313 yr Also... The banner at the top of the forum needs to be changed to rc16b. John So does your signature
July 5, 201313 yr An interesting rc16b syslog line... Jul 4 13:52:38 unRAID kernel: Btrfs loaded Let the fun begin!
July 5, 201313 yr I still cant get my head around the issue relating to User Shares and the calculation of Free Space. From the way it used to be calculated to the way it is now calculated in my eyes is wrong. If share "Movies" includes disk1-8, free space should be calculated on the free space of disks 1-8. Not a calculation on the disks that contain /disk1/movies, /disk3/movies, some of my disks don't have a movies directory yet.
July 5, 201313 yr I can see it both ways. I have a share that I setup in such a way that the split-level means data does not move of the initial 2 disks that started being written to, so in that instance it would be showing me the correct information as data will only go to those disks not because of pre-set disk restrictions but because of the split level settings. I actually never look at the share space left tho.
July 5, 201313 yr I still cant get my head around the issue relating to User Shares and the calculation of Free Space. From the way it used to be calculated to the way it is now calculated in my eyes is wrong. If share "Movies" includes disk1-8, free space should be calculated on the free space of disks 1-8. Not a calculation on the disks that contain /disk1/movies, /disk3/movies, some of my disks don't have a movies directory yet. The algorithm that Tom posted included disks that could potentially have that share so I think in most cases as far as I can see you will get the results you expect. One possible complication I could see in the posted algorithm is the unusual case where a disk (perhaps disk9) that is NOT included in the share already has the relevant folder. The files on the disk show up under the share. This might suggest the share is larger than one would expect.
July 5, 201313 yr Author If share "Movies" includes disk1-8, free space should be calculated on the free space of disks 1-8. Not a calculation on the disks that contain /disk1/movies, /disk3/movies, some of my disks don't have a movies directory yet. Yes there is a bug, this is how it should work. This bug was introduced as a result of adding some code meant to trap this "transport not connected" error.
July 5, 201313 yr Just to clarify the release notes (http://lime-technology.com/wiki/index.php?title=UnRAID_Server_Version_5.0-beta_Release_Notes)... Should the last Upgrade heading read "5.0-rc9 through 5.0-rc15a"? (it currently reads "5.0-rc9 through 5.0-rc1")
July 5, 201313 yr Just to clarify the release notes (http://lime-technology.com/wiki/index.php?title=UnRAID_Server_Version_5.0-beta_Release_Notes)... Should the last Upgrade heading read "5.0-rc9 through 5.0-rc15a"? (it currently reads "5.0-rc9 through 5.0-rc1") Yes. To make it simple, all you need to do with any of the RC's is: (a) Stop the array (b) Copy bzroot, bzimage, and syslinux.cfg to the flash drive (overwriting the ones already there) © Reboot Done
July 5, 201313 yr Thanks. Yay, the cache drive spins down on its default setting now. Little things please me.
July 5, 201313 yr That's normal it is telling you the size of your parity disk not your array size. Then would you agree that changing "Total Size" to "Parity Size" would make more sense? --Sideband Samurai
July 5, 201313 yr That's normal it is telling you the size of your parity disk not your array size. Then would you agree that changing "Total Size" to "Parity Size" would make more sense? --Sideband Samurai While I suppose that's true, it's also been shown that way as long as UnRAID has been in existence. The actual number of bytes that have to be read is the sum of all of the bytes on all of your drives (including parity) ... but since all disks are read at the same time, the counter simply has to go up to the size of the parity drive (the largest drive). Not sure it really matters how it's labeled as long as you understand it. For that matter, that line could be omitted and you'd still have all the info you needed about the current status of a parity check.
July 5, 201313 yr The GUI has gone unresponsive for me on 3 different machines. All was fine last night, went to bed, got up this morning and all 3 just spin. Anyone else? John
July 5, 201313 yr The GUI has gone unresponsive for me on 3 different machines. All was fine last night, went to bed, got up this morning and all 3 just spin. Anyone else? John Just check mine and it is fine using stock web GUI. You using stock or simple features? Reason I ask is that last couple of rc's I've found simple features to be a bit unstable so I removed it. Will revisit post final one a new version comes out. Sent from my Nexus 4 using Tapatalk 2
July 5, 201313 yr The GUI has gone unresponsive for me on 3 different machines. All was fine last night, went to bed, got up this morning and all 3 just spin. Anyone else? John Just check mine and it is fine using stock web GUI. You using stock or simple features? Reason I ask is that last couple of rc's I've found simple features to be a bit unstable so I removed it. Will revisit post final one a new version comes out. Sent from my Nexus 4 using Tapatalk 2 I do not use any plugins or GUI enhancements, however, I do PXE boot unRAID. EDIT: After about 5 minutes one of the GUIs showed up. However, I clicked the Refresh button on the main screen and she is just spinning again. I'll keep and eye on this behavior and see if it continues. If it does, I will revert back to using a VMDK rather than PXE booting to see if that resolves the issue. John
July 5, 201313 yr Just saw this message pop up in the syslog... Jul 5 07:15:01 unRAID emhttp: returnFile: sendfile /usr/local/emhttp/logging.htm: Broken pipe Possibly related to PXE booting unRAID? John
July 5, 201313 yr Just to clarify the release notes (http://lime-technology.com/wiki/index.php?title=UnRAID_Server_Version_5.0-beta_Release_Notes)... Should the last Upgrade heading read "5.0-rc9 through 5.0-rc15a"? (it currently reads "5.0-rc9 through 5.0-rc1") Yes. To make it simple, all you need to do with any of the RC's is: (a) Stop the array (b) Copy bzroot, bzimage, and syslinux.cfg to the flash drive (overwriting the ones already there) © Reboot Done not always true. best course of action is to read the release notes for proper instructions. one upgrade required syslinux.exe to be run on the flash drive again if i recall (rc12??)
July 5, 201313 yr To be fair, the section I was looking to clarify had those instructions in (replace three files), but there seemed to be a typo in the heading that made it ambiguous as to whether it applied to my scenario.
July 5, 201313 yr not always true. best course of action is to read the release notes for proper instructions. one upgrade required syslinux.exe to be run on the flash drive again if i recall (rc12??) You only need to re-run syslinux.exe on your flash drive IF it fails to boot after copying into place the new bzroot/bzimage files. The new syslinux.cfg file adds a "safe boot" option to the menu upon boot up. It is not critical the upgrade, but the extra choice will help those trying to determine which add-on might be causing issues when booting. I never had to run syslinux.exe here, as my flash was able to boot the newer versions just fine. It most likely that those on very old versions of unRAID who are upgrading might find an error when upgrading part way through the boot process, or, possibly those with very large flash drives. (mine are 1Gig drives, and are small compared to some these days)
July 5, 201312 yr When the Web GUI seems to be unresponsive, try closing Internet Explorer; then open it again and go to the Web GUI. I've found that this often results in an instant response from the Web GUI. No idea why ... but it works
July 5, 201312 yr I agree that the Free Space computation in the latest version doesn't make sense. For a given share, the latest RC is only showing total free space on the drives that the share has already stored data upon. It is excluding free space on drives that the share is eligible to write upon but has not yet utilized. For a share on the protected array, free space should equal the sum of all free space on all drives on which the share is allowed to write. Cache space should never be included in these totals, even though unRAID will allow writing beyond the array limit until the cache drive is full. When we write to a share on the protected array, we expect it to be protected immediately or after the next scheduled mover script execution. Thus, the array should be presented as full when there is no more protected space available for it to use. For a share on the cache drive or flash drive, free space should be the remaining free space on the drive itself. Apart from this minor issue, the RC16b is running great after my upgrade from RC15.
July 5, 201312 yr The simple fact is that any free space computation is going to be flawed on a system that has multiple shares that can all draw from the same pool of available storage. Unless UnRAID was to provide a "per share" allocated space limit, this really can't be "fixed" ==> note that I do NOT think this should be done, as one of the nice things about UnRAID is it makes it very easy to have effectively unlimited storage for your shares ... just add/upgrade disks as required.
July 5, 201312 yr When the Web GUI seems to be unresponsive, try closing Internet Explorer; then open it again and go to the Web GUI. I've found that this often results in an instant response from the Web GUI. No idea why ... but it works Yep...done that. Didn't help. I'm going to go back to a VMDK to see if it continues. John
July 5, 201312 yr I completely agree with you stewartwb, just incase you did miss Tom's post he does admit there is a bug with the free space calc, so I guess final or rc17 should have the fix included :-)
Archived
This topic is now archived and is closed to further replies.