jan damborsky wrote:
Hi Lori,
Lori Alt wrote:
Richard Elling wrote:
Hi Jan, comments below...
jan damborsky wrote:
Hi folks,
I am member of Solaris Install team and I am currently working
on making Slim installer compliant with ZFS boot design specification:
http://opensolaris.org/os/community/arc/caselog/2006/370/commitment-materials/spec-txt/
After ZFS boot project was integrated into Nevada and support
for installation on ZFS root delivered into legacy installer,
some differences occurred between how Slim installer implements
ZFS root and how it is done in legacy installer.
One part is that we need to change in Slim installer is to create
swap & dump on ZFS volume instead of utilizing UFS slice for this
as defined in design spec and implemented in SXCE installer.
When reading through the specification and looking at SXCE
installer source code, I have realized some points are not quite
clear to me.
Could I please ask you to help me clarify them in order to
follow the right way as far as implementation of that features
is concerned ?
Thank you very much,
Jan
[i] Formula for calculating dump & swap size
--------------------------------------------
I have gone through the specification and found that
following formula should be used for calculating default
size of swap & dump during installation:
o size of dump: 1/4 of physical memory
This is a non-starter for systems with 1-4 TBytes of physical
memory. There must be a reasonable maximum cap, most
likely based on the size of the pool, given that we regularly
boot large systems from modest-sized disks.
Actually, starting with build 90, the legacy installer sets the
default size of the
swap and dump zvols to half the size of physical memory, but no more
then 32 GB and no less than 512 MB. Those are just the defaults.
Administrators can use the zfs command to modify the volsize
property of both the swap and dump zvols (to any value, including
values larger than 32 GB).
Agreed - the formula [i] is mentioned in PSARC document, but
the implementation I was investigating by looking at latest
SXCE installer code is exactly what you are describing here.
Since that calculation is part of PSARC, I assumed that every
implementation of ZFS root should follow this in order to be
fully compliant with ZFS root design ?
I guess I don't consider the exact formula a "compliance" issue.
I think it's reasonable to modify the formula if you decide a change
is worthwhile.
o size of swap: max of (512MiB, 1% of rpool size)
However, looking at the source code, SXCE installer
calculates default sizes using slightly different
algorithm:
size_of_swap = size_of_dump = MAX(512 MiB, MIN(physical_memory/2, 32 GiB))
Are there any preferences which one should be used or is
there any other possibility we might take into account ?
zero would make me happy :-) But there are some cases where swap
space is preferred. Again, there needs to be a reasonable cap. In
general, the larger the system, the less use for swap during normal
operations, so for most cases there is no need for really large swap
volumes. These can also be adjusted later, so the default can be
modest. One day perhaps it will be fully self-adjusting like it is
with other UNIX[-like] implementations.
[ii] Procedure of creating dump & swap
--------------------------------------
Looking at the SXCE source code, I have discovered that following
commands should be used for creating swap & dump:
o swap
# /usr/sbin/zfs create -b PAGESIZE -V <size_in_mb>m rpool/swap
# /usr/sbin/swap -a /dev/zvol/dsk/rpool/swap
o dump
# /usr/sbin/zfs create -b 128*1024 -V <size_in_mb>m rpool/dump
# /usr/sbin/dumpadm -d /dev/zvol/dsk/rpool/dump
The above commands for creating the swap and dump zvols match
what the legacy installer does, as of build 90.
ok - Then I will use this implementation also in Slim installer.
Could you please let me know, if my observations are correct
or if I should use different approach ?
As far as setting of volume block size is concerned (-b option),
how that numbers are to be determined ? Will they be the same in
different scenarios or are there plans to tune them in some way
in future ?
There are no plans to tune this. The block sizes are appropriate
for the way the zvols are to be used.
I see - thanks for clarification.
Setting the swap blocksize to pagesize is interesting, but should be
ok for most cases. The reason I say it is interesting is because it
is optimized for small systems, but not for larger systems which
typically see more use of large page sizes. OTOH larger systems
should not swap, so it is probably a non-issue for them. Small
systems should see this as the best solution.
Dump just sets the blocksize to the default, so it is a no-op.
-- richard
[iii] Is there anything else I should be aware of ?
---------------------------------------------------
Installation should *not* fail due to running out of space because
of large dump or swap allocations. I think the algorithm should
first take into account the space available in the pool after accounting
for the OS.
The Caiman team can make their own decision here, but we
decided to be more hard-nosed about disk space requirements in the
legacy install. If the pool is too small to accommodate the recommended
swap and dump zvols, then maybe this system isn't a good candidate for
a zfs root pool. Basically, we decided that since you almost
can't buy disks smaller than 60 GB these days, it's not worth much
effort to facilitate the setup of zfs root pools on disks that are smaller
than that. If you really need to do so, Jumpstart can be used to
set the dump and swap sizes to whatever you like, at the time
of initial install.
I would agree with you as far as internal disks are concerned.
However, since Slim installer also allows to install for example
on USB sticks, which are smaller, the minimum required space might
be the issue.
Yes, there could be cases where a smaller swap and dump amount is
reasonable. It all depends on the environment in which the system is
running. I would assume that a system with a USB stick as its root
disk would not be doing the kind of computing needing lots of swap.
In your install procedure, you are free to adapt to the particular
environment
you're installing.
Do we need to create two separate volumes for swap and dump or
might be one ZFS volume enough which then would be shared by both
swap and dump ?
When swap and dump are stored in zvols, it is no longer permitted that they
share the same space (the implementation of swap and dump zvols
required special handling that make them mutually exclusive. ).
However, you could choose not to have a dump zvol at all in some
environments (the USB stick as root environment, for example), as
long as you're willing to not get crash dumps.
Lori
Thank you very much,
Jan
_______________________________________________
caiman-discuss mailing list
[EMAIL PROTECTED]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
