iSCSI on Gen2 (parts 1 & 2) Hosting & Mounting Targets


Hmm… Maybe… That is more dangerous than I am willing to try at this point. I DO have some data in my MyCloud that I kinda want to keep, and so dont want to reformat the internal drive to do crazy wild testing.

What I HAVE tested, is creating a mirrored array using an iSCSI target, and a USB disk, then having it get mounted at an empty share. THAT works!


The automated umount seems to be working as planned. There is just one little snag. Once the new /dev/md* is populated by mdadm, the unit does not scan for partitions on it. I am grabbing sources for utils-linux, which contains partx. partx can be used to scan the device for partitions. I will build a static binary and add it to this package.


Static partx has been added to the package. Tested, working. Successfully detects the partitions on our md_1 device :stuck_out_tongue:

Another thing that might be neat to do, is mount the iscsi target’s container as read only on the remote location, using the loopback device. Why? So you can see the files that have been mirrored of course. Why read only? Because we aren’t stupid that’s why. :stuck_out_tongue:

The system hosting the target does not need any raid set up on it. It is a poor man’s DR site. DR Sites are supposed to be read only, except to the system that is backing up to it. Since this is raid 1 (mirror), and it contains an ext4 file system with a partition and everything, we an likely mount that partition in that image as read only, and get access to the files inside, while it is still being used as a target lun. I am sure you can think of any number of impressive uses for being able to access the files, even if it is read only.

I will test that idea out now.


so no warranty on this? too bad… oh well… guess I have to procrastinate on this, once again :stuck_out_tongue:


Look, this is very bleeding edge hackery here! :stuck_out_tongue: This is still in proof-of-concept stage!

Seat of my pants, crazy wild experimentation!

Still, I LIKE doing that kind of thing, just that some things are too rich for my blood. I am going to attempt having the image file for the iscsi lun mounted as read only on the loopback device, concurrently with having it mounted as an iscsi lun target (and subsequently, also paired in the raid group.) This is just so we can peek at the securely backed up files at the remote.

YUP. That works.

losetup -r /dev/loop1 /[path to image]
partx -u /dev/loop1
mount -o rw,noload /dev/loop1p1 /[path to mount to]

Mounts the image file for the iscsi lun as read only. Sadly, does not seem to update in realtime. Might need more mount options. (though I dont see anything that would help with this. it seems to be filesystem cache related.)


Quick question, do you see all this working in the gui(dashboard or whatever is called)? I happened​ to get a second ultra ex2 (because the fan on the first one is bad) but even though I create the targets and connect to them the gui doesn’t show anything different and it doesn’t show any different RAID settings or volumes to RAID. If I go into ssh i do see the Lun partitions as shares but nothing in the gui and that’s without any hacks! I can’t tell you how amazed i am at what you’re making this piece of software do because it doesn’t even seen to work on supported devices!


If you turn on the hacks for iscsi, the GUI works.

I may be slow to respond, as my antediluvian DSL router got smoked by a thunderstorm a few days ago, and I am waiting for the replacement to arrive from Amazon.

Still, the only part that does not seem to work from the GUI is the Fun with RAID part. Connecting to targets, and hosting targets, works just fine from the GUI.

If you mean getting the RAID manager working… Well, I need to look more carefully about what it is using to exclude candidacy for the list. More than likely, it will require an edited .js file to pick up additional drives, such as those provided via iscsi, or via USB.


Yes, this is the part that doesn’t work with two supported ex2 devices. The gui sometimes shows the targets and initiators correspondingly they are always mounted in the VV (virtual volume) directory, but they are never shown as volumes to the RAID manager so i never get to play with them. Very frustrating… Even on a supported device!


There is a file called vv.xml in the /usr/local/config folder. It contains the configuration data the virtual volume manager uses to connect with iscsi targets, including the host IP address, the IQN used to connect with, and the mountpoint to mount the target at. It may be possible to manually edit this file so that the mount point is a null value, and thus prevent the volume from being automatically mounted on connection.

I will look more into why it does not allow USB and iSCSI volumes to show up in the RAID configuration dialog. I strongly suspect that the .js the web interface calls to do the querying does some kind of exclusion that needs ‘revision’. Failing that, it is from the cgi application that gets invoked, which would be more problematical to work around. (I have not yet checked to see if the cgi binaries can be replaced with a script that makes appropriate returns. If so, then that might be the magic bullet as well.)

My homebrewed script-based mounting works though. It completely sidesteps the web interface, and does manual administration, but it works. I would rather get the web UI working just because. (I bothered getting the iscsi interface and virtual volume manager up and working, might as well try harder on the RAID config system.)

