zfs discuss - Jun 2006 - What does ZFS modify a part of filesystem block?

I have some questions about modify filesystem block.

When we want to modify existing block ZFS makes new one and destroy old. OK - it
is copy-on-write
mechanism. But if we want to modify only a part of the block what does it work?

What does ZFS do with rest of the block? Whether size of it is reduce or maybe
write to new place?

Best regards,
Andrzej
 
 
This message posted from opensolaris.org

This will be handled as a read-modify-write: we will still create a new
block, with the original data from the old block, plus the modifications
and then destroy the old block.

-Mark

Andrzej Butkiewicz wrote:
> I have some questions about modify filesystem block.
> 
> When we want to modify existing block ZFS makes new one and destroy old. OK
- it is copy-on-write
> mechanism. But if we want to modify only a part of the block what does it
work?
> 
> What does ZFS do with rest of the block? Whether size of it is reduce or
maybe write to new place?
> 
> Best regards,
> Andrzej
>  
>  
> This message posted from opensolaris.org
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Thanks Mark!

I see that writing part of filesystem block reduces performance. Especially in
Raid-Z because we have to read all spread on every disk blocks. Does ZFS have
any kind of blocks aggregation?

I suppose that could be work on this way: zfs receive a command to write part of
the block, e.g. last 8kB in 32kB block. Next, instead that read-modify-write we
write modify information into the cache and wait for next modification of this
block. If any next write-command will fill all parts of the block we will could
write whole block without reading it.

Why I''m asking? I''m very interesting in which implementations
Raid-Z will have better
performance than Raid-5. And which way I must improve my applications to obtain
better
performance with ZFS? (constant writing blocks??)

Andrzej
 
 
This message posted from opensolaris.org

Andrzej Butkiewicz wrote:
> Thanks Mark!
> 
> I see that writing part of filesystem block reduces performance. Especially
in Raid-Z because we have to read all spread on every disk blocks. Does ZFS have
any kind of blocks aggregation?
> 
> I suppose that could be work on this way: zfs receive a command to write
part of the block, e.g. last 8kB in 32kB block. Next, instead that
read-modify-write we write modify information into the cache and wait for next
modification of this block. If any next write-command will fill all parts of the
block we will could write whole block without reading it.
> 
> Why I''m asking? I''m very interesting in which
implementations Raid-Z will have better
> performance than Raid-5. And which way I must improve my applications to
obtain better
> performance with ZFS? (constant writing blocks??)
If performance is really this critical to you Raid-Z is probably not the 
correct choice.

Can you actually prove that this aspect of ZFS is actually causing a 
performance problem for you or are you making assumptions ?

-- 
Darren J Moffat

On Wed, Jun 07, 2006 at 07:10:56AM -0700, Andrzej Butkiewicz
wrote:
> I suppose that could be work on this way: zfs receive a command to
> write part of the block, e.g. last 8kB in 32kB block. Next, instead
> that read-modify-write we write modify information into the cache and
> wait for next modification of this block. If any next write-command
> will fill all parts of the block we will could write whole block
> without reading it.
Yep, that pretty much describes this bug:

	5035516 Overwrites should not require synchronous reads

--matt

I''m asking only for curiosity. I would like to know more about ZFS
internals espacially comparing Raid-Z to Raid-5 and improving applications to
cooperation with them. It isn''t complaining on performance :)
 
 
This message posted from opensolaris.org