So now that I have my new unRAID 4.7 server up and running I still have several drives left over from my WHSv1 server that contain data I need to transfer to unRAID.  I have tried mounting one of those NTFS drives within the server itself using both the unMenu Disk Management approach, and using mount from a console.  In either case when I start copying the files using rsync within a console the system errors out showing the syslog snippet below.  My full syslog is also attached.  If I take that same drive and install it on a Windows 7 box I can copy the files to my unRAID server over the network with no issues.  Any suggestions as to what might be causing this?  The NTFS drive is attached to one of my two SASLP-MV8 controllers.

 

Oct  5 05:53:01 media-server kernel: ------------[ cut here ]------------

Oct  5 05:53:01 media-server kernel: WARNING: at drivers/ata/libata-core.c:5186 ata_qc_issue+0x10b/0x308()

Oct  5 05:53:01 media-server kernel: Hardware name: TH67B

Oct  5 05:53:01 media-server kernel: Modules linked in: ntfs md_mod xor ahci r8169 mvsas libsas scst scsi_transport_sas

Oct  5 05:53:01 media-server kernel: Pid: 5108, comm: smartctl Tainted: G        W  2.6.32.9-unRAID #8

Oct  5 05:53:01 media-server kernel: Call Trace:

Oct  5 05:53:01 media-server kernel:  [<c102449e>] warn_slowpath_common+0x60/0x77

Oct  5 05:53:01 media-server kernel:  [<c10244c2>] warn_slowpath_null+0xd/0x10

Oct  5 05:53:01 media-server kernel:  [<c11b624d>] ata_qc_issue+0x10b/0x308

Oct  5 05:53:01 media-server kernel:  [<c11ac0ba>] ? scsi_init_sgtable+0x5b/0x76

Oct  5 05:53:01 media-server kernel:  [<c11ba260>] ata_scsi_translate+0xd1/0xff

Oct  5 05:53:01 media-server kernel:  [<c11a816c>] ? scsi_done+0x0/0xd

Oct  5 05:53:01 media-server kernel:  [<c11a816c>] ? scsi_done+0x0/0xd

Oct  5 05:53:01 media-server kernel:  [<c11baa40>] ata_sas_queuecmd+0x120/0x1d7

Oct  5 05:53:01 media-server kernel:  [<c11bc6df>] ? ata_scsi_pass_thru+0x0/0x21d

Oct  5 05:53:01 media-server kernel:  [<f842769a>] sas_queuecommand+0x65/0x20d [libsas]

Oct  5 05:53:01 media-server kernel:  [<c11a816c>] ? scsi_done+0x0/0xd

Oct  5 05:53:01 media-server kernel:  [<c11a82c0>] scsi_dispatch_cmd+0x147/0x181

Oct  5 05:53:01 media-server kernel:  [<c11ace4d>] scsi_request_fn+0x351/0x376

Oct  5 05:53:01 media-server kernel:  [<c11269a8>] __generic_unplug_device+0x26/0x29

Oct  5 05:53:01 media-server kernel:  [<c112934a>] blk_execute_rq_nowait+0x56/0x73

Oct  5 05:53:01 media-server kernel:  [<c11293dc>] blk_execute_rq+0x75/0x91

Oct  5 05:53:01 media-server kernel:  [<c11292cc>] ? blk_end_sync_rq+0x0/0x28

Oct  5 05:53:01 media-server kernel:  [<c11295fa>] ? blk_recount_segments+0x16/0x24

Oct  5 05:53:01 media-server kernel:  [<c11250c6>] ? blk_rq_bio_prep+0x47/0x78

Oct  5 05:53:01 media-server kernel:  [<c11ac58a>] scsi_execute+0xbf/0x113

Oct  5 05:53:01 media-server kernel:  [<c11bb6d0>] ata_cmd_ioctl+0xf8/0x1ba

Oct  5 05:53:01 media-server kernel:  [<c11bb940>] ata_sas_scsi_ioctl+0x1ae/0x1e8

Oct  5 05:53:01 media-server kernel:  [<f842733d>] sas_ioctl+0x36/0x43 [libsas]

Oct  5 05:53:01 media-server kernel:  [<c11a94c8>] scsi_ioctl+0x299/0x2ad

Oct  5 05:53:01 media-server kernel:  [<f8427307>] ? sas_ioctl+0x0/0x43 [libsas]

Oct  5 05:53:01 media-server kernel:  [<c101d443>] ? enqueue_task_fair+0x96/0x9d

Oct  5 05:53:01 media-server kernel:  [<c11b326d>] sd_ioctl+0x80/0x8c

Oct  5 05:53:01 media-server kernel:  [<c112a420>] __blkdev_driver_ioctl+0x50/0x62

Oct  5 05:53:01 media-server kernel:  [<c112ad1c>] blkdev_ioctl+0x8b0/0x8dc

Oct  5 05:53:01 media-server kernel:  [<c1131e2d>] ? kobject_get+0x12/0x17

Oct  5 05:53:01 media-server kernel:  [<c112b0f8>] ? get_disk+0x4a/0x61

Oct  5 05:53:01 media-server kernel:  [<c1131e2d>] ? kobject_get+0x12/0x17

Oct  5 05:53:01 media-server kernel:  [<c1131e2d>] ? kobject_get+0x12/0x17

Oct  5 05:53:01 media-server kernel:  [<c1192208>] ? get_device+0x11/0x18

Oct  5 05:53:01 media-server kernel:  [<c11334a5>] ? radix_tree_lookup_slot+0xd/0xf

