neilt0

128,000TB. I believe that's the current 48-bit LBA BIOS limit.

I'm pretty sure it doesn't supply power. Just split off the Molex power in the top bay.

No, they run extensive tests, and have documented what they do. It used to take days, but I think it's faster now, since they switched to faster HBAs.

My hack has been incorporated (in a way) into nzbget as a RAM cache, so the hack is not needed. Also, I switched my cache drive to BTRFS, so writes are faster.

A 4TB drive that's dead after a year is not in my plan! 3 years, yes.

I'm happy paying extra for the warranty alone. You can pay a little extra and get a 4th year's warranty for the WD Reds. Compare that to the cheap Seagate DM I bought a year ago with a 1 year warranty, which do you think is the better deal?

I don't think the official HP BIOS runs all the SATA ports at full speed: http://n40l.wikia.com/wiki/Bios That's the main reason why people upgrade the BIOS. But, if you never use ports 5 and 6 for hard drives, it won't matter.

I can't recommend anyone to flash a BIOS if they don't know what they're doing... But, having said that, the wikia is a good resource. The Microserver is not a new design and has actually been replaced with a new model for a while. My (latest model) N54L is running the custom BIOS.

Correct, but I'd do it anyway.

The custom BIOS allows you to run SATA ports 5 and 6 at full speed. They are the internal SATA port and the e-SATA port at the back. If you plan on using more than 4 drives, you should upgrade the BIOS: https://www.google.co.uk/search?q=hp+n54l+custom+bios&oq=hp+n54l+custom+bios&aqs=chrome..69i57j0l3.11676j0j4&client=ms-android-motorola&sourceid=chrome-mobile&espv=1&ie=UTF-8

I voted 8GB. One has 8GB, the other has 3GB.

Well, that's just idiotic. Restricting access to BIOS files when the BIOS update fixes issues like not being able to boot an OS? My N54L has a warranty to June 2014, so I signed up and gave them my serial number. I then had to login about 5 times before they'd give up the bloody BIOS, but I have it now. If you need access to the official BIOS, PM me. I won't send it to you, of course. That would be crazy. I don't even use the official BIOS -- I use the hacked version that enables full SATA speed on all ports, but you may need the official BIOS installer to install it.

12MB/sec suggests one part is operating at 100mbps. Sent from Moto G using Tapatalk

It will be displayed in the syslog after the parity check. It'll show the number of seconds. I took that and divided (in my case) 2TB / #seconds = overall speed. You can also see the speed in realtime from unmenu mymain and maybe even the default web interface?

I don't think write caching matters in terms of write security because unRAID writes, then writes parity, then reads it back, I think -- otherwise it doesn't count as a write. Something like that. Others may know better.

That's slow. I have an N36L with similar drives (WD 2TB Green are the slowest I have, I think). That did a parity check at 91.94 MByte/s. I think I'm running stock disk settings. I have 3GB of RAM in that box. Disk Settings Enable auto start: Default spin down delay: Force NCQ disabled: Enable spinup groups: Default partition format: Tunable (md_num_stripes): default Tunable (md_write_limit): default Tunable (md_sync_window): default Done The speed for a parity sync will be low if you haven't switched on the write cache in the BIOS and/or you are using any SATA ports other than the standard 4 and haven't upgraded the BIOS. I imagine it's because you haven't switched on the write cache, as detailed in the first post in this thread.

I don't know much about the Pico PSUs -- there are others in other forums who have used them. From my experience, the 150W PSU in the Microserver is enough to power 7 modern "low power" drives. That means either NAS drives, "Green" drives or low-power 7200rpm drives like the 4TB Hitachis. Older 7200rom drives draw 2x the power of new ones. I think you may get better power efficiency with the Pico, but it's not like a MicroServer draws much power anyway, once the drives have spun down. And those Pico PSUs/bricks aren't that cheap.

The threshold for larger drive support (64-bit LBA) is 2.2TB. Therefore if mobo/BIOS supports 3TB drives (actually 2.5TB, but those drives weren't too popular) then it will support much bigger drives than 3TB. The next limit is not 4TB, it is 9.4 billion terabytes. The reason why 3TB was mentioned so often is threefold: 1) It is 3TB drives that generally resulted in the 64-bit LBA being required. 2) At the time it was being discussed, 4TB drives weren't available. 3) The mfrs would only mention 3TB as that was all they had tested. So, in theory, 4TB, 6TB, 8TB, 8000000000TB drives should all work. If you search this forum for "3TB Microserver", you can see that 3TB(+) drive Microserver support was discovered way back in 2011: http://lime-technology.com/forum/index.php?topic=11585.msg125618;topicseen#msg125618

