Hi Dave,
Sarah,
Continuing my piecemeal review. Today, it's 6.3 Target Schema.
I see you got a lot of comments here about partition/vdev/slice stuff
so I've confined it to some other items.
- Is the is_root attribute really right at the target level? It seems
to me like it's a pool attribute. What happens if I have multiple
targets with this set to true?
Yes, it should be a zpool attribute. I will move this.
- Similar to discussion on Software schema, will you be removing the
"unknown" from the disk name attribute?
Yes, I removed this.
- Isn't the is_logical attribute of a partition implied by the name
(and therefore redundant)?
Yes, it is in my schema. But, that is an interesting question. Right now
I have the partition name as required, but if the user doesn't want to
specify the name but wants to give other data about the partition that
allows us to create it, either physical or logical, is this something we
want to enable? In AI today we don't require the name. We can create it
based on other attributes.
- Is it really a good idea to default the size_units to gb? In 10
years, that's going to seem so 00's. What about just dispensing with
the separate units attribute and requiring units suffixed to the size
(i.e. 100gb, 2secs, 2tb)? I feel like that might be more comfortable
to the average admin and hold up better over the long term.
Fair point. I will change this to your suggestion.
- Should there be a comment about the format options are expected to be?
The idea is that options shouldn't be set in terms of format. Zpool,
zvol, dataset have a form to the options that are possible, so I could
give a comment about these specifically. But, if the format of the
options changes I want the schema to handle this.
Several things about swap/dump:
- What scope are swap and dump specified under? I don't see any other
reference to them in the schema, so they seem somewhat disconnected.
Maybe that's OK, but the examples didn't show them so I'm kind of
wondering.
They are a target, not a target_device. So, it would look like:
<target>
<swap>
<zvol action="create" name="rpool/swap>
<size>1024mb</size>
</zvol>
</swap>
</target>
The scope of a swap or dump device is global and not specific to a pool.
- Should we have an "automatic" specification for swap/dump (in other
words, use the algorithm that the interactive installers use), or is
its absence expected to imply automatic behavior in AI? If that's the
case, do we need a "none" to disable their creation?
No, we don't need a none. Since this is a subelement of the target
element and not required, their absence means we default to calculating
it. If specified we use the values specified.
- The comment about swap and dump should be more specific that merely
specifying size would create them with a specific name on the (first?
per comment above) root pool.
Yes, I agree. It should be more specific. What I am saying is that if a
size is given, we will create swap in the root pool, otherwise if zvol
data is given we will use that zvol.
- I assume we can specify multiple swap devices?
No, not as I currently have it specified. I can modify this to allow for
multiple swap devices.
- Doesn't seem to be any way to specify swapping on a slice. We do
this in some cases currently, though, and right now the pathological
behavior of ZFS swap when exhausted makes it even preferable.
I thought that swap had to be on a zfs zvol moving forward. I can
certainly change this spec to allow for specifying a slice as one of the
possibilities. What about using a slice for a dump device?
- Wouldn't it make sense to model iscsi as a target_device type?
Yes, it would. Not sure why I didn't do that :-). I will move this as a
target device.
thanks,
sarah
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
