On Tue, Dec 29, 2009 at 02:37:20PM -0800, Brad wrote:
> I would appreciate some feedback on what I've understood so far:
>
> WRITES
>
> raid5 - A FS block is written on a single disk (or multiple disks
depending on size data???)
There is no direct relationship between a filesystem and the RAID
structure. RAID5 maps virtual sectors to columns in some width pattern.
How the FS uses those virtual sectors is up to it. The admin may need
to know how it is to be used if there is a desire to tweak the stripe
width. This makes some comparisons difficult because RAID5 is only a
presentation and management of a set of contiguous blocks, while raidz
is always associated with a particular filesystem.
Updates to RAID5 are in-place.
> raidz - A FS block is written in a dynamic stripe (depending on size of
> data?)across n number of vdevs (minus parity).
>
The stripe may be written in as few as 1 disk for data and other disks
for parity, or the stripe may cover all the disks.
> READS
>
> raid5 - IO count depends on how many disks FS block written to. (data
> crosses two disks 2 IOs??)
Well, that's true for anything. You can't read two disks without
issuing two reads. The main issue is that RAID5 has no ability to
validate the data, so it doesn't need to read all columns. It can just
read one sector if necessary and return the data. How many disk sectors
must be retreived may depend on which filesystem is in use. But in most
cases (common filesystems, common stripe widths), a single FS block will
not be distributed over many disks.
> raidz - A single read will span across n number of vdevs (minus
parity). (1single IO??)
If not in cache, the ZFS block is read (usually only from the non-parity
components), and that block may be on many disks. The entire ZFS block
is read so that it can be validated against the checksum.
> NEGATIVES
>
> raid5 - Write hole penalty, where if system crashes in the middle of a
> write block update before or after updating parity - data is corrupt.
Assuming no other structures are used to address it (like a log
device). A log device is not really part of RAID5, but may be found in
implementations of RAID5.
> - Overhead (read previous block, read parity, update parity
and write block)
True for non-full-stripe writes. Full stripe writes need no read step
(something the raidz implementation leverages).
> - No checksumming of data!
> - Slow read sequential performance.
Not sure why sequential read performance would have a penalty under
RAID5.
--
Darren
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
