WeeboTech

Is there anyway to put the count of files read in the dir_cache program? maybe that could provide a benchmark of when it exceeds it's usefulness. I know I couldn't run it on my server. I had over 250,000 files on some drives.

I just tested this by hand, here are my results. root@unRAID2:/# dd if=/dev/zero of=/mnt/user/swapfile bs=1M count=256 256+0 records in 256+0 records out 268435456 bytes (268 MB) copied, 3.08609 s, 87.0 MB/s root@unRAID2:/# mkswap -L SWAP /mnt/user/swapfile mkswap: /mnt/user/swapfile: warning: don't erase bootbits sectors on whole disk. Use -f to force. Setting up swapspace version 1, size = 262140 KiB LABEL=SWAP, UUID=77b9d51f-163b-43a8-8977-71b3e709470e root@unRAID2:/# swapon -v /mnt/user/swapfile swapon on /mnt/user/swapfile swapon: /mnt/user/swapfile: found swap signature: version 1, page-size 4, same byte order swapon: /mnt/user/swapfile: pagesize=4096, swapsize=268435456, devsize=268435456 swapon: /mnt/user/swapfile: swapon failed: Invalid argument root@unRAID2:/# swapon -v /mnt/disk1/swapfile swapon on /mnt/disk1/swapfile swapon: /mnt/disk1/swapfile: found swap signature: version 1, page-size 4, same byte order swapon: /mnt/disk1/swapfile: pagesize=4096, swapsize=268435456, devsize=268435456 root@unRAID2:/# top -b | head top - 20:16:42 up 2 days, 1:24, 3 users, load average: 0.22, 0.12, 0.08 Tasks: 72 total, 1 running, 71 sleeping, 0 stopped, 0 zombie Cpu(s): 0.0%us, 0.1%sy, 0.0%ni, 99.7%id, 0.1%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 4146032k total, 616828k used, 3529204k free, 7608k buffers Swap: 262140k total, 0k used, 262140k free, 498764k cached

OK that makes sense now. Try creating on the disk mount point instead of the user share. /mnt/cache/.swapfile or something like that. What I've just read, is that it could be that the file system does not support swap. usershare being a filesystem in user space. I just created a swapfile manually on my /mnt/disk1/.swapfile and I was successful

Also WHERE are you swapping to? What filesystem area?

Can you remake the swap file? Or is it a swap partition?

So is there a known limitation in terms of "files/directories" that can be cached with current 32bit architecture? There is, and when I expanded it, bad things started to happen. I have no idea if 64 bit will help this.

It doesn't help to check there as I thought it would. I know what has happened in the past. I booted with a parameter to double dentry and my machine still spun up the drives (because I have so many files). Later on the machine had failures and crashed due to being out of low memory. I then tripled the memory, being a glutton for punishment, and the machine crashed soon after being out of low memory. Granted my bittorrent drive had tons of files, but so did my ftp pub folder, my mp3 folder and my backup folder. There was no way to get around the sheer magnitude of files I was dealing with. There was a kernel boot parameter you can use. I forget what it was, that could resize the dentry cache. You still have to adjust a kernel parameter to prevent it from shrinking the dentry cache upon cache pressure. This may be different with the later releases of the kernel. I don't know, I cannot tell at the current time.

It's the dentry cache. On my other linux system here's a snipped. rcotrone@rgclws:~ $ grep -i dentry /var/log/dmesg Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes) sizeof(dentry)=192 bytes It's probably different for unRAID. FWIW, I tried expanding it once, it sorta worked, then I received an OOM condition and the machine started crashing. It uses low memory and low memory was exhausted. maybe this will change when unRAID goes 64bit.

