Windows hangs up while displaying an iSCSI drive

[jfdev]

I've configured an iSCSI drive via FreeNAS and connected it to my windows 10 machine.

If I click on "Devices" (German: "Geräte...") a disk "Disk -1" appears:

The partion manager hangs up while searching for virtual drives.
If I want to see details at the device manager it hangs up too:

The drive is not shown in Windows explorer although I've created already a partion and used it for months.


Is there any way of recovering the iSCSI as a SMB or NFS or do you have any tips / instructions to repair my iSCSI setup?

The FreeNAS instance is running at an ESXi enviroment with 10GiB of ECC RAM.

 

[jgreco]

It's a block device. What happens if you copy the entire block device to an external USB drive, and then try to get Windows to open that?

If the copy to a USB disk works, then this isn't really a FreeNAS issue and is something Windows-related, and you can feel safe working on a USB copy of the drive with conventional Windows "fix-it" tools.

If the copy to a USB disk fails, then that's probably something we can look at.

 

[jfdev]

It's a block device. What happens if you copy the entire block device to an external USB drive, and then try to get Windows to open that?

If the copy to a USB disk works, then this isn't really a FreeNAS issue and is something Windows-related, and you can feel safe working on a USB copy of the drive with conventional Windows "fix-it" tools.

If the copy to a USB disk fails, then that's probably something we can look at.

Thank you for your quick response.

How could I copy "the entire block device". I've just found /dev/zvol/default_vol/windows (which is the name of my iscsi)
When I try to copy "windows" to another volume (instead of a USB stick), FreeNAS kind of hangs up and only interacts to CTRL+T and the web interface is not responsing.

Command:

cp /dev/zvol/default_vol/windows windows_backup_vol


Output of CTRL + T while cp'ing:

Code:

load: 0.40  cmd: cp 7698 [dp->dp_spaceavail_cv] 286.67r 0.00u 2.67s 0% 3084k

 

[jgreco]

What's the output of "zpool list"?

 

[jfdev]

What's the output of "zpool list"?

Code:

NAME		   SIZE  ALLOC   FREE  EXPANDSZ   FRAG	CAP  DEDUP  HEALTH  ALTROOT
default_vol   1.54T   808G   768G		 -	21%	51%  1.00x  ONLINE  /mnt
freenas-boot  15.9G  2.26G  13.6G		 -	  -	14%  1.00x  ONLINE  -

 

[jgreco]

Huh. I was wondering if your pool was full, because that could have mysterious symptoms like this.

To copy the iSCSI to something else like a USB device, you'd have to identify it when it plugs in as to what it shows up as.

% camcontrol devlist

both before and after should make that easy. It'll show up as a new "da" device. It may or may not have an obvious name.

Then, being so very careful that you have double- and triple-checked the "da" device number as being correct, you can copy the iSCSI to that device with

% dd if=/dev/zvol/default_vol/windows of=/dev/daXX bs=65536

where XX is the device number of the USB disk. Think this should work. I haven't actually tried it.

Expect it to overwrite the target UDB drive, obviously.

It's possible this won't work for one of several reasons, but that's the first thing I'd try. "dd" will respond to control-T with stats about the copy, which might not be super-fast.

 

[jfdev]

Huh. I was wondering if your pool was full, because that could have mysterious symptoms like this.

To copy the iSCSI to something else like a USB device, you'd have to identify it when it plugs in as to what it shows up as.

% camcontrol devlist

both before and after should make that easy. It'll show up as a new "da" device. It may or may not have an obvious name.

Then, being so very careful that you have double- and triple-checked the "da" device number as being correct, you can copy the iSCSI to that device with

% dd if=/dev/zvol/default_vol/windows of=/dev/daXX bs=65536

where XX is the device number of the USB disk. Think this should work. I haven't actually tried it. :)

Expect it to overwrite the target UDB drive, obviously.

It's possible this won't work for one of several reasons, but that's the first thing I'd try. "dd" will respond to control-T with stats about the copy, which might not be super-fast.

I've decided to create a ISO in share instead because I don't have a USB Drive with an appropriate capacity. FreeNAS "hangs up" during the copying process because I cannot connect via SSH again and Ctrl+T only returning the default informations without write speed etc.
/mnt/default_vol/jonas-win/iscsi is currently deactivated SMB share on the FreeNAS instance.
root@nas:/mnt/default_vol/jonas-win/iscsi # dd if=/dev/zvol/default_vol/windows of=/mnt/default_vol/jonas-win/iscsi/disk.iso bs=65536

