Instead of replying to each of the messages I'll just reply to the last,
but answer the questions that each of the three have raised.
Dick Davies wrote:
On 01/11/06, Cyril Plisko <[EMAIL PROTECTED]> 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) -
> I think a target is zero-filled before going online
> (educated guess: it takes 5 minutes to 'online' a target,
> and it consumes virtually no space in the parent zvol if compression
is on),
> so a sparse zvol would exhaust zpool space.
I should change the code and look to see if the backing store is a
character device. If so, there's no need to initialize the backing store
to verify that the space is available.
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.
of character device it isn't written at all. zvol should fall into
char device
category. See mgmt_create.c::setup_disk_backing()
Or did I miss something ?
The routine that you're looking at is primarily dealing with the
condition when the administrator has provided a backing store. The code
that you're looking provides the ability to specify a backing store that
doesn't exist, but a size must also be given.
At the end of create_lun() there's a call to create_lun_common(), not
very original and a little misleading. create_lun_common() starts the
thread which initializes the backing store. This is done for disk and
tapes, but not for raw devices. I'm going to change create_lun_common()
to ignore backing store which points at character devices.
I'm not the one to ask :)
I'm just saying what I've seen - it was SXCR b49, and a ZFS
filesystem, not a zvol as I said (seems iscsi targets are file backed
by default). Still took a few minutes to online a new target, so it was
doing
something, but I don't know what.
The daemon does use regular files by default. This was done to make the
daemon as flexible as possible.
When using regular files the daemon must zero fill the backing store so
that initiators will not get a write error because the underlying file
system has filled up. The daemon is able to create logical units that
are hole-y files, but doing so requires a special XML tag to be added.
I've been thinking about adding this as an option to the CLI if enough
folks would find it useful.
Hope this helps.
If it's a non-issue that'd be great,
--
----
Rick McNeal
A good friend will come and bail you out of jail...but, a true
friend will be sitting next to you saying, "Damn...that was fun!"
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
