I want to setup a storage farm with iSCSI. I have 2 cluster node machine, 1 iscsi target machine that has 8TB installed as RAID 10. The capacity is now 8TB, but I'll upgrade the capacity in future. Let's say, I installed clusters as file server, and I connected these servers to iscsi target, then I shared 8TB capacity as an only folder to the windows users. Users now see only a folder whose capacity is 8TB. But if I want to add another 8TB to expand the main capacity, the users must not see the second folder for this new 8 TB. The users must see only a folder as before, but this time this folder's capacity expanded to 16TB. And so on, if I add another 8TB, the users must deal with only a folder. For this purpose, I've learnt that ZFS can expand its size without a problem. So if I use ZFS as a file system on iSCSI luns, how can the cluster machines see the ZFS. Because the cluster machines have windows 2008. Is there another way to expand the size of shared folder without a problem? Does ntfs support it?
First off I'd say you need to take a step back here and learn the difference between block and file storage. I'm not convinced that you truly understand the difference from the phrasing of your question.
You say that you have an iSCSI target machine and mention ZFS. Is your iSCSI target system running Solaris/OpenSolaris/NexentaOS or BSD? If not then you can't realistically use ZFS. (While FUSE might work I would not depend on it for a server)
As to the Windows 2008 cluster systems seeing a ZFS files system on an iSCSI LUN. Not going to happen. Here is where I don't think you understand the difference between block and file storage, I don't know of any decent sites where you can learn about this, maybe someone else reading this can suggest a good site? Here is a link to a halfway decent article about the difference between block and file storage:
I always visualize the storage in layers, in this case you would most likely have:
2) Raid groups (either a ZFS zpool or a traditional RAID group with a couple of disks)
3) Volume (Think C: in Windows or LVM in Linux)
4) Filesystem (NTFS in Windows, ZFS on Solaris, ext3/4 on Linux)
Depending on the iSCSI target implementation the LUNs could be shared up from raw devices (layer #3) or as large files on a filesystem (Layer #5). A ZFS based target would almost certainly use files residing on the ZFS file system. When you export the LUNs from the iSCSI target the underlying ZFS filesystem becomes invisible to the Windows systems using it. To them they just see a blank disk initially. Then you simply format the LUN using NTFS and install clustering. That adds the following layers to our diagram:
5) LUN file on target (Great big binary blob)
6) iSCSI target layer
7) Volume (i.e. D:)
8) Filesystem (NTFS)
9) User data files.
I hope I've been somewhat clear :-)
And to address your central issue of extending LUNs that are NTFS formatted. That's pretty simple, basically use the extend command in diskpart and the volume will instantly expand to fill all available space. I do it all the time on iSCSI LUNs shared up from a NetApp. Be aware though that extending the C: drive can be awkward as you have to reboot into WinPE to take the volume offline for a moment to do the extend. Perhaps this is fixed in Windows 2008 though, I haven't tried it there yet... (Definitely not the case in Windows 2003, it needs diskpart in WinPE)