Re: [zfs-discuss] RFE: Un-dedup for unique blocks
So ... The way things presently are, ideally you would know in advance what stuff you were planning to write that has duplicate copies. You could enable dedup, then write all the stuff that's highly duplicated, then turn off dedup and write all the non-duplicate stuff. Obviously, however, this is a fairly implausible actual scenario. In reality, while you're writing, you're going to have duplicate blocks mixed in with your non-duplicate blocks, which fundamentally means the system needs to be calculating the cksums and entering into DDT, even for the unique blocks... Just because the first time the system sees each duplicate block, it doesn't yet know that it's going to be duplicated later. But as you said, after data is written, and sits around for a while, the probability of duplicating unique blocks diminishes over time. So they're just a burden. I would think, the ideal situation would be to take your idea of un-dedup for unique blocks, and take it a step further. Un-dedup unique blocks that are older than some configurable threshold. Maybe you could have a command for a sysadmin to run, to scan the whole pool performing this operation, but it's the kind of maintenance that really should be done upon access, too. Somebody goes back and reads a jpg from last year, system reads it and consequently loads the DDT entry, discovers that it's unique and has been for a long time, so throw out the DDT info. But, by talking about it, we're just smoking pipe dreams. Cuz we all know zfs is developmentally challenged now. But one can dream... finglonger ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs receive options (was S11 vs illumos zfs compatiblity)
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- boun...@opensolaris.org] On Behalf Of Edward Ned Harvey zfs send foo/bar@42 | zfs receive -o compression=on,sync=disabled biz/baz I have not yet tried this syntax. Because you mentioned it, I looked for it in the man page, and because it's not there, I hesitate before using it. Also, readonly=on ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] iscsi confusion
I am confused, because I would have expected a 1-to-1 mapping, if you create an iscsi target on some system, you would have to specify which LUN it connects to. But that is not the case... I read the man pages for sbdadm, stmfadm, itadm, and iscsiadm. I read some online examples, where you first sbdadm create-lu which gives you a GUID for a specific device in the system, and then stmfadm add-view $GUID, and then itadm create-target. It's this last command that confuses me - Because it generates an iscsi target iqn.blahblah... And it will create as many as you specify, regardless of how many LUN's you have available. So how can I know which device I'm handing out to some initiator? And if an initiator connects to all those different iqn.blahblah addresses... What device will they actually be mucking around with? I'm not quite sure what in my brain is thinking wrong, but I'm guessing the explanation is something like this: (can anyone tell me if this is the correct interpretation?) I shouldn't be thinking in such linear terms. When I create an iscsi target, don't think of it as connecting to a device - instead, think of it as sort of a channel. Any initiator connecting to it can see any of the devices that I have done add-views on. But each iscsi target can only be used by one initiator at a time. Is that a good understanding? Thanks... ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
