Re: [zfs-discuss] Exporting iSCSI - it's still getting all the ZFS protection, right?
Everything that has readed the storage will be written to disk as sent. However watch our for the writeback cache setting of comstar. If you enable a writeback cache AND your machine boots very fast ( 2 Minutes), you may have data integrity issues because Windows thinks the target was just shortly gone, however everything in memory cache wil be lost. So don't enable the write back cache on Comstar and be prepared to life with the resulting performance (if you dont have a zil). Regards, Robert -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Exporting iSCSI - it's still getting all the ZFS protection, right?
Brandon High wrote: On Mon, May 3, 2010 at 4:33 PM, Michael Shadle mike...@gmail.com wrote: Is ZFS doing it's magic checksumming and whatnot on this share, even though it is seeing junk data (NTFS on top of iSCSI...) or am I not getting any benefits from this setup at all (besides thin provisioning, things like that?) The data on disk is protected, but it's not protected over the wire. You still get snapshots, cloning, and all the other zfs features for the dataset though. -B If someone wrote a ZFS client, it'd be possible to get over the wire data protection. This would be continuous from the client computer all the way to the storage device. Right now there is data protection from the server to the storage device. The best protected apps are those running on the same server that has mounted the ZFS pool containing the data they need (in which case they are protected by ZFS checksums and by ECC RAM, if present). A ZFS client would run on the computer connecting to the ZFS server, in order to extend ZFS's protection and detection out across the network. In one model, the ZFS client could be a proxy for communication between the client and the server running ZFS. It would extend the filesystem checksumming across the network, verifying checksums locally as data was requested, and calculating checksums locally before data was sent that the server would re-check. Recoverable checksum failures would be transparent except for performance loss, unrecoverable failures would be reported as unrecoverable using the standard OS unrecoverable checksum error message (Windows has one that it uses for bad sectors on drives and optical media). The local client checksum calculations would be useful in detecting network failures, and local hardware instability. (I.e. if most/all clients start seeing checksum failures...look at the network; if only one client sees checksum failures, check that client's hardware.) An extension to the ZFS client model would allow multi-level ZFS systems to better coordinate their protection and recover from more scenarios. By multi-level ZFS, I mean ZFS stacked on ZFS, say via iSCSI. An example (I'm sure there are better ones) would be 3 servers, each with 3 data disks. Each disk is made into its own non-redundant pool (making 9 non-redundant pools). These pools are in turn shared via iSCSI. One of the servers creates RAIDZ1 groups using 1 disk from each of the 3 servers. With a means for ZFS systems to communicate, a failure of any non-redundant lower level device need not trigger a system halt of that lower system, because it will know from the higher level system that the device can be repaired/replaced using the higher level redundancy. A key to making this happen is an interface to request a block and its related checksum (or if speaking of CIFS, to request a file, its related blocks, and their checksums.) ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Exporting iSCSI - it's still getting all the ZFS protection, right?
Quick sanity check here. I created a zvol and exported it via iSCSI to a Windows machine so Windows could use it as a block device. Windows formats it as NTFS, thinks it's a local disk, yadda yadda. Is ZFS doing it's magic checksumming and whatnot on this share, even though it is seeing junk data (NTFS on top of iSCSI...) or am I not getting any benefits from this setup at all (besides thin provisioning, things like that?) These were my steps: Make sure service is enabled on the NAS: # svcadm enable /system/iscsitgt Create the zvol and share it (sparse volume size of 1000 gigs) # zfs create -s -V 1000g tank/shares/foo # zfs set shareiscsi=on tank/shares/foo # zfs set compression=on tank/shares/foo Install Microsoft iSCSI Software Initiator Version 2.08 on the Windows server http://www.microsoft.com/downloads/details.aspx?familyid=12cb3c1a-15d6-4585-b385-befd1319f825displaylang=en Thanks in advance... ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Exporting iSCSI - it's still getting all the ZFS protection, right?
On 05/ 4/10 11:33 AM, Michael Shadle wrote: Quick sanity check here. I created a zvol and exported it via iSCSI to a Windows machine so Windows could use it as a block device. Windows formats it as NTFS, thinks it's a local disk, yadda yadda. Is ZFS doing it's magic checksumming and whatnot on this share, even though it is seeing junk data (NTFS on top of iSCSI...) or am I not getting any benefits from this setup at all (besides thin provisioning, things like that?) Yes, the volume is part of your pool, which ZFS looks after. -- Ian. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Exporting iSCSI - it's still getting all the ZFS protection, right?
On Mon, May 3, 2010 at 4:33 PM, Michael Shadle mike...@gmail.com wrote: Is ZFS doing it's magic checksumming and whatnot on this share, even though it is seeing junk data (NTFS on top of iSCSI...) or am I not getting any benefits from this setup at all (besides thin provisioning, things like that?) The data on disk is protected, but it's not protected over the wire. You still get snapshots, cloning, and all the other zfs features for the dataset though. -B -- Brandon High : bh...@freaks.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
