• Posts

  • Joined

  • Last visited


  • Gender
  • URL

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

purko's Achievements

Community Regular

Community Regular (8/14)



  1. I'd rather have 3.1.5 (current) than 3.2.0. It's more mature. As for nfs, fixes are mentioned a bunch of times in the changelogs between 3.1.0 and 3.1.5.
  2. Right, I forgot about the utility. It was created to help deal with "4K-aligned" hard drives during that code transition period, why do you still want to use it? The tool comes in handy when I preclear new disks. Of course, I can do it without mkmbr, but it's convenient to use it. It's a neat tool all by itself, and it could be even cooler if it could do the 3TB disks. Not a big deal though, I was just wondering if you're planning to update it. --- (Yes, I am aware of the preclear scripts posted elsewhere.)
  3. The `/root/mkmbr` that's included in 5.0-beta13 doesn't work with 3TB drives, right? Will it be updated for 3TB? Or maybe a similar tool that does the same job for 3TB drives?
  4. A little OT, but does anybody happen to have the "5.0-beta7.zip" by any chance? Please IM me. Thanks.
  5. Come on, Weebo, you know well what's stopping it's use: it's a beta. LOL yeah, I agree, but have you tried it and found issues with it? Yes, and yes. I can't ship servers with it.
  6. Come on, Weebo, you know well what's stopping it's use: it's a beta.
  7. I don't know why this whole debate even started. A guy simply said, I wish there's 3TB drive support in unRaid. Well, I too wish that. That's all.
  8. But Weebobo, that's my point: There's no 5.x release. There's no ETA for it. I remember back when -- it was about four months into the 5.x-betas -- when I made a comment something like, at that rate it may well take another four months before the thing gets to stable release... people ganged up on me and called me negative and pessimistic. It's kind of funny now, how overly optimistic that turned out to be. Dare I make a simillar comment today? At this rate, and still without any ETA, I won't be surprised if it takes another two years for 5.x to get to stable release. There. Put me on the stake and fire it up. ------ (December 09, 2009, 01:03:49 PM: "I've already started work on the 5.0 release")
  9. You have no way of knowing any of this, as Limetch is not publicly traded. For all appearances, it is a for-profit company, and is still in business. (If you still want to make guesses though, here's a hint.) But all this is irrelevant, really.
  10. I didn't claim otherwise. Yes, there was a demand for >2.2TB support and Tom added it ahead of the planned timescale. To call it a 'hack' would seem, to me, to be discourteous to Tom and dismissive of all the efforts he puts in to unRAID. Why do you take 'hack' to mean a negative thing? From what I hear, that particular 'hack' is working very well. Sadly, it's not in the official release. What does "spare time/part time project" even mean, when Limetech is a legitimate company that charges money for their software? And are you speaking of behalf of Limetech when you're telling me to go *** myself elsewhere? See, I am not "discourteous to Tom", or "dismissive of all the efforts he puts in to unRAID". You could giult me with such arguments if I was taking the fruits of his labor for free. But since I pay for unRaid, I am equally greatful to Tom as I am grateful to the people who made my TV, or to those who made my toaster. Nothing disrespectful here.
  11. Sorry, but I'm not buying that the goal of 5.0 was to bring 3TB support. If you've followed the announcements from the beginning, their idea was just to make a fancier web-interface, without much changes to the core. The 3TB hack was put together in beta-7. Anyway, I didn't mean to go into discussions about how hard/easy it may be. I am simply saying that I want 3TB support in unRaid. (And before other people start telling me that unRaid already has 3TB support: It doesn't.)
  12. Has the mkmbr utility been updated to support hard drives larger than 2TB?
  13. Well, not THAT static! They should at least be fixing known bugs. And what's wrong with asking for 3TB support when 4TB disks are already here? Keep in mind, we can't use beta software on production servers. Not to mention, the kernel in 4.7 is nine stable kernels old; lots of new hardware has been added since.
  14. It is an unreasonable amount of effort. Support the > 2.1 TB drives requires a newer Linux kernel and tools, which is essentially what the unRAID 5.x series is. It is not an unreasonable request though, seeing how the unRAID 5.x series has been in beta for 14 months already, and the end is anyone's bet. What's unreasonable is that the stable release has been practically abandoned, without any new stable version to replace it.
  15. There've been many discussions in the past about what our bottlenecks are: whether it's the rotational disks, or whether it's the network, or the CPU, etc., etc.. In my particular case here though, it looks like Samba itself is the bottleneck: I have one unRaid server, on which I've never been able to do better than 45MB/s writing and 30MB/s reading. (It is also puzzling to me why reading from the server is slower than writing to it) After troubleshooting everything but the phases of the Moon, it was clear to me that I need a more radical approach: a test without client PCs, without network adapters or cables, without hard disks. For this test, we'll just use RamDisk on the server. All network stuff disconnected, we'll do the test on the console of the unRaid server itself. We'll share the RamDisk over Samba, and then we'll be clients to the Samba service from within the same computer. (Stock unRaid 4.7, stock Samba, no addons, no modifications.) Writing and reading directly to/from the ramdisk looks pretty reasonable: root@Tower:~# dd if=/dev/zero of=/dev/shm/test bs=512k count=400 400+0 records in 400+0 records out 209715200 bytes (210 MB) copied, 0.675903 s, 310 MB/s root@Tower:~# root@Tower:~# dd if=/dev/shm/test of=/dev/null bs=512k 400+0 records in 400+0 records out 209715200 bytes (210 MB) copied, 0.366701 s, 572 MB/s Now let's see how the same ramdisk does over samba. Let's create a samba share for it. In smb-extra.conf: [ramdisk] path = /dev/shm read only = No Mount that samba share locally, and do the same writing/reading: root@Tower:~# mkdir /smb root@Tower:~# mount.cifs // /smb root@Tower:~# root@Tower:~# dd if=/dev/zero of=/smb/test bs=512k count=400 400+0 records in 400+0 records out 209715200 bytes (210 MB) copied, 4.83386 s, 43.4 MB/s root@Tower:~# root@Tower:~# dd if=/smb/test of=/dev/null bs=512k 400+0 records in 400+0 records out 209715200 bytes (210 MB) copied, 6.74039 s, 31.1 MB/s I can't believe the results I'm getting here! Writing 43MB/s and readng 31MB/s from a RAMDISK is just not right. Something is very wrong with samba on this server. Can anybody reproduce these results? (I am also getting the same results when testing with newer samba versions, up to samba-3.5.10.) BTW, the server CPU is 1GHz single core, and the RAM is 1GB. (BIOS timings carefully checked, Memtest ran for days without a glitch) The CPU load never goes more than 60% when writing to the samba share, and the load never goes more than 15% when reading from it. So, CPU, RAM, network, hard disks, all out of the equasion. What's left? Are there any other suspects that could exonerate Samba? Funny thing, when testing with FTP, it's goes the other way around: it writes ~80MB/s to the ramdisk, and reads ~138MB/s from it. (similar setup as above, whithin the same machine, over Any ideas? (syslog attached) syslog.zip