I strongly suspect that they axed USB and iSCSI devices in the RAID system on purpose, since being able to make a large array using inexpensive USB drives would detract from sales of the more expensive solutions, even though those more expensive solutions are still leaps and bounds better, and being able to put USB drives in as additional spares would be damned helpful-- not to mention the obvious utility of using iSCSI targets at a remote DR site for mirroring. It seems technologically, there is nothing really stopping that kind of function, other than purposeful roadblocks in the way the web UI is programmed.

I will attempt hacksaw surgery later. I get the next two days off. Will invest some time then.


Ok, I looked into it.

The scripts themselves are not the culprits here. It is the actual WD baked administration utility that is at fault.

The JS just checks to see if an XML file containing information about the disks is present/populated or not, then either runs with the populated list, or creates the files necessary by invoking this utility, which then outputs the needed data records. Sadly, this utility only queries the SATA interface (I looked inside it with a hex editor to see what libraries are linked inside, and the only libs I saw were sata related.), and so it only populates the list with SATA backed devices.

Since it just outputs a structured plain text when the query is invoked, and most other functions could be wrapped using my script based methods, it might be possible to replace this binary executable with a script that does a lot of stuff behind the scenes (getting sizes from the /sys block, setting up new /dev/md* devices with the echo method I discovered, then invoking mdadm and doing the needful, etc.) and returns the appropriate data when it is fed the right arguments, which would then un-neuter the RAID manager.

I am just not sure that is either safe, or appropriate.


I understand why not safe, but why not appropriate? Meaning you are not sure that is the right file to mod?


It is the right file to mod, just I am unsure what all other ancillary functions it performs. Additionally, the main raid group created by the MyCloud is not really safe to mess with, so you would need to manage disks OTHER than the internal disk for safety reasons. Then, on top of that, much like getting iscsi volumes up, it only comes up at the last leg of the init process when the wdcrack init script runs.

I am also unsure a script is really the correct vehicle to use to replace a binary executable. Sure, you can do basically all the same things the binary does, but hmm… You can do some things with executables you really shouldnt be trying to do with scripts.

Before I get really invested in this, I need to get some research items from people with real EX2 or the like versions of the MyCloud, as I need examples of multi-disk xml files so that I can structure them properly/return proper returns for multiple disks from the script.

For safety reasons, I would always refuse to return /dev/sda in the list, personally-- that will keep users from setting up dangerous configurations that the single bay clouds are not really safe to use with. Creating new arrays from USB and iSCSI disks would be very handy though, so it would still be a worthwhile ordeal-- just hmm…

Yeah, not sure script is appropriate vehicle.


I see. I got tired of the ex2 because the fan would sometimes be non stop and at annoying frequency, and sometimes the disks would be burning hot and the thing would not start the fan! So I got the ex4100 instead. If you need files from there let me know. Cheers


caveats… everything that I covet has caveats :stuck_out_tongue:


Ok, I know this is kinda old, but I decided to revisit iscsi on the mycloud today, after reading Ralphael make the statement that he did not like how his targets (on an EX2, but the subsystem is the same on my hacked gen2) were container files, instead of physical LUNs

So, I decided to see if you could play fakeout with the iscsi subsystem, and pull a switcharoo on the image file, with a symbolic link pointing directly to a block device.

The experiment seems to be successful.

I attached a 120gb SATA disk using an external USB3 adaptor, that has no partitions defined.
I then created a temporary target in the iscsi configuration panel, and gave it a 1gb size. (smallest you can set)
Then I SSHed into the box, and pulled the switcharoo. On my gen2, the location of the image files is:


I used mv to rename the target container file, then created a symbolic link to replace it, that points at the USB disk’s raw block device. (Since everything runs as root on these things, I can totally do this.)

However, the size of the target does not automagically update. It seems to be controlled by some config file someplace that I have not found. What you CAN do though, is increase the size of target so that it matches the size of the volume you have pointed it at, using the web interface. I made it 1gb smaller, because HDD manufacturers lie like weasels about the disks’s physical size for marketing purposes, and this gives me the buffer I need.

I then connected to the target with a windows box, partitioned, formatted, and copied data to it. It appears to be working as expected.


good job I say… we need a speed comparison1


What will surely get you salivating is that since you can point it directly at a block device, you could point it directly at an md device, and have a RAID backed hardware LUN…

As for speed, it does seem slightly faster than the disk image based approach it does by default, but I have not performed comprehensive testing.

(To be really comprehensive, I would need to test the raw interface with a ram backed block device, but the 1gb min size is a showstopper there. I would like to perform that test as a control to see where and how much the bottleneck is from the protocol/stack itself, vs the underlying media. A media that physically does not exist, like a ramdisk, would serve my needs perfectly for such a test, but the Gen2 only has 512mb of ram. Also, I dont like drilling holes in my walls, so I am using a wireless AC network, which is not as fast as wired gigabit. I would have to waddle downstairs with a wired device right off the router to properly test.)