The N36L and N54L are essentially the same machine with different CPUs. Both support 4TB (and higher) drives. I run both and run unRAID on both. One server is on all the time and the other is an archive server. You may be able to use the N36L as a drive enclosure, but it'd be a horrible hack. I have 8 drives attached to my N54L (7x 4TB + cache, one drive is external).

http://www.avforums.com/threads/hp-n36l-n40l-n54l-microserver-updated-ahci-bios-support.1521657/

No. The hardware doesn't support sleep. Some have enabled power off and LAN wake from power off, but I don't bother because the power usage is so low.

I had a discussion with hugbug (the author of nzbget) and we worked out that this tweak is only valid if you are using a FS that works best without DirectWrite switched on -- which is the case with ReiserFS: http://nzbget.sourceforge.net/forum/viewtopic.php?f=3&t=957&p=6113#p6113

Reading up on tmpfs, it appears to limit the size to 1/2 the RAM by default (which is a good thing). Does that still apply to Slackware/unRAID? http://en.wikipedia.org/wiki/Tmpfs#Linux

Yes, but the problem with using an SSD is a) cost and b) limited writes Using RAM and a (spinning) hard drive is is faster (the RAM part at least) and not really limited when it comes to writes (the hard drive). Because the assembly process requires 2 writes, and I'm writing a lot of data to the drive each month, an SSD could be dead in about a year, according to the specs.

Hi, I had a bit of a brain wave today -- I remembered from somewhere that /tmp/ was a magical, expanding RAM disk and I figured I could use it to speed up nzbget... ...in fact I am currently doing so, and holy poop, does it work! But, I figured I should post a query here to make sure I don't blow anything up. Here's my config: * HP Microserver N54L (2.2GHz dual core) * 8GB RAM * 7x 4TB array drives * 200GB Seagate 7200.2 2.5" cache drive (relatively slow) * 105megabits/sec cable internet (soon to be 120-133megabits/sec) * SuperNews News Service Provider nzbget 12 usenet client (this tweak may also apply to SABnzbd) The main issue is that with such a fast internet connection, to utilise it fully, I am using 28 NSP connections, so you have 28 simultaneous writes at a total 12MB/sec to a relatively slow cache drive. The drive can almost keep up, but not quite, and then of course you may see a simultaneous download and par repair or simultaneous download and unpack, hitting the drive even harder. I used to use one of the 4TB drives as a cache drive, and it was pretty quick, but I decided to move that to the array and use my spare 7200rpm 2.5" drive to save power, heat and also so if it died there couldn't be too much data on it. The way that nzbget works (as do virtually all usenet clients) is that it will retrieve segments of an individual rar to a temp folder (temp). Once that rar is complete, it will assemble those to an intermediate folder (inter), then when all the rars are done, it will unpack to a destination folder (dst). Like so: temp UbuntuAnimalName.part001.rar.001 1.3MB UbuntuAnimalName.part001.rar.002 1.3MB UbuntuAnimalName.part001.rar.003 1.3MB UbuntuAnimalName.part001.rar.004 1.3MB ... inter UbuntuAnimalName.part001.rar 100MB UbuntuAnimalName.part002.rar 100MB UbuntuAnimalName.part003.rar 100MB ... dst UbuntuAnimalName.ISO 4.5GB I have set dst to be on an array drive, and that speeds up unpacking, but I have the temp folder on the cache drive and that was really slowing things down. So, I set nzbget to use /tmp/nzbget-temp as the temp folder and boy, oh boy has it sped things up! The download speed used to fluctuate all over the place from 11,000KB/sec down to 8,000KB/sec then 10,000KB/sec, then 12,0500KB/sec (the line speed). Now it's pretty much locked on at 12,500KB/sec. The temp folder holds the parts of a rar as it's being downloaded, then it's built (joined) in to the inter dir. So, the space required for temp is a function of the size of the split RAR. I've seen .partxxx.rar RARs up to 1GB and right now I'm testing with 500MB rars. During the joining phase, nzbget will download the next RAR, so assuming the join completes before the second RAR is downloaded, you need 2x the RAR size. So far, with 500MB rars, I've not seen the temp folder go over about 1.2GB. With 8GB of RAM, I'm seeing 2.5GB utilised. So, my question is, is there anything inherently bad about using the tmpfs (if that is what it's called) ? I can't see it ever using more than 2GB even in a worst case scenario, as it's always emptying itself to the cache drive. Secondly, is there any danger of using "too much" lowmem, or does the RAM disk not use lowmem? And finally, is there a way of limiting the size of the RAM disk -- I'd be happier if I could limit it to, say, 4GB. Cheers! Neil.