On 2012-11-29 16:16, Sebastian Gabler wrote:
Hi Jim,
thanks for the information.
You're welcome :)
I managed to set up 4 partitions on the disk with fdisk:
Total disk size is 3116 cylinders Cylinder size is 12544 (512 byte)
blocks
Cylinders Partition Status Type Start End Length %
========= ====== ============ ===== === ====== === 1
Solaris2 1 779 779 25 2 Solaris2
780 1558 779 25 3 Solaris2 1559 2336
778 25 4 Solaris2 2337 3114 778 25
So, this is an MBR table. With GPT/EFI "fdisk" would likely show a
trivial table like this:
Total disk size is 7832 cylinders
Cylinder size is 16065 (512 byte) blocks
Cylinders
Partition Status Type Start End Length %
========= ====== ============ ===== === ====== ===
1 EFI 0 7832 7833 100
...and "format/partition/print" would detail thus:
Total disk sectors available: 125812701 + 16384 (reserved sectors)
Part Tag Flag First Sector Size Last Sector
0 usr wm 256 59.99GB 125812701
1 unassigned wm 0 0 0
2 unassigned wm 0 0 0
3 unassigned wm 0 0 0
4 unassigned wm 0 0 0
5 unassigned wm 0 0 0
6 unassigned wm 0 0 0
8 reserved wm 125812702 8.00MB 125829085
Now, in /dev/rdsk and /dev/dsk, I see:
# ls -sh /dev/dsk/ | grep c3t31d0p
512 c3t31d0p0
512 c3t31d0p1
512 c3t31d0p2
512 c3t31d0p3
512 c3t31d0p4
>
So, there are 5 Partitions. I
am not sure which or if any count, and I have not found a way to
verify that each of the Partitions is about 4 GB.
As I wrote, "p0" is the partition table (whole disk's header), and the
p1-p4 are your data partitions.
As for the sizes, you can calculate from data shown by fdisk above,
or look at slice-2's size in "format" below.
Your partitions here are 777 cylinders in size, with each cylinder
being 12544*512 bytes = 6.125Mb (according to fdisk); your partition
sizes amount to 4759Mb=4.65Gb each (in power-of-two sizing of Mb).
partition print says
partition> print Current partition table (original): Total disk
cylinders available: 777 + 2 (reserved cylinders)
Part Tag Flag Cylinders Size Blocks 0
unassigned wm 0 0 (0/0/0) 0 1
unassigned wm 0 0 (0/0/0) 0 2
backup wu 0 - 776 4.65GB (777/0/0) 9746688 3
unassigned wm 0 0 (0/0/0) 0 4
unassigned wm 0 0 (0/0/0) 0 5
unassigned wm 0 0 (0/0/0) 0 6
unassigned wm 0 0 (0/0/0) 0 7
unassigned wm 0 0 (0/0/0) 0 8
boot wu 0 - 0 6.12MB (1/0/0) 12544 9 unassigned
wm 0 0 (0/0/0) 0
Being "Solaris" partitions, these are likely labelled with a slice
table. But you can only access one Solaris slice table on your disk,
with the x86 default layout shown above.
I am still confused how to proceed further.
I hope that you can use these partitions as your pool components, i.e.
# zpool add mypool log c3t31d0p1
It MAY be possible that ZFS would refuse this, at least on some builds;
in this case (or in any case) it might be a safer bet to create a single
MBR partition spanning the whole disk and several 4.6Gb slices inside
it (skipping the number 2), and then use these slices for log devices:
# zpool add mypool log c3t31d0s1
If you do manage to add some log devices before such reorganization of
the disk layout, be sure to remove these devices from pools first.
And be extra careful to use the keywords (like "log" or "cache", as
appropriate) when adding devices to pools - otherwise you risk extending
the pool size itself with a new top-level component, especially if you
use "force" for any reason - and top-level components can not be
removed.
Anyhow, if at all possible - do back up your data before trying this all :)
WBR,
Sebastian
Am 29.11.2012 13:47, schrieb
[email protected]:
------------------------------ Message: 7 Date: Thu, 29 Nov 2012
13:47:04 +0100 From: Jim Klimov <[email protected]> To:
[email protected] Subject: Re:
[OpenIndiana-discuss] slicing a disk for ZIL Message-ID:
<[email protected]> Content-Type: text/plain;
charset=ISO-8859-1; format=flowed On 2012-11-29 12:43, Sebastian
Gabler wrote:
I have bought and installed an Intel SSD 313 20 GB to use as
ZIL for
one
or many pools. I am running openindiana on a x86 platform, no
SPARC. As 4 GB should suffice, I am considering to partition
the drive in
order to
assign each partition to one pool (ATM pools are 2 on the
Server, but I could expand it in the future) After some
reading, I am still confused about slicing and partitioning.
What do I actually need to do to achieve the wanted effect to
have
up to
4 partions on that SSD?
Well, basically you need to partition the SSD:)
There are several options available: 1) Use MBR (MSDOS Boot Record)
traditional partitions - up to four primary partitions, one (or
more?) of which can allocate a range as a secondary (or extended)
partition and store more parts there.
In this case you would address your zfs "log" devices as cXtYdZpN.
In case of IDE connection (which you don't want) you see cXdZpN.
Here "N" is the partition number, with "0" being the partition
table/whole disk itself, so your logs would be N=1,2,3,4 if you
only use primary partitions (the whole disk should be divided
between them, then. Extended partitions are addressed at N=5..15.
2) Use MBR with Solaris slices - define a "Solaris" partition in
MBR using the whole disk, and define Solaris slices inside. Note
that slice #2 is reserved as traditional "whole disk" for backup
tools. It may cause zfs tools to report conflicts (slice overlaps),
but you can ignore them.
In this case your zfs "log" devices would be cXtYdZsN, with N
being the slice number (0..7, 2 is reserved but can be reused if
required).
AFAIK you can't define more than one Solaris slice set on one HDD,
though you can use other partitions for other filesystems. Maybe
you can mix slices and partitions as components for the pool and
its log/cache devices, but I won't bet on this.
3) Use a GPT (GUID Partition Table, maybe aka "EFI") partitioning
table. There you explicitly define many partitions, all primary,
that can be used by your pools and their components (logs/caches).
I think, Solaris "format" utility detects a GPT table and uses (and
displays) those partitions in place of slices for traditional
MBR+slice tables. I.e. with GPT you don't have slices, and usually
don't need to - you can have many more GPT partitions than slices.
When you dedicate a whole disk to ZFS to use in a non-root pool, it
essentially makes a GPT table with an 8Mb reserved tail partition
and the rest is a ZFS partition.
As of now, the GPT-tabled disks can not be used for bootable root
pools with Solaris-derived OSes (maybe usable with other distros
and another GRUB in particular).
I think you can not use separate ZIL with root pools - for mostly
the same reasons only mirrors/single disks are allowed (the single
device passed from BIOS/bootloader must be sufficient to boot the
OS image). Maybe you can attach an L2ARC cache to an rpool,
though.
Also note that when using a sliced/partitioned disk with ZFS, you
might need to ensure that disk caching is on for this device. This
can be scripted as a bootup init-script calling "format", if
required. I think I or Edward Ned Harvey published variants of such
scripts in zfs-discuss mailing list this year.
Finally, you can use "(g)parted" and/or "fdisk" utilities to label
a disk as having a particular table and its contents. For slices
or partitions accessible to Solaris, and to configure some options
like cache, you further use "format" utility and follow its text
menu.
HTH, //Jim Klimov
------------------------------
_______________________________________________ OpenIndiana-discuss
mailing list [email protected]
http://openindiana.org/mailman/listinfo/openindiana-discuss
_______________________________________________ OpenIndiana-discuss
mailing list [email protected]
http://openindiana.org/mailman/listinfo/openindiana-discuss
--
+============================================================+
| |
| Климов Евгений, Jim Klimov |
| технический директор CTO |
| ЗАО "ЦОС и ВТ" JSC COS&HT |
| |
| +7-903-7705859 (cellular) mailto:[email protected] |
| CC:[email protected],[email protected] |
+============================================================+
| () ascii ribbon campaign - against html mail |
| /\ - against microsoft attachments |
+============================================================+
_______________________________________________
OpenIndiana-discuss mailing list
[email protected]
http://openindiana.org/mailman/listinfo/openindiana-discuss
