Btrfs devel - Jan 2010 - What's the benefit of COW without checksum?

Hi Chris,
According to my understanding, COW in Btrfs services for 1) snapshots
capacities 2) keeping checksum consistent with FS data,
that''s why nodatacow implies nodatasum. And COW will still happen for
snapshots even under ''nodatacow''.

So could you please tell me what can we get from COW if not computing
checksum (nodatasum)? That''s to say, if some user decides to
disable checksum, do you think it''s fine for him to just mount with
''nodatacow''? Or there''s still some reason for him to
use bare
''nodatasum''?

Thanks & Regards,
Zhu Yanhai

(Resent it again as the previous one was rejected by mailing list for
its contained HTML subpart)
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Tue, Jan 26, 2010 at 03:15:08PM +0800, Zhu Yanhai
wrote:
>    Hi Chris,
>    According to my understanding, COW in Btrfs services for 1) snapshots
>    capacities 2) keeping checksum consistent with FS data,
>    that''s why nodatacow implies nodatasum. And COW will still
happen for
>    snapshots even under ''nodatacow''.
> 
>    So could you please tell me what can we get from COW if not computing
>    checksum (nodatasum)? That''s to say, if some user decides to
>    disable checksum, do you think it''s fine for him to just mount
with
>    ''nodatacow''? Or there''s still some reason for
him to use bare ''nodatasum''?
COW does have advantages in some workloads, basically where you end up
putting fresh data modifications close to each other.  This is
especially true on some ssds that work best when writing large groups of
contiguous data.

Mail server workloads often benefit from cow as well.  Especially with
the intel crc32c extensions, the checksumming is becoming less and less
expensive on modern hardware.  I don''t expect many people to turn it
off.

nodatacow on the other hand has a big impact on database workloads.  The
random over-write performance goes down significantly when cow is on
because the extents become very small and the amount of metadata needed
to track them becomes very large. 

So, nodatacow is likely to be used often, while nodatasum is probably
only going to be used by people trying to figure out how big the impact
of checksumming is on performance.

-chris

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

I''m using btrfs for a distribution specialized to be used with USB pen
drives.

btrfs ist the first file system (besides nilfs) that is fast enough to be used
with media (flash memory) that has a severe restriction on the number of writes
per second (to be more precise: the number of page deletes per second).

Until now I had to use a layered approached using some kind of union file
system and a ramdisk as the top level layer.

I first testet btrfs last June when it entered the official kernel. At
that time is was much to slow to be used in the described scenario. But the
speedups during the last months made its use possible! :-)

So lots of thanks to Chris Mason and all others who brought us such a
groundbreaking file system. They have done a great piece of work. Yet
there''s
still a lot to be done, but I''m optimistic that we will end up with a
very well
designed file system useable for lots of different application scenarios.

Greetings, Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html