Plus there is no guarantee they will stay in ram and/or be flushed. If there are that many small files that you want to be read at high speed, using an SSD would be better. other choice is to put allot of ram in the system and/or use a tmpfs. SSD is probably better. While investigating today, I found a some cool products that can use mSATA in a PCIe slot. (if you don't have enough room for a 2.5" ssd).

I do all of my unix work from the unix command line. This is my trade and I can type fast enough that it's faster for me to do it that way. it's also my 'usual' way I update the flash files. wget unzip reboot

infozip is available here as a slackware package. http://slackbuilds.org/mirror/slackware/slackware-13.37/slackware/a/infozip-6.0-i486-1.txz'>http://slackbuilds.org/mirror/slackware/slackware-13.37/slackware/a/infozip-6.0-i486-1.txz http://slackbuilds.org/mirror/slackware/slackware-13.37/slackware/a/ wget the file. then do installpkg infozip-6.0-i486-1.txz this will install zip and unzip. mkdir a bin directory on the .vmdk filesystem. copy the unzip program into that bin directory. (or leave it in the root directory, that's up to you). This allows more tech savy people to mkdir /mnt/bootvmdk mount -L BOOT /mnt/bootvmdk cd /mnt/bootvmdk wget the newest unRAID.zip archive. unzip the bzimage and bzroot right on the .vmdk. ./unzip "unRAID Server***.zip" bzimage ./unzip "unRAID Server***.zip" bzroot Perhaps in the future we'll even be able to pull out the unRAID version number from the bzroot and name the bzimage/bzroot accordingly. For now having the unzip binary immediately available makes it easier to help oneself. i.e. Unless we can get Tom to include zip/unzip on the distro.

@Beta, do you think you could put the unzip binary on the .vmdk perhaps in the bin directory? It would allow people to mount the filesystem. Issue a wget and unzip the files they need directly on the .vmdk Only reason I suggest this is unzip is not part of the standard distro. Is it possible to expand the .vmdk to a larger capacity without actually increasing it's size? I.E. enough for 3-4 versions of unRAID. production/stable RC development .zip archive. Also, do you have a default LABEL on the virtual disk? I know mine say BOOT, but I also remember changing them on purpose so I could mount them via -L mkdir /mnt/bootvmdk mount -L BOOT /mnt/bootvmdk It's silly, but I cannot remember if the BOOT label is from your default or mine. My issue regarding label and size is specific to developing some workarounds via the booting rc scripts. So I need to unpack and repack the bzroot while keeping a few versions around. I figured if you make the associated changes, people can also help themselves with the support program and space to grab the .zip archive.

I would wait a while. There are problems with the syslinux.cfg and the default boot option. If the Virtual machine has less then 4GB unRAID it will not come up or it's going crash at some point in time. Either that or edit the syslinux.cfg and move the default from the mem=4095M entry to the entry without it. It would be easier to upgrade unRAID live! if unzip were part of the standard distro. You could do a mount of the virtual disk, wget the latest entry, unzip bzimage/bzroot into /tmp. copy them to the virtual disk and reboot.

Allot of this depends on how many files you have on your disks. The greater the amount of files, the greater the chance that file entries will be flushed out of the dentry cache. It depends on low memory, plus there's a fixed max size of the dentry cache. When I last looked at the kernel code it was also pretty aggressive in recapturing dentry nodes that were not accessed or exceeded the limit. As an experiment I booted with a parameter to expand the dentry cache. It did not work for me. In fact it caused OOM conditions. I know my environment was different. While others enjoyed the benefit of directory caching, I could not *sigh*. My download/bittorrent drive had so many files that it would just exceed all limits. Along with my rsync_linked_backup methodology, the file count was ginourmous. I wonder if we are seeing a trend with the new kernel or it's the amount of files on the filesystem. Have you tried capturing the files in a list with find. find /mnt/disk1 -ls > /tmp/filelist.disk1 you can do that for each disk. Then do. wc -l /tmp/filelist.* @Joe L, is there a max depth option for dircache?

I used it on an old Kuro box. (remember those?) I put all of my boot floppy images and removed all the floppy drives from my network. It's good for those times you need to boot a floppy image with a bios update.

I like PXE boot too, it also requires a DHCP and TFTP server somewhere. Sure would be great if we could get a statically compiled TFTP server on ESX... Hmmm sound like a fun project. Although updating a .vmdk is trivial also. While you are in unRAID, telnet in. wget the newest unRAID .zip archive. rename current bzroot to bzroot.versionnumber, rename current bzimage to bzimage.versionnumber. or use .bak i.e. mv bzroot bzroot.bak mv bzimage bzimage.bak (I happen to use version numbers). Update the syslinux.cfg to add an entry. Then unzip unraid.zip bzimage unzip unraid.zip bzroot reboot.

From Wikipedia.... Ahhh. There we are Open Virtualization Archive. At least that one fits the best. http://www.openvirtualizationalliance.org/

I'm simpler, 1 virtual socket, 1 virtual core. I run other VM's. So my setup needs to leave the other core unused.

I noticed slow down when accessing multiple drives on the same eSATA cable to a Port Multiplier Box. I did not test to multiple boxes on multiple eSATA cables. I would assume that accessing one drive on each box at a time would provide close to maximum speed for each drive. The PCIe x1 card is capable of 250MB/s in each direction (i.e. full duplex). Keep in mind the silicon image chipset is not the fastest port multipler chipset. I believe speed is limited to DMA/100. However, it was the smoothest I've seen when accessing multiple drives on the same eSATA cable. I do like the RC-218 card. I had one. The driver at that time was a lil slower then the Silicon Image chipset. It initialized faster i.e. UDMA/133, but it was slow accessing multiple drives. That may have changed since my tests with that card were quite a few years ago. In fact during the infancy of Port Multiplier Support in unRAID. I had also tried the JMB363 chipset with mixed results. Today's results may be very different from years ago.

I don't have that kind of setup. I.E. I have unRAID under ESX on a N54L. I don't use usershares or a cache disk in my configuration. I figured I would post so you knew I wasn't ignoring you.

Let us know how it works out.

That particular SYBA card is no longer available. It was a SD-PEX40031. I bought it used on eBay knowing it was not produced or available any longer. I bought it specifically because it had 4 ports, It uses some kind of bridging chipset for the PCIe to PCI-X. I'm not sure I would recommend that one specifically. I moved that to my ESX host. I'm currently using the addonics and the startech SATA III controllers in my N54L.

I'm one guy, but I'm a programmer and a power user. I alone access multiple drives simultaneously. Since the unRAID server is my file server, all my documents, music, source and downloaded files go there. At the same time I have a bittorrent laptop that is continually downloading there. Then there is the HTPC constantly reading and playing music. I don't use unRAID just as an archival server, I use it as my main file server. For me, there was an issue of latency, blocking and stuttering. Smooth coordinated access could have an impact. It all depends on usage and simultaneous access. While I have not tested parity check speeds with some of the lower performing PMP devices, 10MB/s to access the drives will surely impact your parity check speeds to the point of being unusable.

Have you used the R622 with Port Multipliers? If so were you able to benchmark multiple drive simultaneous access? I.E. DD from the raw drive in parallel. I'm curious if the High Point drivers handle it as smoothly as the Silicon Image cards. While 30MB/s simultaneous access of 4 drives isn't that fast these days, I found that multiple drive access did not choke out the other drives.