Where are iSCSI read-only targets?

[digitalis99]

I have searched the forums, but haven't come up with any answer to my question. I've seen what appear to be older FreeNAS screenshots that show configuring an iSCSI target that can be marked as read only. 9.3 doesn't display this checkbox. Is the function gone for good, will it make a comeback, or is it simply not visible in the GUI any more?

I'd like to connect two targets to the same extent, one read-write and the other read-only. If someone knows that this is impossible, please alert me.

 

[mav@]

I'd like to connect two targets to the same extent, one read-write and the other read-only. If someone knows that this is impossible, please alert me.

Internally CTL supports read-only extents/LUNs. But that is a flag of the LUN, not LUN<->Target association, and it is not present in WebUI now as very rare thing.

What scenario do you want to configure with that functionality? Without having clustered file system you may not want to share same extent to several initiators unless they are all read-only. Even if only one of them is writing, it may confuse the readers.

 

[digitalis99]

Internally CTL supports read-only extents/LUNs. But that is a flag of the LUN, not LUN<->Target association, and it is not present in WebUI now as very rare thing.

What scenario do you want to configure with that functionality? Without having clustered file system you may not want to share same extent to several initiators unless they are all read-only. Even if only one of them is writing, it may confuse the readers.

I'd like to configure the latter scenario you cite, in the hopes that one machine can write to the extent and the change be visible and readable by those who have mounted the read-only target pointing to the same extent. I *have* to run Windows as my initiator machines, and the LUN would be formatted NTFS. I already know I can't have two initiators with read-write access to the same NTFS LUN without instantly corrupting the volume, but I'm hoping to have multiple read-only initiators that can see the writes being done on the one that is mounted read-write. Since the Windows (and Starwind) initiator doesn't/don't have the option to mount an iSCSI target as a read-only target, I can't prevent writes on the initiator side. That leaves me with preventing writes by all but one system on the target side.

The cluster/parallel filesystem options for Windows are almost non-existent, hence my desire to at least attempt something that may be beyond the bounds of the developers initial designs.

 

[cyberjock]

You can't really do read-write to one server and read-only from the other. If you don't have a clustering file system, it just won't work.

So yeah.. impossible unless you are using a clustering file system. And if you are using a clustering file system, then you shouldn't care if it is read-only or not. ;)

 

[cyberjock]

@digitalis99
You posted before I saw your response. But yeah, won't work with what you want to do with NTFS. So you'll need to seek out some other solution. :/

 

[digitalis99]

@digitalis99
You posted before I saw your response. But yeah, won't work with what you want to do with NTFS. So you'll need to seek out some other solution. :/

I'm really not trying to be rude when I ask this: So, have you actually tried it, or is that just speculation? I ask because I've done many things that aren't expressly documented or known to work with Windows in the past. If you've tried it, great, my search will lead me elsewhere. :)

 

[cyberjock]

I'm really not trying to be rude when I ask this: So, have you actually tried it, or is that just speculation? I ask because I've done many things that aren't expressly documented or known to work with Windows in the past. If you've tried it, great, my search will lead me elsewhere. :)

I've seen people try it and try to get my help to figure out how to make it work.. it doesn't work. Microsoft will even tell you that it won't work. :P

If you mount NTFS read-only the OS assume the file system is static and not being changed by something else (that would be something reserved for clustered file systems). So while you won't corrupt the NTFS file system, anything that could mount the file system would be retrieving what would be perceived as corrupted data from the files as well as corrupted data from the file system itself.

Even if that weren't a problem, you cannot have a LUN that is writeable for one system, but read-only for another. So you've got 2 reasons why this is impossible. ;)

 

[digitalis99]

I've seen people try it and try to get my help to figure out how to make it work.. it doesn't work. Microsoft will even tell you that it won't work. :p

If you mount NTFS read-only the OS assume the file system is static and not being changed by something else (that would be something reserved for clustered file systems). So while you won't corrupt the NTFS file system, anything that could mount the file system would be retrieving what would be perceived as corrupted data from the files as well as corrupted data from the file system itself.

Even if that weren't a problem, you cannot have a LUN that is writeable for one system, but read-only for another. So you've got 2 reasons why this is impossible. ;)

