planetscott

Looks like that did the trick. I backed up the old MBR (just in case) and cleared it with dd. Re-started the array and the drive now shows up as a new parity drive and it's started the parity sync. The UI now says that it's 4k aligned, but just to make sure, I dumped out the partition table entry and it looks right: root@nas:/mnt/tmp/tmp# hexdump -C -n 16 -s 446 parity_new_mbr.bin 000001be 00 00 00 00 83 00 00 00 40 00 00 00 70 88 e0 e8 |[email protected]...| 000001ce It shows the partition now starting at 0x40 (64), where if I look at the old partition table it was starting at 0x3F (63). Thanks for the help. Once this finishes I'll see if my write performance improves.

Yup, it's showing up as unaligned. I guess the first thing for me to do is reformat my parity drive to properly align it. Since 5.0 supports AF disks, should I just be able to wipe the partition table on the parity drive using dd and then try to start the array? Ideally unRAID would see the disk as "unformatted" and then re-format it and rebuild parity?

I wonder if there is a way I can verify that? Assuming that's the case, would it make sense to rebuild parity with a newly formatted drive?

I should have mentioned that I was testing on the console using dd. Disk-to-disk and disk-to-usershare performance is similar. I'm using the VMXNET3 driver on unRAID and on another test VM to do performance tests over NFS, but I don't believe that to be a bottleneck. I'm able to get ~100MB/sec when writing the cache drive over NFS. To me it does not make sense that parity calculation should take *that* much time. When I look at top during a dd, most of the time is spent in wait. There's definitely something else going on here...

I have a mish mash of data drives - I have a WD20EARS as my parity drive and the data drive I'm writing to for my test is a WD20EARX. I upgraded the system from unRAID 4.5, and the EARX drive has the jumper set for Advanced Format drives. I did not apply the jumper to the EARS parity drive - should that matter? Writing to other drives in the array gets me similar or worse results.

Just checking into this thread. I've been building a new server with an X9SCM-F-O and I'm experiencing mediocre write speeds to my user shares. Here's my relavent hardware: X9SCM-F-O Xeon E3-1230 V2 (Ivy Bridge) KVR1333D3E9SK2/16G (2x8GB) IBM M1015 crossflashed to IT mode I have unRAID virtualized in ESXi 5.1 with the M1015 in passthrough mode. I am running 5.0rc10. When writing to the array directly, I get around 10MB/sec, which is not as high as I would expect. My read speeds are around 25MB/sec. My unRAID VM currently has 2GB of RAM allocated. I've tried bumping it up to 4GB and trying the mem=4095 kernel boot parameter and it had no effect. I also tried vm.highmem_is_dirtyable=1 and that didn't have much effect either. This evening I tried adding a cache drive (WD 500GB Caviar Blue). With the cache drive, I get much better write performance - around 100MB/sec. I'm going to see if I can do some tinkering/profiling to try to find where this performance discrepancy is.

How exactly is your ZFS configured? You're booting your guest off the one SSD (is this configured as an ESXI datastore?), then the other SSD is part of another ZFS array? What other drives are part of the ZFS array? Sorry if this is a stupid question, just trying to better understand the physical layout of your disks.

Thanks for updating with your progress. I've actually got the same configuration (unRAID with a WDTV w/ USB mod), and while I'm not currently using NFS, this information could be helpful for me in the future.

I figured I would comment on this thread since I'm running a mostly Mac network. I've built netatalk and used it with my custom unRAID install, and honestly, you're better off using Samba. I found afpd to offer no advantages to Samba, and more disadvantages if anything. The configuration is a pain. It has a bunch of unique dependencies. I found performance to be no better than Samba. AFAIK, netatalk does not include a built-in Bonjour advertising daemon, so you still have to manually configure your shares through Finder. I think the better move would be for Tom to include support for Avahi. In my configuration I find that's all I need to have great compatibility with unRAID on OSX. My shares automatically show up in Finder, and it just feels a little snappier for some reason (as opposed to manually connecting to shares).

To be honest, I havn't done any comparisons with the old kernel. Like I've said, my main reason for running SMP is to fully take advantage of virtualization. Are you running into I/O bottlenecks now?

Turns out it's a problem with my use of the 2.6.26 kernel. I guess it's not ready for primetime yet! I compiled 2.6.24.4 (SMP) and I'm no longer having any problems.

