nars

How would we test this ? "execute-disable bit capability", if I'm not in error disabling it should also disable pae (at least on my desktop pc with XP it only shows PAE enabled when such option is enabled on bios).

Just an idea... anyone running unraid native (not on vm) tested to just disable nx bit at bios setup (it should disable pae I think?) and see what happens? that way it should disable pae for sure, I'm not sure if mem=4xxx actually do same as... remember that video memory and other pci allocations will take space on addressing (size depending on hardware) and I guess mem param really limits only ram then there should be still pae working for some few MB's...

From what I can read some few posts I think there are some people (not many) probably getting a bit scared by reading this topic and thinking that Tom may release a broken version of unRaid as final just due to pressure put on him... the thing is not exactly like that... unRaid seems stable, from what I can understand Tom made small changes on latest RC's, other than fix small bug's that can't be related with "the problem", also updated samba and fuse (minor versions that should only also fix bugs on these and can't be related to "the problem" either) and... new linux kernel version (3.4.x vs 3.0.x) included, for some good reason Tom had to upgrade it, and downgrading will almost for sure cause other problems with other users. The new Linux kernel version included is not some "crap" alpha/beta/whatever kernel... it's a kernel released by "Linux guys" as being "stable", any other Linux distro could be released with it (could also be a good test if anyone with that MB could test a distro with similar kernel, x86 flavor and see if same problem just to be absolute sure it is not unraid specific problem, then test x64 flavor and see what happens)... there is apparently an issue with that kernel and a specific motherboard, and apparently not even on all users with that motherboard (there is an unconfirmed suspicion that maybe only users with >4GB ram? some specific bios settings?). What if the issue is (let's suppose) related to a bios bug, on that specific motherboard, that only happens with >4GB ram and with something new that is actually properly implemented on the new kernel? (and that being correctly implemented then it may NEVER be fixed/reversed/workarounded)? will unRaid release be delayed and wait forever for kernel to be "fixed"? problem may not happen on x64 kernel, as memory is handled by other ways, etc... and users with >4GB will usually use x64 kernel anyway on major Linux distros, then one more reason that no one may care about fixing/workarounding the problem on kernel (or on BIOS if a bug on it). I know this is just a supposition, anyway it may be the case and then it may not make sense to just sit and wait kernel guys to sort the issue, problem needs if possible to be identified with more tests etc, if no conclusion and not anyone else with other hardware have same problem then I think there is only one thing to do... release it and look for another solution for these users with the problem, possible start working on x64 version, but... a x86 version is also needed to be released anyway (there are most probably still users with some non x64 machines, p4's etc) and there is no reason to only release the current x86 when there is also a x64 version available... right?

I could see 2 or 3 guys that posted saying that have that x9scm and no write performance issue (excl. BetaQuasi as he is probably using unraid on esxi not native)... would be interesting that users with that specific MB compare whole hardware specs and bios settings to try to get some conclusion. Concerning release v5 or not, IMO this must be only a Tom decision as... we are fully aware of the situation, we have the version available, and we can use it or not, doesn't matter how it is labeled... and it's Tom that may "suffer" with the release getting support issues... on the other hand 4.7 is also far from perfect version from what I could read (never used it myself)... then... I would say maybe wait just a bit more (1 week, 2 weeks... after so much time the v5 is pending it would not hurt...) and see if users with that motherboard can get to some conclusion... or even any chance you Tom could get such MB and check it? Else if the conclusion it's just it is really kernel related and no fix comes up then release it... else v5 will be rc forever... then look at building x64 kernel, etc... anyway I guess you will either continue maintaining both 32 and 64 bit flavors (as some users may still have old non 64bit capable hardware) or just leave current v5 as latest 32 bit capable version (if you don't plan to always release both)? in either case you will need to call the 32 bit flavor final even including this issue. p.s. Tom: if you release v5 don't forget the ftp thing (not sure if you did see my 2nd post about leave only root access and a possible good vsftpd config following some tests I made)