Cool...I'll have to look somewhere else. Back to the seemingly endless search for a solution to a relatively simple problem.

 

[cyberjock]

I won't lie.. the whole "need a clustering file system" really limits the options. Especially on the Windows side of things. If you want to go anything else, there's lots of options.

I've been fortunate that the limitations haven't been a problem for me... yet. I do anticipate that the day is coming where I'm gonna be cussing like a sailor since I know I'll need a clustering file system and have no good, easy options.

 

[digitalis99]

I won't lie.. the whole "need a clustering file system" really limits the options. Especially on the Windows side of things. If you want to go anything else, there's lots of options.

I've been fortunate that the limitations haven't been a problem for me... yet. I do anticipate that the day is coming where I'm gonna be cussing like a sailor since I know I'll need a clustering file system and have no good, easy options.

Yeah...try setting up an all-Windows compute cluster of a few hundred nodes and trying to figure out how to effectively feed them with large datasets (like dozens of GB). That will elicit the cussing. Heck, I could get by with an SMB cache sort of function, but alas, Windows doesn't even have that. Branch Cache is kind of close, but totally unusable when everything is local.

We've been testing a bit with OrangeFS, but there is an intentional architectural design limitation that is precluding us from moving forward...that, and the Windows client isn't really used in production anywhere. We've already helped them uncover a few bugs.

I'm looking at XtreemFS now, because I can't seem to find much info on anything else...even proprietary software. The official Windows Cluster Service doesn't even support more than one primary machine for reads. If you can avoid Windows, consider yourself fortunate.

 

[mav@]

I think there could be some scenarios where limitations of NTFS can be avoided by administrative means. It is definitely bad idea to modify data underneath active readers, but if I understand right, you may easily avoid live modifications in your producer-consumer scheme. You could use cool feature of ZFS -- snapshots:
1) Create ZVOL;
2) Export that ZVOL for writing to single initiator, make it upload the data, unmount it clean and create ZFS snapshot of it;
3) Export that snapshot as separate read-only extent/target and safely mount it on all readers;
4) When you need update the data, again mount the ZVOL to single initiator for writing, update the data, unmount and create new snapshot;
5) Export that new snapshot as new extent/target and tell initiators to remount to it at some point when it is needed/possible;
6) After all initiators remounted you can delete old snapshot, or leave it for history if pool space permits. If needed, different initiator may even continue accessing different data snapshots for unlimited time.

PS: You may not even need to unmount the writer if you find how to make it flush modified filesystem buffers to make ZFS snapshot consistent. VMware tools somehow do it on VM guests, so theoretically it is possible.

 

[digitalis99]

I think there could be some scenarios where limitations of NTFS can be avoided by administrative means. It is definitely bad idea to modify data underneath active readers, but if I understand right, you may easily avoid live modifications in your producer-consumer scheme. You could use cool feature of ZFS -- snapshots:
1) Create ZVOL;
2) Export that ZVOL for writing to single initiator, make it upload the data, unmount it clean and create ZFS snapshot of it;
3) Export that snapshot as separate read-only extent/target and safely mount it on all readers;
4) When you need update the data, again mount the ZVOL to single initiator for writing, update the data, unmount and create new snapshot;
5) Export that new snapshot as new extent/target and tell initiators to remount to it at some point when it is needed/possible;
6) After all initiators remounted you can delete old snapshot, or leave it for history if pool space permits. If needed, different initiator may even continue accessing different data snapshots for unlimited time.

Unfortunately, writes need to happen too often for this approach to work in my case.

 

[mav@]

Unfortunately, writes need to happen too often for this approach to work in my case.

It sounds like question of proper scripting. Though indeed there is some lower limit that penalize caching too much to keep this scheme useful.

Any way I don't know way for initiator to survive/detect underlying data changes on mounted NTFS without explicit remount. If you need granularity smaller then whole FS, then either clustered FS or some file protocol such as SMB or NFS.

 

[bmh.01]

NTFS aside, this would be an ideal feature for running direct-san VMFS backups from veeam though. To give the veeam box read only access to the vmfs luns, you can give it r/w and it shouldn't be an issue as long as someone doesn't try to initialise the lun but it would be belt-and-braces to be able to only give it read only access.