That being said, I did have defraggler “Profile” the two iscsi LUNs I have connected to with my upstairs windows box. The windows box upstairs really needs a proper wireless AC NIC installed, but the one I bought for it got put into a loaner PC I lent a co-worker after her house burned down, so I am using some horrible gigabit-wifi bridge consumer grade POS which introduces a whole new realm of difficulty in getting reliable speed comparisons… BUT, since both LUNs are being accessed through this nightmarish clusterfuck, (Which of course, slows EVERYTHING down) and there is still a noticable/measurable performance gain using the hardware LUN…

The reported profiled speeds from Defraggler are:

G: (this is the image file based LUN) 3.47mb/sec
H: (Switcharoo test LUN) 5.65mb/sec

When writing to the LUN using windows explorer, I got around 15mb/sec through that shitty bridge though. I will pull crystalmark and get a proper measure in a bit… but yeah, it will still be suspect due to that bridge.

Quick and dirty through crystal disk mark shows that it is just a teensy bit slower than the file backed LUN. I find that very surprising. Granted, the hardware LUN is being hosted by the Gen2’s USB3 port, which is “well known” for not actually giving USB3 speeds… Due to that, I was expecting the file backed LUN to be significantly faster… But the difference is not anything to write home to mommy about.

I suspect that crappy bridge is just destroying the throughput and I am not getting a proper measurement. In a few days I will have time off again, and I will see about replacing that bridge with a proper AC card.


well based on those stats, we can then conclude that it is 39% faster with a hardware LUN which going back to my stats of about 57.3MB/s reads on an iSCSI image based LUN, I should get about 92.25MB/s reads on a hardware LUN which is basically the normal speed of the EX2 when connected via SMB.


Oh ■■■■, dont get me started on how terrible SMB speed is though this bridge. 3mb/sec reads. PAINFUL.

ISCSI is fantabulously faster for some reason.


Just tried this and its not working for me. Could I see your updated define.js in full?. the WDCRACK 1.2 didnt come with one :frowning:

I dont see the storage option in the menus to allow me to create an ISCSI volume. Not sure where the problem is :frowning:

it looks like the isn’t being called because once the unit is up, i can run the init script and i see output that the iscsi stuff is loaded. If it was being executed at boot i’d expect it would tell me the modules are already loaded etc.


Ok, here is my define.js

var DEV_NAME = " [WD My Cloud EX2 ™]";

var MODEL_NAME = “KC2A”;
var IPV6_FUNCTION = 1;
var LAN_PORT_NUM = 1;
var VOLUME_NUM = 1;
var SHARE_FUNCTION =1; //facebook,flickr,picasa
var DFS_FUNCTION =1; //4-bay:1
var _MAX_TOTAL_AD_GROUP = 200;
var _MAX_TOTAL_ACCOUNT = 512; //4-bay:512
var _MAX_TOTAL_GROUP = 64; //4-bay:64
var _MAX_TOTAL_SHARES = 1024; //not include created by system,ex:Public,SmartWare,TimeMachineBackup… ITR No.: 99836
var _MIN_F_TEMP = 140; //4-bay:140
var _MAX_F_TEMP = 158; //4-bay:158
var _MIN_C_TEMP = 60; //4-bay:60
var _MAX_C_TEMP = 70; //4-bay:70
var _MIN_FAN_SPEED = 0;
var TIME_FORMAT = 12; //12 or 24
var A_UPDATE_URL = “”;
var A_BACKUP_URL = “”;
var A_MOBILE_URL = “”;
var A_POLICY_URL = “”;
var D_UPDATE_URL = “”;
var D_BACKUP_URL = “”;
var D_MOBILE_URL = “”;
var FORGOT_PW_URL = “”;
var DEV_ID = “wdfmycloud_ex2”;
var PROJECT_NAME = “MyCloudEX2”;
var _ADMIN_UID = “500”;
var _ADMIN_GID = “1001”;
var SYSTEM_TEST = 1;
var WEBHELP_UPDATE = “09022015”;

Bear in mind, I have been attempting other experiments since then, which is why I am reporting as an EX2 instead of a Mirror. ISCSI should work with either.

Make sure that all of the utilties got copied by the init script. If you are missing some, it will be all kinds of hair pulling. prealloc is especially needed, else the web interface just hangs when you create the target, etc.


sweet, its all working great now :slight_smile:

Thanks for help. Considering how well it works, i wonder why WD disabled this feature from factory?