The panic DOES occur when I use the web interface to stop/start the array. If I stop the array, then reboot, or power down it comes back up normally on reboot (parity is valid). I am running SMP, yes. In one of the other threads I described how I patched unraid.c to get rid of the panic on array shutdown by adding an additional lock (I've never seen a panic at startup). I've been running an SMP kernel for the past month with my flash-based install with no issues. Perhaps I'll try building a non-SMP kernel to see if I get the same behavior. One thing that's strange is that I just shut down the array, but it looks like /mnt/user has not unmounted cleanly. root@monster:/mnt# ls -l /bin/ls: cannot access user: No such file or directory total 36 -rw-r--r-- 1 root root 376 2006-09-25 23:09 README drwxr-xr-x 2 root root 4096 2006-09-25 21:02 cdrecorder/ drwxr-xr-x 2 root root 4096 2002-03-16 02:34 cdrom/ drwxr-xr-x 2 root root 4096 2006-09-25 21:02 dvd/ drwxr-xr-x 2 root root 4096 2002-03-16 02:34 floppy/ drwxr-xr-x 2 root root 4096 2002-03-16 02:34 hd/ drwxr-xr-x 2 root root 4096 2006-09-25 21:02 memory/ drwxr-xr-x 2 root root 4096 2006-09-25 21:03 tmp/ d??? ? ? ? ? ? user/ drwxr-xr-x 2 root root 4096 2006-09-25 21:02 zip/ root@monster:/mnt# Hmm ...

I'm running into a strange kernel panic when I restart the array (after stopping it). I get this every time: Sep 7 10:31:18 monster kernel: kobject_add_internal failed for 9:1 with -EEXIST, don't try to register things with the same name in the same directory. Sep 7 10:31:18 monster kernel: Pid: 1516, comm: emhttp Not tainted 2.6.26.3-unRAID #3 Sep 7 10:31:18 monster kernel: [<c020ec01>] kobject_add_internal+0x108/0x13e Sep 7 10:31:18 monster kernel: [<c020ef12>] kobject_add+0x4a/0x4e Sep 7 10:31:18 monster kernel: [<c0266e1a>] device_add+0x62/0x42c Sep 7 10:31:18 monster kernel: [<c020e959>] kobject_init+0x32/0x53 Sep 7 10:31:18 monster kernel: [<c026726c>] device_create_vargs+0x78/0x99 Sep 7 10:31:18 monster kernel: [<c0142834>] bdi_register+0x25/0x3a Sep 7 10:31:18 monster kernel: [<c0142863>] bdi_register_dev+0x1a/0x1e Sep 7 10:31:18 monster kernel: [<c020926a>] add_disk+0x4f/0x69 Sep 7 10:31:18 monster kernel: [<c02085dc>] exact_match+0x0/0x7 Sep 7 10:31:18 monster kernel: [<c0208fe1>] exact_lock+0x0/0xd Sep 7 10:31:18 monster kernel: [<f886af72>] start_array+0x581/0x5be [md_mod] Sep 7 10:31:18 monster kernel: [<f886c08e>] md_cmd_proc_write+0x894/0xa1f [md_mod] Sep 7 10:31:18 monster kernel: [<c0178cb0>] inotify_d_instantiate+0xf/0x30 Sep 7 10:31:18 monster kernel: [<c0163f69>] d_rehash+0x1c/0x27 Sep 7 10:31:18 monster kernel: [<c017f568>] proc_root_lookup+0xe/0x26 Sep 7 10:31:18 monster kernel: [<c01642a5>] dput+0x15/0xb9 Sep 7 10:31:18 monster kernel: [<c015e444>] __link_path_walk+0x9be/0xace Sep 7 10:31:18 monster kernel: [<c0113a51>] __wake_up_common+0x34/0x58 Sep 7 10:31:18 monster kernel: [<c01147ac>] __wake_up+0x29/0x39 Sep 7 10:31:18 monster kernel: [<c0168430>] mntput_no_expire+0x18/0xd7 Sep 7 10:31:18 monster kernel: [<c015e5bb>] path_walk+0x67/0x70 Sep 7 10:31:18 monster kernel: [<c015e7fe>] do_path_lookup+0x11e/0x139 Sep 7 10:31:18 monster kernel: [<c017efab>] pde_users_dec+0xb/0x27 Sep 7 10:31:18 monster kernel: [<c017f43d>] proc_reg_open+0x41/0x48 Sep 7 10:31:18 monster kernel: [<c017f3fc>] proc_reg_open+0x0/0x48 Sep 7 10:31:18 monster kernel: [<c015592a>] __dentry_open+0x11d/0x1e6 Sep 7 10:31:18 monster kernel: [<c0155a0f>] nameidata_to_filp+0x1c/0x2c Sep 7 10:31:18 monster kernel: [<c015f6ba>] do_filp_open+0x31c/0x64a Sep 7 10:31:18 monster kernel: [<c01460c4>] handle_mm_fault+0x693/0x71d Sep 7 10:31:18 monster kernel: [<f886b7fa>] md_cmd_proc_write+0x0/0xa1f [md_mod] Sep 7 10:31:18 monster kernel: [<c01826b1>] proc_file_write+0x25/0x2e Sep 7 10:31:18 monster kernel: [<c018268c>] proc_file_write+0x0/0x2e Sep 7 10:31:18 monster kernel: [<c017f2ac>] proc_reg_write+0x56/0x69 Sep 7 10:31:18 monster kernel: [<c017f256>] proc_reg_write+0x0/0x69 Sep 7 10:31:18 monster kernel: [<c01571a7>] vfs_write+0x83/0xf6 Sep 7 10:31:18 monster kernel: [<c01576b1>] sys_write+0x3c/0x63 Sep 7 10:31:18 monster kernel: [<c0102b7a>] syscall_call+0x7/0xb Sep 7 10:31:18 monster kernel: ======================= Sep 7 10:31:18 monster kernel: BUG: unable to handle kernel NULL pointer dereference at 00000094 Sep 7 10:31:18 monster kernel: IP: [<c0187e74>] sysfs_create_link+0x36/0xda Sep 7 10:31:18 monster kernel: *pdpt = 000000003742d001 *pde = 0000000000000000 Sep 7 10:31:18 monster kernel: Oops: 0000 [#1] SMP Sep 7 10:31:18 monster kernel: Modules linked in: md_mod fuse e1000 sata_sil24 ahci libata i2c_i801 dock Sep 7 10:31:18 monster kernel: Sep 7 10:31:18 monster kernel: Pid: 1516, comm: emhttp Not tainted (2.6.26.3-unRAID #3) Sep 7 10:31:18 monster kernel: EIP: 0060:[<c0187e74>] EFLAGS: 00210246 CPU: 1 Sep 7 10:31:18 monster kernel: EIP is at sysfs_create_link+0x36/0xda Sep 7 10:31:18 monster kernel: EAX: c048f09c EBX: 00000078 ECX: c03a091e EDX: 0000bebe Sep 7 10:31:18 monster kernel: ESI: c03a091e EDI: fffffff2 EBP: f76f58d0 ESP: f64f3d7c Sep 7 10:31:18 monster kernel: DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Sep 7 10:31:18 monster kernel: Process emhttp (pid: 1516, ti=f64f2000 task=f7c56520 task.ti=f64f2000) Sep 7 10:31:18 monster kernel: Stack: 00000009 00000001 c020926a c02085dc f64d1200 00000001 f64d6000 00000001 Sep 7 10:31:18 monster kernel: f886af72 f64d120c f8870c46 00000001 f64d6080 f64f3df6 f64f3df6 b6465300 Sep 7 10:31:18 monster kernel: f74aee00 f886c08e c0178cb0 f79ee9b0 f78aab00 f78aab00 c0163f69 0000000d Sep 7 10:31:18 monster kernel: Call Trace: Sep 7 10:31:18 monster kernel: [<c020926a>] add_disk+0x4f/0x69 Sep 7 10:31:18 monster kernel: [<c02085dc>] exact_match+0x0/0x7 Sep 7 10:31:18 monster kernel: [<f886af72>] start_array+0x581/0x5be [md_mod] Sep 7 10:31:18 monster kernel: [<f886c08e>] md_cmd_proc_write+0x894/0xa1f [md_mod] Sep 7 10:31:18 monster kernel: [<c0178cb0>] inotify_d_instantiate+0xf/0x30 Sep 7 10:31:18 monster kernel: [<c0163f69>] d_rehash+0x1c/0x27 Sep 7 10:31:18 monster kernel: [<c017f568>] proc_root_lookup+0xe/0x26 Sep 7 10:31:18 monster kernel: [<c01642a5>] dput+0x15/0xb9 Sep 7 10:31:18 monster kernel: [<c015e444>] __link_path_walk+0x9be/0xace Sep 7 10:31:18 monster kernel: [<c0113a51>] __wake_up_common+0x34/0x58 Sep 7 10:31:18 monster kernel: [<c01147ac>] __wake_up+0x29/0x39 Sep 7 10:31:18 monster kernel: [<c0168430>] mntput_no_expire+0x18/0xd7 Sep 7 10:31:18 monster kernel: [<c015e5bb>] path_walk+0x67/0x70 Sep 7 10:31:18 monster kernel: [<c015e7fe>] do_path_lookup+0x11e/0x139 Sep 7 10:31:18 monster kernel: [<c017efab>] pde_users_dec+0xb/0x27 Sep 7 10:31:18 monster kernel: [<c017f43d>] proc_reg_open+0x41/0x48 Sep 7 10:31:18 monster kernel: [<c017f3fc>] proc_reg_open+0x0/0x48 Sep 7 10:31:18 monster kernel: [<c015592a>] __dentry_open+0x11d/0x1e6 Sep 7 10:31:18 monster kernel: [<c0155a0f>] nameidata_to_filp+0x1c/0x2c Sep 7 10:31:18 monster kernel: [<c015f6ba>] do_filp_open+0x31c/0x64a Sep 7 10:31:18 monster kernel: [<c01460c4>] handle_mm_fault+0x693/0x71d Sep 7 10:31:18 monster kernel: [<f886b7fa>] md_cmd_proc_write+0x0/0xa1f [md_mod] Sep 7 10:31:18 monster kernel: [<c01826b1>] proc_file_write+0x25/0x2e Sep 7 10:31:18 monster kernel: [<c018268c>] proc_file_write+0x0/0x2e Sep 7 10:31:18 monster kernel: [<c017f2ac>] proc_reg_write+0x56/0x69 Sep 7 10:31:18 monster kernel: [<c017f256>] proc_reg_write+0x0/0x69 Sep 7 10:31:18 monster kernel: [<c01571a7>] vfs_write+0x83/0xf6 Sep 7 10:31:18 monster kernel: [<c01576b1>] sys_write+0x3c/0x63 Sep 7 10:31:18 monster kernel: [<c0102b7a>] syscall_call+0x7/0xb Sep 7 10:31:18 monster kernel: ======================= Sep 7 10:31:18 monster kernel: Code: 85 c9 75 04 0f 0b eb fe 85 c0 bd 84 6a 40 c0 74 10 8b 68 1c bf f2 ff ff ff 85 ed 0f 84 a4 00 00 00 b8 9c f0 48 c0 e8 b2 fb 1a 00 <8b> 5b 1c 85 db 74 17 83 3b 00 75 0f ba 81 00 00 00 b8 a1 36 3a Sep 7 10:31:18 monster kernel: EIP: [<c0187e74>] sysfs_create_link+0x36/0xda SS:ESP 0068:f64f3d7c Sep 7 10:31:18 monster kernel: ---[ end trace e065292131e2d8a2 ]--- It's very strange. I was running into this repeatedly yesterday. What I found is that if I restored my array (and rebuilt parity), this panic no longer occurred when I restarted the array. However, as soon as I shut down unRAID using WeeboTech's powerdown script, the error returned. To me it doesn't look like a kernel configuration error. I was running the 2.6.26 kernel on my flash previously, so I don't think that's to blame. My suspicion is that there's something that the emhttp shutdown is doing that the powerdown script is not. Has anyone else seen this behavior? I mean, I can get around it by rebooting every time I change the array, but I'd rather fix the root problem.

This is great bubbaQ, I think I may have to try this over the weekend!

Just to confirm, after making that fix I no longer get the kernel error on shutdown. Here's a diff of my change: root@slackware:/usr/src/linux/drivers/md# diff -up /root/initrd-unraid-4.3.3/usr/src/linux/drivers/md/unraid.c ./unraid.c --- /root/initrd-unraid-4.3.3/usr/src/linux/drivers/md/unraid.c 2008-07-15 18:16:09.000000000 -0400 +++ ./unraid.c 2008-08-03 21:16:19.000000000 -0400 @@ -1388,6 +1388,7 @@ static void shrink_stripes(unraid_conf_t { struct stripe_head *sh; + spin_lock_irq(&conf->device_lock); while ((sh = get_free_stripe(conf)) != NULL) { if (atomic_read(&sh->count)) MD_BUG(); @@ -1395,6 +1396,8 @@ static void shrink_stripes(unraid_conf_t kmem_cache_free(conf->slab_cache, sh); atomic_dec(&conf->active_stripes); } + spin_unlock_irq(&conf->device_lock); + if (conf->slab_cache) { kmem_cache_destroy(conf->slab_cache); conf->slab_cache = NULL; root@slackware:/usr/src/linux/drivers/md# Hope this helps.