Giraffeninja

Members
  • Posts

    82
  • Joined

  • Last visited

Everything posted by Giraffeninja

  1. I'd just be happy if AFP didn't crash my whole server every time the mover script starts. Same issue since Beta 6, one day maybe...
  2. I followed the steps to remove the super.dat file. I reassigned my drives and pressed start. All drives began "clearing" with the write count going up on the drives and the read count remained the same. Realizing that unraid appears to be formatting my drives I walked over the the server and pressed the power button to start up my shutdown script. After a quick reboot 6/7 drives on the server showed as unformatted while one seemed fine (disk 5 for what it matters). Having nothing of importance on drives 2-7 I ran the preclear script to get the server back online. Assigned the now cleared drives and started the array. The array appears to be functioning now however I am having the same issue I had using 5.4b in that AFP will become unavailable and the GUI for the server will become unresponsive. SMB does appear to stay up. Disabling AFP seems to alleviate the issue but my system log is now showing repeated errors. Mar 17 18:30:21 DarkStar kernel: ------------[ cut here ]------------ Mar 17 18:30:21 DarkStar kernel: WARNING: at arch/x86/kernel/apic/ipi.c:109 default_send_IPI_mask_logical+0x2f/0xb9() (Minor Issues) Mar 17 18:30:21 DarkStar kernel: Hardware name: H57M-USB3 Mar 17 18:30:21 DarkStar kernel: empty IPI mask Mar 17 18:30:21 DarkStar kernel: Modules linked in: md_mod xor pata_jmicron mvsas libsas i2c_i801 i2c_core ahci r8169 scsi_transport_sas jmicron libahci [last unloaded: md_mod] (Drive related) Mar 17 18:30:21 DarkStar kernel: Pid: 13665, comm: dd Not tainted 2.6.36.2-unRAID #8 (Errors) Mar 17 18:30:21 DarkStar kernel: Call Trace: (Errors) Mar 17 18:30:21 DarkStar kernel: [<c1027b52>] warn_slowpath_common+0x65/0x7a (Errors) Mar 17 18:30:21 DarkStar kernel: [<c1015a12>] ? default_send_IPI_mask_logical+0x2f/0xb9 (Errors) Mar 17 18:30:21 DarkStar kernel: [<c1027bcb>] warn_slowpath_fmt+0x26/0x2a (Errors) Mar 17 18:30:21 DarkStar kernel: [<c1015a12>] default_send_IPI_mask_logical+0x2f/0xb9 (Errors) Mar 17 18:30:21 DarkStar kernel: [<c10142d0>] native_send_call_func_ipi+0x4f/0x51 (Errors) Mar 17 18:30:21 DarkStar kernel: [<c1046c60>] smp_call_function_many+0x15e/0x176 (Errors) Mar 17 18:30:21 DarkStar kernel: [<c1059794>] ? drain_local_pages+0x0/0x10 (Errors) Mar 17 18:30:21 DarkStar kernel: [<c1059794>] ? drain_local_pages+0x0/0x10 (Errors) Mar 17 18:30:21 DarkStar kernel: [<c1046c92>] smp_call_function+0x1a/0x20 (Errors) Mar 17 18:30:21 DarkStar kernel: [<c102bb86>] on_each_cpu+0xf/0x1e (Errors) Mar 17 18:30:21 DarkStar kernel: [<c105a48c>] drain_all_pages+0x14/0x16 (Errors) Mar 17 18:30:21 DarkStar kernel: [<c105ab8a>] __alloc_pages_nodemask+0x316/0x450 (Errors) Mar 17 18:30:21 DarkStar kernel: [<c1056f88>] grab_cache_page_write_begin+0x4f/0x8b (Errors) Mar 17 18:30:21 DarkStar kernel: [<c1096386>] block_write_begin+0x21/0x68 (Errors) Mar 17 18:30:21 DarkStar kernel: [<c1099965>] ? blkdev_write_end+0x2d/0x36 (Errors) Mar 17 18:30:21 DarkStar kernel: [<c109998c>] blkdev_write_begin+0x1e/0x20 (Errors) Mar 17 18:30:21 DarkStar kernel: [<c1098e53>] ? blkdev_get_block+0x0/0xc4 (Errors) Mar 17 18:30:21 DarkStar kernel: [<c1055afa>] generic_file_buffered_write+0xb5/0x1a9 (Errors) Mar 17 18:30:21 DarkStar kernel: [<c1056c9b>] __generic_file_aio_write+0x392/0x3d3 (Errors) Mar 17 18:30:21 DarkStar kernel: [<c1099096>] blkdev_aio_write+0x2e/0x6d (Errors) Mar 17 18:30:21 DarkStar kernel: [<c1079fc2>] do_sync_write+0x8a/0xc5 (Errors) Mar 17 18:30:21 DarkStar kernel: [<c1003bf1>] ? do_IRQ+0x86/0x9a (Errors) Mar 17 18:30:21 DarkStar kernel: [<c1191803>] ? __clear_user+0x11/0x28 (Errors) Mar 17 18:30:21 DarkStar kernel: [<c107a7d5>] vfs_write+0x8a/0xfd (Errors) Mar 17 18:30:21 DarkStar kernel: [<c1079f38>] ? do_sync_write+0x0/0xc5 (Errors) Mar 17 18:30:21 DarkStar kernel: [<c107a8df>] sys_write+0x3b/0x60 (Errors) Mar 17 18:30:21 DarkStar kernel: [<c130fb5d>] syscall_call+0x7/0xb (Errors) Mar 17 18:30:21 DarkStar kernel: ---[ end trace 037ddde044816d85 ]--- Mar 18 22:15:01 DarkStar kernel: sas: command 0xf6b1fa80, task 0xf6cc5540, timed out: BLK_EH_NOT_HANDLED (Drive related) Mar 18 22:15:01 DarkStar kernel: sas: Enter sas_scsi_recover_host (Drive related) Mar 18 22:15:01 DarkStar kernel: sas: trying to find task 0xf6cc5540 (Drive related) Mar 18 22:15:01 DarkStar kernel: sas: sas_scsi_find_task: aborting task 0xf6cc5540 (Drive related) Mar 18 22:15:01 DarkStar kernel: drivers/scsi/mvsas/mv_sas.c 1703:<7>mv_abort_task() mvi=c5160000 task=f6cc5540 slot=c517163c slot_idx=x2 (System) Mar 18 22:15:01 DarkStar kernel: sas: sas_scsi_find_task: querying task 0xf6cc5540 (Drive related) Mar 18 22:15:01 DarkStar kernel: drivers/scsi/mvsas/mv_sas.c 1632:mvs_query_task:rc= 5 (System) Mar 18 22:15:01 DarkStar kernel: sas: sas_scsi_find_task: task 0xf6cc5540 failed to abort (Minor Issues) Mar 18 22:15:01 DarkStar kernel: sas: task 0xf6cc5540 is not at LU: I_T recover (Drive related) Mar 18 22:15:01 DarkStar kernel: sas: I_T nexus reset for dev 0400000000000000 (Drive related) Mar 18 22:15:01 DarkStar kernel: drivers/scsi/mvsas/mv_sas.c 2083:port 4 ctrl sts=0x89800. (System) Mar 18 22:15:01 DarkStar kernel: drivers/scsi/mvsas/mv_sas.c 2085:Port 4 irq sts = 0x1001001 (System) Mar 18 22:15:01 DarkStar kernel: drivers/scsi/mvsas/mv_sas.c 2111:phy4 Unplug Notice (System) Mar 18 22:15:01 DarkStar kernel: drivers/scsi/mvsas/mv_sas.c 2083:port 4 ctrl sts=0x199800. (System) Mar 18 22:15:01 DarkStar kernel: drivers/scsi/mvsas/mv_sas.c 2085:Port 4 irq sts = 0x1001081 (System) Mar 18 22:15:01 DarkStar kernel: drivers/scsi/mvsas/mv_sas.c 2083:port 4 ctrl sts=0x199800. (System) Mar 18 22:15:01 DarkStar kernel: drivers/scsi/mvsas/mv_sas.c 2085:Port 4 irq sts = 0x10000 (System) Mar 18 22:15:01 DarkStar kernel: drivers/scsi/mvsas/mv_sas.c 2138:notify plug in on phy[4] (System) Mar 18 22:15:01 DarkStar kernel: drivers/scsi/mvsas/mv_sas.c 1224:port 4 attach dev info is 60400 (System) Mar 18 22:15:01 DarkStar kernel: drivers/scsi/mvsas/mv_sas.c 1226:port 4 attach sas addr is 4 (System) Mar 18 22:15:01 DarkStar kernel: drivers/scsi/mvsas/mv_sas.c 378:phy 4 byte dmaded. (System) Mar 18 22:15:01 DarkStar kernel: sas: sas_form_port: phy4 belongs to port4 already(1)! (Drive related) Mar 18 22:15:03 DarkStar kernel: drivers/scsi/mvsas/mv_sas.c 1586:mvs_I_T_nexus_reset for device[4]:rc= 0 (System) Mar 18 22:15:03 DarkStar kernel: sas: I_T 0400000000000000 recovered (Drive related) Mar 18 22:15:03 DarkStar kernel: sas: sas_ata_task_done: SAS error 8d (Errors) Mar 18 22:15:03 DarkStar kernel: ata13: translated ATA stat/err 0x01/04 to SCSI SK/ASC/ASCQ 0xb/00/00 (Drive related) Mar 18 22:15:03 DarkStar kernel: ata13: status=0x01 { Error } (Errors) Mar 18 22:15:03 DarkStar kernel: ata13: error=0x04 { DriveStatusError } (Errors) Mar 18 22:15:03 DarkStar kernel: sas: --- Exit sas_scsi_recover_host (Drive related) As a side note non of the recovery options for reiserfs appear to work on drive one, every attempt ends in "aborted".
  3. After looking a little further, I wonder if some of those write speeds being reported are processor capped. Using iStat to monitor CPU usage on my server AFP no Cache, SMB no Cache and SMB Cache all use around 8% of the CPU to Copy a file over. AFP Cache uses around 18%. Considering streaming a movie off the server doesn't even consume 1% (showing as 99-100% idle). I wonder if it's the Atom / Celeron servers reporting < 40MB/s.
  4. I am really liking the speed of AFP, however it seems to be somewhat unreliable. It works fine if you connect then copy files right away, but it seems to "time out" after a while, even if it is in the middle of a transfer. I haven't been able to pin it down but it seems to be around 4 hours or so. I have resorted to SMB for everything but Time Machine, however I will switch back to AFP so I can get you a syslog. Joe, not that I'm complaining but I'm trying to figure out why my speeds are so far out of the normal. Setup: i3 iMac (10.6.6) -> 20 foot Ethernet -> Netgear Gigabit Switch -> 10 foot ethernet -> UnRaid 5b4 (i3 on Gigabyte H57M-USB3) Cache Samsung HD502HJ (7200rpm) all other drives Samsung HD154UI (5400rpm) 3 MKV files (10.81GB total) Here are the speeds I am getting: SMB No Cache SMB Cache AFP No Cache AFP Cache *All Data Disks and Parity are Samsung HD154UI (5400 rpm)
  5. Few notes here. AFP speed is amazing!!! I am getting writes to the cache drive of 85 mb/s (96 is the peak so far). I have noticed a few issues with allowing disks to be exported. If I allow all disks to be exported in AFP but not in SMB, I can not log into the server using afp. If I only allow 1 disk afp and not smb it's ok. If I do none afp and all smb it's ok. Does anyone have any info regarding the Temporary Items and Network Trash Folder shares? Why are they there, how do I get rid of them. It's not a major issue, but they are throwing folders nested into other folders and they all appear to be empty. I was assuming they had to do with hidden files mac's write, but none are in any of the folders. I was able to crash the server somehow. I do have add ons running so that isn't much help, and as soon as I get more info I'll post it. Copying a sparse bundle over AFP. Went to go get dinner, server became unresponsive, shares vanished, afp stopped broadcasting to bonjour (SMB showed but was unresponsive). Unable to ssh or wake the display connected to the server. Had to hard shutdown. I didn't have the log window open, but I will report back if it occurs again. Great work, I just need to figure out how to turn off the SMB broadcasting and find a solution to the Temp / Trash shares now.
  6. The issue doesn't occur in normal unRaid use, it could only show up if you were running add ons on the server (like unmenu) and only if the drives were connected using ahci.
  7. My tests were only 30 min long so they should have been in the faster area of the drive. All of my drives for the test were the same size and brand (Samsung 154UI's as well as empty although that should not have affected anything) so that also eliminated the possibility of one of the drives skewing the numbers. I'd run the drive test in unmenu just to make sure one of your drives isn't much slower, next time I do a full parity I'll let you know the end results.
  8. Their quality has come a long way between models (4224 is very nice) however they are still not up there with some of the higher-end companies (supermicro, chenbro, etc...). They are however 1/3 the price. If you need the space and are on a budget I would recommend the 4224.
  9. That or just turn off ahci. Since the issue does not occur when the drives are set to an IDE mode.
  10. I also think the f3's are one of the better drives. Seagate has scared me away since that 1.5 fiasco, as soon as Samsung burns me I'm sure I'll forgive Seagate. I had 2 drives in my Raid 5 array fail within hours, then my external drive with the only backup of a few files failed as I was copying the data back. All of them were 1.5 Seagates. Needless to say I was unhappy, but they sent me replacements...
  11. After reading the forum posts about Samsung and their temperatures I decided I had to get to the bottom of it. Since I have 24 Samsung drives ranging from f2's all the way to f4's I need to know if the temp reading can't be trusted. I searched the internet and could not find anything stating that all Samsung Drives report an incorrect temperature anywhere. - Do not use the temperature reading on your AC's thermostat that is 3 rooms away to gauge ambient temperature. Since no one was reporting how they were getting their temperature readings I went shopping. http://www.amazon.com/gp/product/B000MX5Y9C?ie=UTF8&tag=wwwgalttechco-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=B000MX5Y9C I also had a digital thermometer with a probe on hand just for another set of data. Temperature at the thermostat was 25.5c (down the hall) Temperature in the room was 27.2c (sitting on my desk) Temperature outside the server was 25.1c (12 inches from the server) Temperature inside the server was 24.7c (reading was from behind the backplanes on a SC933) I use a mixture of Samsung drives HD502HJ, HD154UI, HD203WI and HD204UI. When I first woke the array up, all drives reported temperatures of 19c-22c. This includes a Seagate 9BJ13G 7200rpm I had in for pre-clearing. I let the array "warm up" while I went and got a beer and heated up a snack downstairs, then refreshed the page. One of the HD154UI's was reporting a temperature of 24c, the rest ranged from 25c up to 30c. All drives of the same model were within 1 degree of each other. Since nothing looked out of the ordinary, and I wanted to spend more time with my new $80 toy I decided to gather more info. I am sure there is a better way to do this but this is what I did. I took a Screenshot of the array then stopped it. I then pulled one of each of the 4 types of drives and used the Infrared thermometer on the bottoms of them since the bottom temperature reading was higher. I took readings from each of the 4 drives in the same spot right next to the spindle. Each reading was within 2c of the temperature listed in unRaid. The 154UI and 204UI were colder then unRaid reported, while the 502HJ and the 203WI were warmer. I'm not really sure what controls were used by the people reporting this issue, but based on my results I do not see anything here that says Samsung's have false temperature readings. Either people didn't get an accurate ambient reading, or they had a faulty drive.
  12. The Hitachi looks like it was 25% full which will skew the results away from it since the fastest part of the disk is full. You are using Windows 7 (possibly vista, but I don't like to believe that OS still exists) which supports the advanced format, where unraid does not, so it wont properly show the advantages / disadvantages. Also you seem to have only tested the read speeds, which is not the issue with these drives. Re run the bottom tests again but select "Write" and you should get different results. The drives work fine, they write slower then the other 2 TB choices. They also use less power and tend to run cooler. If you have them, they will work fine.
  13. They are as safe as any HD can be. The main reason they are not recommended is due to their below average write speeds using unRaid. Their read speeds are generally not the issue. In my experience, if you use another 2 TB as your parity (I use an f3) and a good cache drive (I use a 502hj) you will not even be able to tell a difference between an ears and a f4.
  14. It's still in "beta" like all software is, but I've done just over 1200 and have yet to have a sync issue using it. It does however fail on some badly mastered Blu-Rays (the ones that were done first using aacs v1) however they are fixing that in the next release.
  15. I use makemkv to convert the disk / folders into an mkv. It's free (for now at least) and will let you take all the tracks you want (dts, hd audio, etc...) and put them into a single mkv. Do a few that way and see what you think of the file size. The quality will be the same as the original since all you did was wrap it into a single file. After that, use handbrake. It's free and will encode the movies in any way you'd like. There are literally hundreds of different options to configure. If you want the settings I use, I'll forward them to you but they take a while to encode (I use 2 passes to clean up any artifacts). After that's done I remux the new encoded video file with the original audio files...
  16. He was directing the "Recoding to a lower quality..." to me unraided, just changing the container to a MKV doesn't encode anything. @neilt0: To encode or not is a different question altogether. You have to choose from Speed/Quality/Size. You can only have 2. When I encode them they cost less, around 26 cents. While 1:1 rips are limited to around 1600 (assuming they have their own 40 TB server) encoding them leaves you with a ~5000 limit. With all the processors between your HTPC / Receiver / Projector, it is very difficult to even tell the difference between a 1:1 rip and a well encoded 1080P H.264 MKV. Even on a 120" screen (assuming the rest of your gear is decent). The main difference is the amount of time it takes up. Sound seems to make the larger difference anyways, you don't want to touch the audio files. Let your $5000 audio system earn it's keep.
  17. makemkv is what I use. It's takes about 30 min from disk to mkv and it deals with encryption as well. if you already have the decrypted Bluray folder's it does it in about 5-10 min a file. Works on both Window's and Mac, and is currently free in beta (which it has been for at least a year). Just turning your folder's into MKV's does not result in loss of quality, but it allows you to save space by eliminating all the extra stuff you don't want (bonus features, foreign audio tracks, subtitles...). They tend to average between 15-30 GB each. Myself (and it sounds like Brit does as well), I add a step after that and encode the movie using Handbrake. It allows me to trim the black bars off as well as tweak some other settings like interlace. It takes a considerable amount of time (my i7 takes about 4 hours for 2 passes) but allows me to shrink the files down to around 8 GB with very little loss in video quality.
  18. I do what Brit does. Takes more time, but with the right settings it's 90%+ of the video quality and 100% of the audio in about 1/4 the space. When you start looking at 1000+ HD movies, it makes a difference. If you don't want to lose any quality and dont care about all the extras (deleted scenes, making of...) go mkv for the container. More players will play it over m2ts files, and I'll be smaller then the full iso without losing any quality (because you are just changing the file type, not the size).
  19. I'm running quite a few add on's, which ones are considered "CPU Intensive"? I personally think it's the best choice for someone building a new system, but nothing I have thrown at it seems to take it over 15% usage.
  20. Final test. -i3 Motherboard- 163 watt parity 115 watt idle 97 MB/s Parity (over 30 min) (processor usage was at ~5%) End result, i3 530 is overkill for unRaid?
  21. I had the same issue with a samsung f2 and f3 using the card. Preclear using the board worked fine.
  22. Whew! Now that's all done, I'll tell you what I'm thinking. LV processors seem to be the way to go. - Machine runs much cooler (wasn't watching temps too much but I had 58c Stock and 44c LV running parity) - Uses less power (~25 watts less per processor) - No noticeable speed difference (1MB vs 2MB cache) Hyper-threading seems to only really matter for single processors. - unRaid Parity seems to be the most intensive task. - 2 processors are right at the bottleneck (at least in my system) - It doesn't really consume more power. (since the processor doesn't have to work as hard) I guess the question now is, Single or Dual? I'm leaning towards Single LV Processor Hyper-threaded. Cost less, uses less energy, performance is within 10% of Dual processor. Anyone else's thoughts?
  23. These numbers will be a little harder to compare as I haven't had 2 processors in here for a while, and I never ran the dual stock processors Hyperthreaded. -Dual LV Processor- (Hyperthreaded) 265 watt parity 175 watt idle 95 MB/s Parity (over 30 min) (processor usage was only at ~25%) -Dual LV Processor- 269 watt parity 175 watt idle 98 MB/s Parity (over 30 min) (processor usage was at ~50%) The bottleneck on my system seems to be either the drives or the PCI-X bus. I had these same drives on a 4x PCI-E card and was only able to achieve 98 MB/s, which leaves me to believe it could be the drives. *Interesting how Hyperthreading uses less power, maybe because it's not working as hard? *Hyperthreading on vs. off doesn't seem to affect idle, always good to know.