Very good point. I'll fix that for final. Thanks. Btw, thinking a bit more... I think maybe you can actually do better than disable ftp by default... you can actually leave it accessible only for root user by default... surely it's ok that anyone having root login can (and will anyway) access whole server... I have been doing some tests with that and this was the best config I could get for vsftpd to do that: # vsftpd.conf for unRAID # write_enable=YES connect_from_port_20=YES # # No anonymous logins anonymous_enable=NO # # Allow local users to log in. local_enable=YES local_umask=0000 local_root=/mnt check_shell=NO chroot_local_user=YES # # Allow only users on vsftpd.user_list userlist_enable=YES userlist_deny=NO userlist_file=/etc/vsftpd.user_list # # Logging to syslog syslog_enable=YES log_ftp_protocol=NO xferlog_enable=NO # # Misc. dirmessage_enable=NO ls_recurse_enable=YES then create a file at /etc/vsftpd.user_list with just 'root' (and anyone may easily allow other users to access ftp just by adding allowed usernames there... or even to add other users with different root dirs by just making use of user_config_dir and then overriding root dir for that user...) Notice that I did changed local_umask so that the ftp will create files/dirs with similar permissions as the ones created by smb, and also enabled chroot_local_user, I don't see why use guest_enable as before to make all files owned by root (even if using more allowed users than just root) as even smb creates files owned by logged users then ftp will just be doing same... anyway if for some reason you think guest_enable is required then you should also look at setting anon_umask or files/dirs will be created with wrong permissions.

Just noticed that with the new o+rw permissions now the included ftp server works "out-of-box" what is in part good... but... remember that ftp gives access to all data on the server... and this may be a security problem in cases that a specific user is supposed to access only specific shares etc... as such user using ftp with his login details will have whole access to all data on the server. Think it may be a bad idea to leave this as default for the final version... maybe better idea to disable ftp by default? (but make it easy to be enabled for users that want it) Implementing permissions on FTP would be perfect for sure but guess it would require a lot more work for Tom and probably not for an RC version... that's why I suggested just disabling FTP by default instead.

Upgraded from rc9a, so far rc10 is running fine and stable on my server with Realtek 8111F (Asus P8H77-M), same network speed (~110MB/s on both directions, with client PC running W7, a bit less with XP) and same read/write speed on the protected array (120/30-35MB/s) as with rc8 and rc9a. Thanks. Jan 12 09:50:58 unRAID kernel: r8168: This product is covered by one or more of the following patents: US5,307,459, US5,434,872, US5,732,094, US6,570,884, US6,115,776, and US6,327,625. Jan 12 09:50:58 unRAID kernel: eth0: Identified chip type is 'RTL8168F/8111F'. Jan 12 09:50:58 unRAID kernel: r8168 Copyright (C) 2012 Realtek NIC software team

Basic tests seems all OK so far with my Realtek 8111F (Asus P8H77-M), same network speed as with rc8, will post again if I find some problem. Thanks.

Do you plan to run on the unRaid server something specific (video encoding, etc) needing a better CPU? I have a G620 on my server and I'm very happy with it... more than suffice for unRaid (unRaid itself will use almost no CPU) and even for VirtualBox and super cool cpu all the time. In fact G620 seems very similar to i3 2100T, basically 2100T is more expensive, supports HT (is it important?), and comes with low profile (noisier) cooler. Note that a few sites claim that G620 is probably 35W TDP (looking at power consumption comparing with others) and not 65W as Intel claims, being a marketing trick to try to push people looking for low power to the 2100T instead. See some links I still have bookmarked from when I have been researching on cpu for my server, you will find good infos there, benchmarks, power consumption, etc: http://www.anandtech.com/Show/4524/the-sandy-bridge-pentium-review-pentium-g850-g840-g620-g620t-tested http://www.xbitlabs.com/articles/cpu/display/pentium-g850-g840-g620_8.html http://www.avsforum.com/t/1303066/official-sandy-bridge-lga1155-for-htpcs-thread/1470#post_20523711 Also concerning benchmarks, you can maybe get a better idea on performance if you can compare it to other CPU's on cpu-world.com for eg., see: (select Performance tab for benchmark comparatives): http://www.cpu-world.com/Compare/239/Intel_Core_i3_i3-2100_vs_Intel_Pentium_Dual-Core_G620.html http://www.cpu-world.com/Compare/323/Intel_Core_i3_i3-2100T_vs_Intel_Pentium_Dual-Core_G620.html Also just a curiosity my Desktop PC is still a Core 2 Duo E6600, one of the first Core 2 Duo available, from 2006, still not a bad PC IMO and for the usage I need it... now compare it with the actual and super low cost G620: http://www.cpu-world.com/Compare/338/Intel_Core_2_Duo_E6600_vs_Intel_Pentium_Dual-Core_G620.html