Oct  5 05:53:01 media-server kernel:  [<c104a179>] ? filemap_fault+0xb8/0x305

Oct  5 05:53:01 media-server kernel:  [<c1048c43>] ? unlock_page+0x18/0x1b

Oct  5 05:53:01 media-server kernel:  [<c1057c63>] ? __do_fault+0x3a7/0x3da

Oct  5 05:53:01 media-server kernel:  [<c10757d4>] ? do_filp_open+0x3d8/0x6d1

Oct  5 05:53:01 media-server kernel:  [<c105985f>] ? handle_mm_fault+0x42d/0x8f1

Oct  5 05:53:01 media-server kernel:  [<c108b6c6>] block_ioctl+0x2a/0x32

Oct  5 05:53:01 media-server kernel:  [<c108b69c>] ? block_ioctl+0x0/0x32

Oct  5 05:53:01 media-server kernel:  [<c10769d5>] vfs_ioctl+0x22/0x67

Oct  5 05:53:01 media-server kernel:  [<c1076f33>] do_vfs_ioctl+0x478/0x4ac

Oct  5 05:53:01 media-server kernel:  [<c106afbf>] ? fd_install+0x1e/0x43

Oct  5 05:53:01 media-server kernel:  [<c106b14e>] ? do_sys_open+0xdc/0xe7

Oct  5 05:53:01 media-server kernel:  [<c1076f93>] sys_ioctl+0x2c/0x45

Oct  5 05:53:01 media-server kernel:  [<c1002935>] syscall_call+0x7/0xb

Oct  5 05:53:01 media-server kernel: ---[ end trace 1301ecc83af4f640 ]---

syslog-2011-10-05.txt

Search for SNAP in the User Customization forum.

Search for SNAP in the User Customization forum.

 

Thanks for the lead - I can give that a shot this evening.  But having said that will it make a difference relative to how I was already mounting the NTFS drive in my system?  I just read the S.N.A.P. original topic and didn't see anything there to tell me how it might be different with respect to the error I saw.  Also once I've transferred the data from the original NTFS drive I will be doing a preclear and adding that drive to my array.

Search for SNAP in the User Customization forum.

 

Thanks for the lead - I can give that a shot this evening.  But having said that will it make a difference relative to how I was already mounting the NTFS drive in my system?  I just read the S.N.A.P. original topic and didn't see anything there to tell me how it might be different with respect to the error I saw.  Also once I've transferred the data from the original NTFS drive I will be doing a preclear and adding that drive to my array.

SNAP will not fix a failed system call.

 

Which ntfs driver are you attempting to use?  Almost looks like it timed out.  Might try loading ntfs-3g and using it.

Which ntfs driver are you attempting to use?  Almost looks like it timed out.  Might try loading ntfs-3g and using it.

 

I'm using the ntfs that's part of 4.7 at the moment, but I did try ntfs-3g yesterday and still had the problem.  However after browsing the forum some more I noticed something about 4.7 unRAID not being compatible with hot swap disks.  So I stopped and powered down my system this evening.  That took care of the hot swap factor.  But at the same time I moved the nfts drive from the SASLP controller to one of the mobo SATA ports.  I rebooted and remounted the drive through unmenu disk management.  I then went into a screen session to start copying files and voila!, it's working now.  Unfortunately I changed 2 variables at the same time, so I'll retry later by powering down and moving the drive back to the SASLP to confirm whether or not it was just the hot swap issue.  And once confirmed I'll mark this as solved.  Thanks!

First a correction to my last post - I am using the ntfs-3g driver and was using it before at the time of the error I posted at the beginning of this topic.

 

So to follow up further on my last post, I shut down the server and moved the NTFS drive back to the SASLP-MV8 controller.  I have 2 of these controllers in my system and this NTFS drive was on the "2nd" controller and was the only drive there.  I brought the server back online and mounted the NTFS drive through unmenu disk management:

 

/dev/sdi1 mounted on /mnt/disk/sdi1

Using command: mount -r -o umask=111,dmask=000 -t ntfs-3g /dev/sdi1 /mnt/disk/sdi1 2>&1

 

I then trying using rsync to copy some DVD .iso files from the NTFS drive to the unRAID disks and I got the same error as I posted above.  It then occurred to me that the NTFS drive was on the 2nd controller and that the 2nd controller had not been used before.  Maybe it's bad?

 

So I powered down and moved the NTFS drive to the last open slot on the 1st SASLP-MV8 and went through the process again.  I got the same error!

 

So it would appear that copying from the NTFS drive connected to a mobo SATA port works just fine, but using the SASLP is a problem.  I guess I can live with that, but it would be nice to know if others have seen a similar issue???

 

...

So it would appear that copying from the NTFS drive connected to a mobo SATA port works just fine, but using the SASLP is a problem.  ...

Note, in the snippet from syslog you posted above, that error is being "instigated" by a system call from within smartctl; and the trace leads to a [sAS]controller-specific (sas_ioctl) routine. [it is likely that your error from the actual copy is similar, but I can't figure where smartctl and a file-copy operation would be doing the same ioctl().]

 

Regardless, focusing back on the posted traceback, it would be interesting to know what NTFS-specific goings-on would cause something so "low-level" as smartctl to provoke that fault. That is really something that Tom, or the driver's code maintainer, should investigate.

 

Glad you were able to isolate the issue, and find a (begrudgingly) acceptable workaround.

 

-- UhClem