Giraffeninja

Members
  • Posts

    82
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

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

Giraffeninja's Achievements

Rookie

Rookie (2/14)

0

Reputation

  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.