zfs discuss - May 2007 - Re: ZFS - Use h/w raid or not?Thoughts. Considerations.

Also the "unmirrored memory" for the rest of the system has ECC and
ChipKill, which provides at least SOME protection against random
bit-flips.

--

Question: It appears that CF and friends would make a descent live-boot
(but don''t run on me like I''m a disk) type of boot-media due
to the
limited write/re-write limitations of flash-media. (at least the
non-exotic type of flash-media)

Would something like future zfs-booting on a pair of CF-devices
reduce/lift that limitation? (does the COW nature of ZFS automatically
spread WRITES across the entire CF device?) [[ is tmp-fs/swap going to
remain a problem till zfs-swap adds some COW leveling to the swap-area?
]]

Thanks,

 -- MikeE

-----Original Message-----
From: zfs-discuss-bounces at opensolaris.org
[mailto:zfs-discuss-bounces at opensolaris.org] On Behalf Of Carson Gaspar
Sent: Tuesday, May 29, 2007 8:05 PM
To: Richard Elling
Cc: zfs-discuss at opensolaris.org; Anton B. Rang
Subject: Re: [zfs-discuss] Re: ZFS - Use h/w raid or not?Thoughts.
Considerations.


Richard Elling wrote:
> But I am curious as to why you believe 2x CF are necessary?
> I presume this is so that you can mirror.  But the remaining memory
> in such systems is not mirrored.  Comments and experiences are
welcome.

CF == bit-rot-prone disk, not RAM. You need to mirror it for all the 
same reasons you need to mirror hard disks, and then some.

-- 
Carson
_______________________________________________
zfs-discuss mailing list
zfs-discuss at opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Ellis, Mike wrote:
> Also the "unmirrored memory" for the rest of the system has ECC
and
> ChipKill, which provides at least SOME protection against random
> bit-flips.
CF devices, at least the ones we''d be interested in, do have ECC as
well as spare sectors and write verification.

Note: flash memories do not suffer from the same radiation-based
bit-flip mechanisms as DRAMS or SRAMS.  The main failure mode we
worry about is write endurance.
> Question: It appears that CF and friends would make a descent live-boot
> (but don''t run on me like I''m a disk) type of boot-media
due to the
> limited write/re-write limitations of flash-media. (at least the
> non-exotic type of flash-media)
Where we see current use is for boot devices, which have the expectation
of read-mostly workloads.  The devices also implement wear leveling.
> Would something like future zfs-booting on a pair of CF-devices
> reduce/lift that limitation? (does the COW nature of ZFS automatically
> spread WRITES across the entire CF device?) [[ is tmp-fs/swap going to
> remain a problem till zfs-swap adds some COW leveling to the swap-area?
> ]]
The belief is that COW file systems which implement checksums and data
redundancy (eg, ZFS and the ZFS copies option) will be redundant over
CF''s ECC and wear leveling *at the block level.*  We believe ZFS will
excel in this area, but has limited bootability today.  This will become
more interesting over time, especially when ZFS boot is ubiquitous.

As for swap, it is a good idea if you are sized such that you don''t
need to physically use swap.  Most servers today are in this category.
Actually, most servers today have much more memory than would fit in a
reasonably priced CF, so it might be a good idea to swap elsewhere.

In other words, it is more difficult to build the (technical) case for
redundant CFs for boot than it is for disk drives.  Real data would be
greatly appreciated.
  -- richard

On Tue, 2007-05-29 at 18:48 -0700, Richard Elling wrote:
> The belief is that COW file systems which implement checksums and data
> redundancy (eg, ZFS and the ZFS copies option) will be redundant over
> CF''s ECC and wear leveling *at the block level.*  We believe ZFS
will
> excel in this area, but has limited bootability today.  This will become
> more interesting over time, especially when ZFS boot is ubiquitous.
I suspect that an interesting config would put the boot archive and not
much else on the CF, and the "live" root and anything else that needs
regular updates in a main zfs pool on disk.  Something like the original
zfs_mountroot approach would be involved - and that allowed the pool
containing the root to exist in a fully general pool, not limited to the
zfs boot config.

That would further reduce both the size of CF required and the frequency
of updates to it..

						- Bill