ISCSI - NTFS; am I missing something?

[Neil Rubenstien]

I am trying to wrap my head around ISCSI. I am running an AIO400. I have setup the AIO400 as the Target and my workstations as Initiators. They are connected and comunicate fine. I would like to do block level writing. When i add the raid array to the workstation it asks me to format the drive as NTFS. Is this File IO? If so, how do I setup block level IO.

Detailed help would be great, Thanks in advance.

Newbie

[Uwe Zessin]

On the iSCSI level this is block I/O and your initiator has full control over the file system. In that case, you must not allow a second initiator access to the same ressouce, because Windows does not know how to share NTFS via a block server like an iSCSI target. If it were file I/O like on a file share, you could not create a file system through the share.

[Patrick Terlisten]

Hello,

if you can see a new volume in the disk management, and you can create a NTFS file system on it, you do block IO to it. File IO would be using a file share over CIFS or NFS.

You can create an NTFS file system on a file share.

Best regards,
Patrick

[Neil Rubenstien]

Hi,

Thanks for your response guys. So, I am using block IO. When I called tech support this morning they told me that this is file IO. Block IO would only be used if I install Linux and format the drive as RAW. Then setup the RAW disk as a target. Is this correct?

If I am understanding you correctly I can not have multiple workstations (xp pro) as initiators sharing the same target. Is this correct.

Sorry I am just learning the language and am not that versued yet.

Thanks

[roberttco]

Hi Neil,
I don't know if your answer lies above but let me take a whack at this also. First a little theory. The iSCSI target maintains a file (the virtual device file) on the AiO. It then presents this file as a block device to the iSCSI initator on your workstation. On the wokstation, the OS sees the iSCSI target virtual device (it is virtual because in reality it is a file and not a device) as if it were a physical device on your system (e.g. a disk drive). So until you put a partition on the iSCSI device it is a raw device that you can do block IO to.

So now the question is what is your application ? As noted above you want to ensure no two systems are writing to the same data at the same time. You can, in fact, present the iSCSI device to multiple initators at the same time as long as the file system that is on that device supports it. I am interpreting what you wrote as meaning you would have different iSCSI targets for each initator/workstation. If this is true then you should not have any problems. Incidentally, multiple hosts (initators) for one iSCSI lun created using the All-in-One Storage Manager is not supported.

Finally, while I did not explicitly say so, you can create an NTFS partition and format it in the iSCSI device without any problems. In fact you can create multiple partitions and each workstation could access a partition but it would be wiser to use separate iSCSI targets if this was your goal.

[Neil Rubenstien]

Well, maybe it is best I explain what I am doing.

I have one Target (aio400r) and 5 workstations (Initiators ?). I want the aio400r to be a SAN using ISCSI. I want to write to disk at the block level. Simple as that.

The system I am creating is based on a piece of software we are using (Autodesk Revit). The idea behind the software: There is a central file on the aio400r, there are local files on all 5 workstations (it could be 1 or more) each workstation has the same local file and constantly comunicates with the central file about who is working on what aspect of the file.

Am I on the write track or should i just use a NAS with Linux file system? I was hoping to skip the NAS and got the a SAN solution for speed sake.

Thanks, any advice would be great

[roberttco]

Looking at the Revit documentation, it indicates that you need a central file repository but that repository is a simple network shared folder. In your case, you would use the AiO 'Create a Share' function instead of using iSCSI. In this way you can share the central file to as many workstations as you need. I am looking at page 1189 (Chapter 18 - Working in a Team) of the Revit Architecture 2009 users guide. Please let me know if this not the same workflow you are describing.

[Neil Rubenstien]

Yes, you are right on track. We are currently using file sharing (using NFS) it works fine, a bit slow (this is the problem). We are hoping to give it a bit more speed by using iscsi block level writing. The problem is iscsi does not work like a shared network drive (in the way that we need, permisions, read / write, etc) There is a software called metaSan ISCSI, it seems to do what we are looking for. is there any way to do this without using there software? check out