You can also get 'clear' on ncurses slackware package, anyway the alias solution will save you some ram for sure

good work should be easier for new users coming as this topic is getting really long.

strange, I didn't needed to add user/pass there... only uncomment noAuth line

You can't probably get much more than that as average speed... I did search on Internet for some HDTune/HDTach test screenshot of your hdd and: http://lord.asmodeus.free.fr/HFR/hardware/HDD/Seagate%20Green%202To/HDTune_Benchmark_ST2000DL003-9VT166_write.png

Yes, could be an idea to include it on doinst.sh, but I don't really mind having it on the go file anyway... Also I think the issue is probably related to the vbox udev rules for usb being added after boot (when vbox package gets installed) then only after we plug a new usb device after the rules are in place they are triggered... guess that maybe an "udevadm trigger" could probably also help on that (I needed it for other similar thing recently)... anyway creating that /dev/vboxusb dir with these permissions is exactly one of the things that the script that is called from the udev rules does after a new usb device is connected. Btw, olympia, just a question, if you share an usb flash drive (not recommended you share the unraid OS one, as that probably could cause problems/corruption...) or an external hard disk... do you get any decent speeds to access such devices from the vm's? I do get really crap speed (see my last post at: https://www.virtualbox.org/ticket/2973 ), please confirm me if you get the same problem.

Just wanted to add that using FastCopy tool produces these results: xp->unraid = 105MB/s and unraid->xp 70MB/s (a bit better than TeraCopy but still not ~100MB/s, and yes tried to increase buffer size, no help). Also tried W7 on the desktop PC instead of XP and... I was able to reach ~110MB/s in both directions using native windows explorer copy function! guess it is a lot more effective for such speeds than in XP... also it should use SMB2 with W7... Interesting though is that Teracopy on W7 is slower than native explorer copy reaching only 50MB/s in both directions (yes worst than in XP, in one of the directions at least...). Maybe I need to live with that for XP...

Same file, I have the cache HDD empty with just two big test files, one with 2GB (the one I used for most tests). As I said before it's not HDD bottleneck at all as testing with dd on server it can read the test file at ~150MB/s at "first read"... and ~6GB/s after cached... server haves 8GB RAM... whole test file get's cached... then in almost all tests the test file was not even actually read from the HDD as it was already cached. I can only guess that it must be related to how smb works, amounts of data sent in each "packet" before an ack or something like that... either at server or at XP machine, anyway strange why can only notice it in one direction, but maybe one of them haves slightly different behavior on size of sent "packets" or one replies acks faster, must be something... I did even tried to add some "socket options" on smb.conf that I did read that could help but no improvement. Re how I measure it, for testing SMB I used most of time Teracopy to copy files to/from the server, Teracopy itself shows copy speed, and for FTP used Filezilla that also shows transfer speed, and... also used a very simple self-made network speed meter software (winpcap based) that measures total speed of data in/out in my windows machine network connection, independently of the software/protocol I did tested, and it did match the values on Teracopy/Filezilla. Also easy to see that a 2GB test file takes ~20s to copy from XP to server and takes ~40s to copy from server to XP. P.S. HTTP download from server can also reach ~100MB/s, seems only SMB from server to XP (not from XP to server as mentioned) is degraded to ~50MB/s

Ok, did further tests and seems not really NIC related, I did now found that I can read from the server at ~100MB/s using FTP, the speed values I did posted on my post above were using smb. Seems I need to search if I can somehow tweak/optimize smb (not sure if at unRaid or at XP?) to get ~100MB/s on both directions... hints are welcome...

I did some tests with my server and noticed that I can write to cache drive over gigabit network at ~105MB/s, however when reading from it I can only achieve ~50MB/s... I'm wondering why I can't also get ~105MB/s when reading from the server? I did tested dd on my server and it's not HDD bottleneck for sure as my cache disk (wd red) can read ~150MB/s... My unRaid server NIC is onboard Realtek 8111F, using the latest unRaid RC version, and my desktop PC NIC is a Marvel Yukon 88E8053, using windows xp... maybe related to one of these two onboard cards? Or software/drivers related? Unfortunately I don't have a 3rd PC with a Gigabit NIC at this moment then it's hard to identify in what system is the bottleneck... Anyone else experienced similar behavior with such big difference in read vs write speed with similar NIC's?

This seems a very basic thing... not sure if this is already a known issue, but I did tried to search on the forum and couldn't really find a similar report... Using 5.0-rc8a, on "SMB Security Settings" for an user share, if we set "Security" as "Private" and leave all users as "No Access" then all users (existing on the unraid server... not guests...) can access that share as read-only. Looking at smb-shares.conf it gets set like this: [nars] path = /mnt/user/nars comment = browseable = no # Private writeable = no read list = write list = valid users = I guess because "valid users" is empty then it's like it is not there at all? and then it isn't in fact like "private"... think this may be misleading for anyone that for eg. had a share set as private and then temporarily wants to refuse all access to a share and sets all users as "No Access" instead of just disabling the export... then it will have just the opposite effect and all users will be able to access it in fact... maybe better not export the share at all if user doesn't set at least one user to access the share, when in private mode, if no better option?

tried to follow your/existing steps but could not get vmnet to compile using the patch you pointed with my rc8a (kernel 3.4.11), also tried without network support and all other modules compiled ok but there is something broken with the web interface also, could only get a light yellow page with title "Loading..."

I did posted last month on this same topic about usb... concerning the issue that usb devices would not get listed unless a new device connected and vbox killed/restarted (like sureguy said on page 16) I did apparently found how to fix it, just use this on the go file before installing/starting vbox: groupadd vboxusers usermod -aG vboxusers root usermod -aG vboxusers nobody mkdir /dev/vboxusb -m 0750 chown root:vboxusers /dev/vboxusb btw, at least on my system it is still very very slow to use usb devices on vm's... in fact slower if I enable usb2 support on the VM settings than if I disable it... with usb2 enabled I can access a pen drive at around 0.5-1 MB/s and with usb2 disable near 3 MB/s... anyone have any idea why this? I did searched a lot and can find other users reporting similar problem with virtualbox, and apparently no solution, but some say they can get it to work a lot better speed...

Anyone could get usb to work properly on virtualbox? I could get it to work once using: groupadd vboxusers usermod -aG vboxusers root usermod -aG vboxusers nobody and then killing virtualbox processes and re-launching them... but it was really really slow (an usb mass storage device could only be read at less than 100KB/s on a VM... really crap...), and also seems a bit tricky to get the usb devices listed as available to virtualbox, only after killing/rerun virtualbox process and connect a new usb device... after that I could get it to work (very slow), else nothing detected at all, even if I add the lines to add the vboxusers group on the go file before the lines to install and run virtualbox...

If you want to use lainie compiled binaries (see: http://lime-technology.com/forum/index.php?topic=10978.msg197022#msg197022) then it will be a lot easier. Note: there is a step missing on instructions, you need to manually create directory at /boot/custom/vbox or vbox will not start.

thank you

I see, thanks for your clarification, concerning storing VM disk image on the array if performance is the only possible issue then honestly it seems rather fast to me, I do have 30-40MB/s write speed and near 100MB/s read speed from the array, it's not that bad for a VM... and from my tests it seems really fast to boot xp on a vm for eg., actually faster than booting xp on a vmware vm on my desktop pc Concerning the /root/VirtualBox\ VMs directory I see now what you mean, it's even possible to set default directory for new VM's on phpVirtualBox settings, I see, just forget what I said. I did also thought about symlinking /root/.VirtualBox to a directory on the array, instead of copy from/to the flash... however I'm not sure if the array is actually started when the go script runs? guess not, at least if we have unraid set to don't autostart the array then it should be no for sure... maybe there some way... some script that is only called when the array is up? will search for that