Thanks for all the feedback. This PSARC case was approved yesterday and
will be integrated relatively soon.
Adam
On Wed, Nov 01, 2006 at 01:33:33AM -0800, Adam Leventhal wrote:
Rick McNeal and I have been working on building support for sharing ZVOLs
as iSCSI targets directly into ZFS. Below
Hello Richard,
Wednesday, November 1, 2006, 11:36:14 PM, you wrote:
REP Adam Leventhal wrote:
On Wed, Nov 01, 2006 at 04:00:43PM -0500, Torrey McMahon wrote:
Lets say server A has the pool with NFS shared, or iSCSI shared,
volumes. Server A exports the pool or goes down. Server B imports the
On Wed, Nov 01, 2006 at 04:00:43PM -0500, Torrey McMahon wrote:
Spencer Shepler wrote:
On Wed, Adam Leventhal wrote:
On Wed, Nov 01, 2006 at 01:17:02PM -0500, Torrey McMahon wrote:
Is there going to be a method to override that on the import? I can see
a situation where you want to
Ceri Davies wrote:
For NFS, it's possible (but likely suboptimal) for clients to be
configured to mount the filesystem from server A and fail over to
server B, assuming that the pool import can happen quickly enough for
them not to receive ENOENT.
IIRC NFS client side failover is really only
On Thu, Darren J Moffat wrote:
Ceri Davies wrote:
For NFS, it's possible (but likely suboptimal) for clients to be
configured to mount the filesystem from server A and fail over to
server B, assuming that the pool import can happen quickly enough for
them not to receive ENOENT.
IIRC NFS
Cyril Plisko wrote:
On 11/1/06, Adam Leventhal [EMAIL PROTECTED] wrote:
What properties are you specifically interested in modifying?
LUN for example. How would I configure LUN via zfs command ?
You can't. Forgive my ignorance about how iSCSI is deployed, but why
would
you want/need to
On 11/2/06, Rick McNeal [EMAIL PROTECTED] wrote:
The administration of FC devices for the target mode needs some serious
thinking so that we don't end up with a real nightmare on our hands.
As you point out the FC world doesn't separate the port address from the
target name. Therefore each FC
On 11/2/06, Rick McNeal [EMAIL PROTECTED] wrote:
That's how the shareiscsi property works today.
So, why manipulating LUN is impossible via zfs ???
A ZVOL is a single LU, so there's nothing to manipulate. Could you give
me an example of what you think should/could be changed?
I was
Cyril Plisko wrote:
On 11/2/06, Rick McNeal [EMAIL PROTECTED] wrote:
That's how the shareiscsi property works today.
So, why manipulating LUN is impossible via zfs ???
A ZVOL is a single LU, so there's nothing to manipulate. Could you give
me an example of what you think should/could
On Wed, Nov 01, 2006 at 10:05:01AM +, Ceri Davies wrote:
On Wed, Nov 01, 2006 at 01:33:33AM -0800, Adam Leventhal wrote:
Rick McNeal and I have been working on building support for sharing ZVOLs
as iSCSI targets directly into ZFS. Below is the proposal I'll be
submitting to PSARC.
On Wed, Nov 01, 2006 at 12:18:36PM +0200, Cyril Plisko wrote:
Note again that all configuration information is stored with the dataset.
As
with NFS shared filesystems, iSCSI targets imported on a different system
will be shared appropriately.
Does that mean that if I manage the iSCSI
On Wed, Nov 01, 2006 at 02:14:24AM -0800, Adam Leventhal wrote:
On Wed, Nov 01, 2006 at 10:05:01AM +, Ceri Davies wrote:
On Wed, Nov 01, 2006 at 01:33:33AM -0800, Adam Leventhal wrote:
Rick McNeal and I have been working on building support for sharing ZVOLs
as iSCSI targets directly
On 01/11/06, Adam Leventhal [EMAIL PROTECTED] wrote:
Rick McNeal and I have been working on building support for sharing ZVOLs
as iSCSI targets directly into ZFS. Below is the proposal I'll be
submitting to PSARC. Comments and suggestions are welcome.
Adam
Am I right in thinking we're
On 01/11/06, Dick Davies [EMAIL PROTECTED] wrote:
And we'll be able to use sparse zvols
for this too (can't think why we couldn't, but it'd be dead handy)?
Thinking about this, we won't be able to (without some changes) -
I think a target is zero-filled before going online
(educated guess: it
What properties are you specifically interested in modifying?
LUN for example. How would I configure LUN via zfs command ?
You can't. Forgive my ignorance about how iSCSI is deployed, but why would
you want/need to change the LUN?
Adam
On Wed, Nov 01, 2006 at 01:36:05PM +0200, Cyril Plisko
On Wed, Nov 01, 2006 at 01:17:02PM -0500, Torrey McMahon wrote:
Is there going to be a method to override that on the import? I can see
a situation where you want to import the pool for some kind of
maintenance procedure but you don't want the iSCSI target to fire up
automagically.
There
On Wed, Nov 01, 2006 at 10:57:27AM -0800, Adam Leventhal wrote:
On Wed, Nov 01, 2006 at 01:17:02PM -0500, Torrey McMahon wrote:
Is there going to be a method to override that on the import? I can see
a situation where you want to import the pool for some kind of
maintenance procedure but
On Wed, Adam Leventhal wrote:
On Wed, Nov 01, 2006 at 01:17:02PM -0500, Torrey McMahon wrote:
Is there going to be a method to override that on the import? I can see
a situation where you want to import the pool for some kind of
maintenance procedure but you don't want the iSCSI target to
On 11/1/06, Adam Leventhal [EMAIL PROTECTED] wrote:
What properties are you specifically interested in modifying?
LUN for example. How would I configure LUN via zfs command ?
You can't. Forgive my ignorance about how iSCSI is deployed, but why would
you want/need to change the LUN?
Well,
On Wed, Nov 01, 2006 at 09:25:26PM +0200, Cyril Plisko wrote:
On 11/1/06, Adam Leventhal [EMAIL PROTECTED] wrote:
What properties are you specifically interested in modifying?
LUN for example. How would I configure LUN via zfs command ?
You can't. Forgive my ignorance about how iSCSI is
On 11/1/06, Adam Leventhal [EMAIL PROTECTED] wrote:
On Wed, Nov 01, 2006 at 09:25:26PM +0200, Cyril Plisko wrote:
On 11/1/06, Adam Leventhal [EMAIL PROTECTED] wrote:
What properties are you specifically interested in modifying?
LUN for example. How would I configure LUN via zfs command ?
Cyril Plisko wrote:
On 11/1/06, Dick Davies [EMAIL PROTECTED] wrote:
On 01/11/06, Dick Davies [EMAIL PROTECTED] wrote:
And we'll be able to use sparse zvols
for this too (can't think why we couldn't, but it'd be dead handy)?
Thinking about this, we won't be able to (without some changes) -
Spencer Shepler wrote:
On Wed, Adam Leventhal wrote:
On Wed, Nov 01, 2006 at 01:17:02PM -0500, Torrey McMahon wrote:
Is there going to be a method to override that on the import? I can see
a situation where you want to import the pool for some kind of
maintenance procedure but you
On Wed, Nov 01, 2006 at 04:00:43PM -0500, Torrey McMahon wrote:
Lets say server A has the pool with NFS shared, or iSCSI shared,
volumes. Server A exports the pool or goes down. Server B imports the pool.
Which clients would still be active on the filesystem(s)? The ones that
were mounting
Adam Leventhal wrote:
On Wed, Nov 01, 2006 at 04:00:43PM -0500, Torrey McMahon wrote:
Lets say server A has the pool with NFS shared, or iSCSI shared,
volumes. Server A exports the pool or goes down. Server B imports the pool.
Which clients would still be active on the filesystem(s)? The ones
Cyril Plisko wrote:
Can we do something similar to NFS case, where sharenfs can be
on, off, or something else, in which case it is a list of options ?
Would this technique be applicable to shareiscsi too ?
Absolutely. We would, however, like to be conservative about adding
options
only
Richard Elling - PAE wrote:
Adam Leventhal wrote:
On Wed, Nov 01, 2006 at 04:00:43PM -0500, Torrey McMahon wrote:
Lets say server A has the pool with NFS shared, or iSCSI shared,
volumes. Server A exports the pool or goes down. Server B imports the
pool.
Which clients would still be
Adam Leventhal wrote:
On Wed, Nov 01, 2006 at 09:58:12AM +, Darren J Moffat wrote:
iscsioptions
This property, which is hidden by default, is used by the iSCSI
target
daemon to store persistent information such as the IQN. The contents
are not intended for users or
Rick McNeal wrote:
Looking at the code it doesn't seem like the backing store being zeroed.
In case of regular file a single sector (512 byte) of uninitialized
data from
stack (bad practice ?) is written to the very end of the file. And in
case
I hang my head in shame. I've fixed the code.
On 01/11/06, Rick McNeal [EMAIL PROTECTED] wrote:
I too must be missing something. I can't imagine why it would take 5
minutes to online a target. A ZVOL should automatically be brought
online since now initialization is required.
s/now/no/ ?
Thanks for the explanation. The '5 minute online'
30 matches
Mail list logo
