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:
1) Disks
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)
5) Files.
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)

  • 3
    Actually you can use zfs with iSCSI it's how it works on Solaris. You create a ZVOL which is then shared via iSCSI. This shows up as a block device to the iSCSI initiator which can then be formatted with whatever file system you want. However I'm not sure how this works with a Windows Cluster as NTFS to my knowledge does not have distributed locking and is not a cluster aware/safe file system. So these iSCSI target LUNS may only be able to be mounted by a single system. – 3dinfluence Mar 15 '10 at 0:10
  • I should add to that. Even though your initiator isn't using the zfs file system on the LUN/block device in this case. You are still using ZFS to manage your storage and LUNs. So you still get some of the benefits of ZFS. Such as the flexible pooled storage, checksums, and self healing. – 3dinfluence Mar 15 '10 at 0:43
  • Yes, that's pretty much as I described it, depending on the implementation the iSCSI LUN could be a zvol or a file. You do get the underlying flexible pooled storage ability, but zfs checksums don't apply to files stored in a higher level disk format such as NTFS. NTFS does have distributed locking and is fully cluster aware as long as all the attached systems are running Windows 2008 R2 and are using the Cluster Shared Volumes option. Currently this only works with Hyper-V though so that's not very useful to a lot of people. – Ausmith1 Mar 15 '10 at 14:12
  • The checksums are still happening on a zvol and on a file backed LUN. ZFS doesn't know anything about the file or data its storing...a bit is a bit to it. So it's still there and happening behind the scenes. NTFS however is just aware of the block device layer that is presented to it. – 3dinfluence Mar 15 '10 at 19:07
  • I only like to expose block devices to windows machines. Having double filesystems with LUN file targets is just asking for trouble. – Brain2000 Jun 21 '20 at 14:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy