zfs discuss - May 2010 - 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-befd1319f825&displaylang=en

Thanks in advance...

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.

On Mon, May 3, 2010 at 4:33 PM, Michael Shadle <mike503 at 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 : bhigh at freaks.com

Brandon High wrote:
> "On Mon, May 3, 2010 at 4:33 PM, Michael Shadle <mike503 at
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.)

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100507/05a27ac0/attachment.html>

AFAIK, zfs should be able to protect against (if the pool is redundant), or at
least
detect, corruption from the point that it is handed the data, to the point
that the data is written to permanent storage, _provided_that_ the system
has ECC RAM (so it can detect and often correct random background-radiation
caused memory errors), and that, if zfs controls the whole disk and the disk
has a write cache, the disk correctly honors requests to flush the write cache
to permanent storage.  That should be just as true for a zvol as for a
regular zfs file.

What I''m trying to say is that zfs should give you a lot of protection
in your
situation, but that it can do nothing about it if it is handed bad data: for
example, if the client is buggy and sends corrupt data, if somehow a network
error goes undetected (unlikely given that AFAIK iSCSI runs over TCP and
at least thus far never over UDP, and TCP always checksums (UDP might not)),
if the iSCSI server software corrupts data before writing it to disk, etc.

In other words, zfs probably gives more protection to a larger portion of the
data path than just about anything else, but in the case of a remote client,
whether iSCSI, NFS, CIFS, or whatever, the data path is longer and
distributed, and the verification that zfs does only covers part of that.

What I''m saying would _not_ apply if the client were doing zfs onto
iSCSI
storage; in that case, the client''s zfs would also be looking after
data integrity.
So the closer to the data generating application that the integrity from that
point on is provided, the less places something bad can happen without being
at least detected.

Note: I can''t guarantee that any of what I said is correct, although I
would
be willing to risk my own data as if it were.
-- 
This message posted from opensolaris.org

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