Matthew Ahrens wrote:> Ross Newell wrote:
>> What are this issues preventing the root directory being stored on
>> raidz?
>> I''m talking specifically about root, and not boot which I can
see
>> would be
>> difficult.
>>
>> Would it be something an amateur programmer could address in a
>> weekend, or
>> is it more involved?
>
> I believe this used to work with the old "zfs mountroot" setup
with
> boot-from-UFS then root-on-ZFS. So, you could probably hack it back
> in, or just use the old bits. Lin or Lori could probably provide more
> details, or correct me...
>
>
If you''re using pre-build 62 bits, and the old
manual setup procedure documented in
http://blogs.sun.com/tabriz/entry/are_you_ready_to_rumble
a raidz pool can be used for booting.
The zfs booter, in the current implementation, expects
to find these critical files:
/boot/grub/menu.lst
/platform/i86pc/boot_archive
/platform/i86pc/kernel/unix
in a dataset in a zfs pool and it can only access one
disk, so all of those files (and all blocks in those
files) need to be accessible on that disk. If the pool
is constructed of mirrored disks, that''s OK, because
every disk in the mirror has ALL of the blocks for
every file in the pool. But if the pool is a RAID-Z
pool, the blocks will be distributed over multiple
disks and so the booter can''t find them all.
The reason RAID-Z worked in the older implementation
is that the system wasn''t really booted off zfs. It was
booted from a ufs file system, and then a zfs dataset
was mounted as root. That was useful as a prototype,
but not optimal for the long run because it required
a separate slice to be allocated for the ufs boot file system.
Ultimately, we expect to support booting from RAID-Z
by implementing some kind of "replicate on all devices
in the pool" option for bootable datasets. But that
option doesn''t exist yet and it''s a ways down on the
priority list at this time.
Lori