>
> > For a RaidZ, when data is written to a disk, are
> individual 32k join together to the same disk and
> written out as a single I/O to the disk?
>
> I/Os can be coalesced, but there is no restriction as
> to what can be coalesced.
> In other words, subsequent writes can also be
> coalesced i
On Mar 9, 2010, at 6:13 PM, Damon Atkins wrote:
> Sorry, Full Stripe on a RaidZ is the recordsize ie if the record size is 128k
> on a RaidZ and its made up of 5 disks, then 128k is spread across 4 disks
> with the calc parity on the 5 disk, which means the writes are 32k to each
> disk.
Nomin
Sorry, Full Stripe on a RaidZ is the recordsize ie if the record size is 128k
on a RaidZ and its made up of 5 disks, then 128k is spread across 4 disks with
the calc parity on the 5 disk, which means the writes are 32k to each disk.
For a RaidZ, when data is written to a disk, are individual 32k
I am talking about having a write queue, which points to ready to write, full
stripes.
Ready to write full stripes would be
*The last byte of the full stripe has been updated.
*The file has been closed for writing. (Exception to the above rule)
I believe there is now a scheduler for ZFS, to han
On Sun, 7 Mar 2010, Damon Atkins wrote:
The example below shows 28 x 128k writes to the same file before
anything is written to disk and the disk are idle the entire time.
There is no cost to writing to disk if the disk is not doing
anything or is under capacity. (Not a perfect example)
Zfs
I think ZFS should look for more opportunities to write to disk rather than
leaving it to the last second (5seconds) as it appears it does. e.g.
if a file has record size worth of data outstanding it should be queued within
ZFS to be written out. If the record is updated again before a txg, the