http://www.tiger-technology.com/article.php?story=MetaSANiSCSI

Thanks

[roberttco]

It appears you are using non-windows clients to run Revit. Is this correct ? Or did you choose to use NFS for a different reason ? CIFS/SMB will provide a much higher throughput if you are using Windows clients.

Regardless one issue with the plan to use iSCSI is that your application would need to be aware of the other systems so that they do not corrupt the common file. Unless the Revit software uses some sort of distributed locking mechanism sharing an iSCSI LUN or for that matter any sort of SAN storage will not work. From what I read, in the Revit documentation, it does not appear that this is how they implemented it. In fact the reccomended method of copying the central file and then publishing the changes back to the shared file implies, quite strongly, that any sort of shared block device will not work as you had hoped.

[Neil Rubenstien]

Sorry, I gave you miss information. We are on an all Windows based network. XP Pro for clients and Server 2003 for domain controlers and storage servers. We are not using but CIFS/SMB

Revit works by copying the central file (Located on the central storage) to your local XP Pro workstation (they call these local files). You are thinking interms of checking in and out documents. This isnt the case, the central file is essentially like a SQL database. Once you open the local file it constantly talks back to the central file to see who has permissions to work on portions of the building. So esentially you could have 10 local files saving to central and checking to see who is working on what portion of the building. Hope this makes sence.

So you can see this can be band width intensive. I was essentially hoping to use ISCSI and Metasan to get the speed and throughput we need.

your thoughts.

Thanks again for all your help on this.

[roberttco]

I beleive in your case you want to look at using worksets and make the worksets non-editable but allow the elements to be editable - maybe that is what you are doing. It is in effect a method of checking in and out (or taking or relenquishing ownership of an element). The state of who has what is maintained in the central file - but you probably already know this. Nevertheless, using iSCSI or a SAN target will not work because Revit is not able to guarentee that more than one system will be writing to the central file at the same time. This check is performed at the file system level on the file server (e.g. one instance of revit tries to open the file as read-write while another instance alredy has it opened (r/w). The first operation will fail and you will get a message indicating that somone else is using the file. in a SAN environment, each machine will have it's own sense of the stateof the file so on machine 1 it thinks it has write access to the file and machine 2 does to. Now they both save at the same time. The result is most likely a corrupted file.

From your inital post, it seems like you are investigating the use of an AiO for this task but I was wondering if you have some performance expectaitons or data from a previous solution. It seems that fundamentally you are concerned about the performance. I am just curious about the performance requirements.

I did some across a couple resources that may be of interest:

http://discussion.autodesk.com/thread.jspa?threadID=561803

http://cad.amsystems.com/products/docs/autodesk-revit-6-worksets.pdf

[Marc Hall_1]

on comments by:
Uwe Zessin
Jul 15, 2008 18:00:51 GMT Unassigned
On the iSCSI level this is block I/O and your initiator has full control over the file system. In that case, you must not allow a second initiator access to the same ressouce, because Windows does not know how to share NTFS via a block server like an iSCSI target. If it were file I/O like on a file share, you could not create a file system through the share.

Not sure what you mean. I just installed a Buffalo iSCSI device and have two servers accessing it. I thought that was the advantage if iSCSI so you can do that?
Or is MPIO (Microsoft iSCSI Initiator, supported on this device) just for redundancy or fail over?.
TIA

[Uwe Zessin]

Marc,
I am not familiar with this "Buffalo iSCSI device".

Many iSCSI target allow multiple concurrent initiator connects, but the file system is managed by the server's operating system. Many FS/OS combinations expect exclusive access and DO NOT understand how to properly share a volume. Corruption starts as soon as the second server mounts the file system.

Just create and delete some directory trees from both servers concurrently for, lets say, half a hour - then run a file system integrity check.


It does not matter if you use parallel SCSI, iSCSI, Fibre Channel - all are 'simple' block protocols and don't know what a file is.

The iSCSI initiator just taps between the network stack (lower layer) and the file system (upper layer). MPIO can be used for simple failover and (in some cases) for load balancing.