-
Posts
10,186 -
Joined
-
Last visited
-
Days Won
196
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Report Comments posted by limetech
-
-
Not sure if there is an action item for us here or not, so changing status. OP can re-open if you think there is something we need to do.
-
1
-
-
Changed Status to Closed
-
44 minutes ago, IamSpartacus said:
EDIT: When I run the commands manually, it tells me "Couldn't chdir to /unlock: No such file or directory" when I try to mount the cifs share. I can't cd to it but I can see it in Midnight Commander but there is a period after it so it shows as /unlock.
If somehow the /unlock. was created instead of /unlock that would explain behavior. What do you mean by "cron job code in your GO file"? Do you mean those lines are in your 'go' file or that you are setting up an actual cron job to execute?
-
There was a kernel patch we used in 6.3.5 release that addressed an issue with Threadripper 'reset'. This patch no longer worked with 4.17 kernel in 6.6.0 and upon investigating, AMD provided updated bios that addresses that issue.
Probably this is a different issue. I think 4.18 kernel has specific patches for Threadripper, but the Intel 10Gbit ixgbe out-of-tree driver does not compile with 4.18 and we have been waiting for an update:
https://sourceforge.net/p/e1000/bugs/625/
This is the problem we face in using OOT drivers: often we get stuck on a specific kernel.
If we don't see updated driver soon then we will revert back to stock ixgbe driver and move on to the 4.18 kernel.
-
Please check if there is a bios update available for your m/b.
-
On 9/1/2018 at 2:39 AM, johnnie.black said:
Most likely unRAID only checks the number of cache devices, and if >1 considers it's a protected pool, since raid1 is the default pool mode, and doesn't actuality check the btrfs profile in use.
Correct. The 'proper' fix for this is to make btfrs raid0/1 selectable, something we plan on adding.
-
What Brit said. Note this is -rc1 release. We anticipate lots of small tweaks and fixes such as these over the next few -rc releases before publishing stable.
"Why didn't you guys address some of this before public release?", you might ask. The answer is, take a look at the change log - there are numerous under the hood updates in every subsystem, including security updates. We are a very small team and decided it was important to get this published asap and fix the cosmetic stuff as we go.
-
Are you saying you want to use 800x600 or that a higher resolution is being output to your monitor?
-
A reminder: this thread is for general discussion and not meant to report and solve specific problems. If you report a problem in this thread, instead of creating a separate topic for it in this board, you may receive support but you should not expect it. PLEASE open separate topics here.
-
Changed Status to Open
Changed Priority to Minor
-
getfattr() is only called by 'in_use' script to ask shfs what is the actual device where the file exists (and thus where it will show up in 'fuser' output). If shfs keeps track of open files, 'in_use' would not be necessary. However, the danger with this is that a file could be opened via the disk share and shfs would not know about it.
That is, suppose we are moving /mnt/cache/share/test1 to array. If a process has /mnt/user/share/test1 open then we can detect this and skip this file. But if process bypassed shfs and opened /mnt/cache/share/test1 directly, then shfs would not know this (but in current implementation 'in_use' would catch this). This might be problematic. There is no way to ask kernel directly if a particular file is open or not AFAIK.
Edit: the other complication here is that vdisk images mapped using loop back file system do NOT show up in 'fuser' output, those have to be checked using 'losetup -j'. The VM Manager will open those files directly, that is, not via shfs.
-
Yes I've been meaning to add spare file support. This would be handy when backing up vdisk images.
-
2
-
1
-
-
Changed Status to Open
Changed Priority to Minor
-
After your test run, does file test1 appear on both cache disk and array disk? Probably does.
Maybe can solve this by having shfs keep track of open files internally. This would also let us eliminate the very-expensive (in terms of overhead) call to 'fuser' for every file.
-
Changed Status to Open
-
This is one of the intended use for 'system' share.
I will update this report to 'Open' so that it stays on my radar
-
26 minutes ago, Peter Kejser said:
i know its a "tiny" server compared to i3 and i5 and what not, but im not demanding much, actually only redundancy of what i store and the abillity to read and write files to it and stream a file from it now and then, i guess i could have gone with tinylinux, but i´m not tech savy in linux, and unraid is "simple" plugin drives and keep the biggest drive parity. Thats why i chose unraid.
Kind regards
Peter
Yes we are trying not to neglect the small NAS use cases since that's unRAID's heritage. The download has grown pretty large over the years with addition of console GUI, docker, virtual machines, and ever increasing set of device drivers. We are looking at ways to remedy this situation.
Did you happen to try the upgrade with array stopped? Another thing you can do is first reboot in 'Normal/Safe' mode - this will prevent console GUI code and any plugins you might have from loading into RAM. Then try the upgrade. Sorry for the inconvenience.
-
Changed Status to Solved
Changed Version to 6.5.2
-
Changed Status to Closed
-
Yes I think this has been addressed.
-
10 hours ago, itimpi said:
I would it is time to update the minimum requirement for unRAID v6 to be 2GB?
Yes we need to think about this one...
-
Changed Status to Solved
Changed Version to 6.5.2-rc2
-
Thank you for the report.
-
Changed Status to Retest
Changed Priority to Minor
Intel pstate Driver Changes
-
-
-
-
-
in Prereleases
Posted
Changed Status to Closed