Code:

load: 0.47  cmd: dd 8163 [running] 1.16r 0.00u 1.07s 8% 2212k
3189+0 records in
3189+0 records out
208994304 bytes transferred in 1.164564 secs (179461433 bytes/sec)
load: 0.67  cmd: dd 8163 [dp->dp_spaceavail_cv] 6.09r 0.01u 5.62s 38% 2216k
load: 0.62  cmd: dd 8163 [dp->dp_spaceavail_cv] 9.15r 0.01u 5.62s 26% 2216k
load: 0.62  cmd: dd 8163 [dp->dp_spaceavail_cv] 9.71r 0.01u 5.62s 26% 2216k
load: 0.62  cmd: dd 8163 [dp->dp_spaceavail_cv] 10.16r 0.01u 5.62s 25% 2216k
load: 0.62  cmd: dd 8163 [dp->dp_spaceavail_cv] 10.59r 0.01u 5.62s 25% 2216k
load: 0.62  cmd: dd 8163 [dp->dp_spaceavail_cv] 11.03r 0.01u 5.62s 25% 2216k
load: 0.62  cmd: dd 8163 [dp->dp_spaceavail_cv] 11.48r 0.01u 5.62s 21% 2216k
load: 0.48  cmd: dd 8163 [dp->dp_spaceavail_cv] 25.86r 0.01u 5.62s 0% 2216k
load: 0.48  cmd: dd 8163 [dp->dp_spaceavail_cv] 27.36r 0.01u 5.62s 0% 2216k
load: 0.48  cmd: dd 8163 [dp->dp_spaceavail_cv] 27.84r 0.01u 5.62s 0% 2216k
load: 0.48  cmd: dd 8163 [dp->dp_spaceavail_cv] 28.21r 0.01u 5.62s 0% 2216k
load: 0.52  cmd: dd 8163 [dp->dp_spaceavail_cv] 28.56r 0.01u 5.62s 0% 2216k
load: 0.30  cmd: dd 8163 [dp->dp_spaceavail_cv] 79.81r 0.01u 5.62s 0% 2216k
load: 0.30  cmd: dd 8163 [dp->dp_spaceavail_cv] 80.28r 0.01u 5.62s 0% 2216k
load: 0.30  cmd: dd 8163 [dp->dp_spaceavail_cv] 80.70r 0.01u 5.62s 0% 2216k
load: 0.30  cmd: dd 8163 [dp->dp_spaceavail_cv] 81.14r 0.01u 5.62s 0% 2216k
load: 0.17  cmd: dd 8163 [dp->dp_spaceavail_cv] 665.41r 0.01u 5.62s 0% 2216k
load: 0.16  cmd: dd 8163 [dp->dp_spaceavail_cv] 667.93r 0.01u 5.62s 0% 2216k
load: 0.16  cmd: dd 8163 [dp->dp_spaceavail_cv] 668.64r 0.01u 5.62s 0% 2216k
load: 0.16  cmd: dd 8163 [dp->dp_spaceavail_cv] 669.06r 0.01u 5.62s 0% 2216k
load: 0.16  cmd: dd 8163 [dp->dp_spaceavail_cv] 669.77r 0.01u 5.62s 0% 2216k
load: 0.16  cmd: dd 8163 [dp->dp_spaceavail_cv] 670.15r 0.01u 5.62s 0% 2216k
load: 0.16  cmd: dd 8163 [dp->dp_spaceavail_cv] 670.47r 0.01u 5.62s 0% 2216k
load: 0.14  cmd: dd 8163 [dp->dp_spaceavail_cv] 670.75r 0.01u 5.62s 0% 2216k
load: 0.14  cmd: dd 8163 [dp->dp_spaceavail_cv] 671.06r 0.01u 5.62s 0% 2216k
load: 0.14  cmd: dd 8163 [dp->dp_spaceavail_cv] 671.32r 0.01u 5.62s 0% 2216k
load: 0.14  cmd: dd 8163 [dp->dp_spaceavail_cv] 671.65r 0.01u 5.62s 0% 2216k

 

[jgreco]

Well if there's some sort of problem with the pool, you're not doing yourself any favors with that. I don't have a test jig available at the moment to refresh my memory on the specifics of this sort of setup so all I can really say is that I think something is out of space.