sys/vfs/hammer: Remove exceptional zone selection case
authorTomohiro Kusumi <kusumi.tomohiro@gmail.com>
Sun, 6 Sep 2015 13:00:07 +0000 (22:00 +0900)
committerTomohiro Kusumi <kusumi.tomohiro@gmail.com>
Thu, 24 Sep 2015 14:09:49 +0000 (23:09 +0900)
commit97358992e1db75a4e2989baafd87c0fb76ad2a31
tree02f998effab5aed4cc075a6696d5e4c83d6fd8c0
parent7ff55be9fc5f3aeb0c701de252efa020f3af854e
sys/vfs/hammer: Remove exceptional zone selection case

hammer_alloc_data() has an unusual and exceptional way to
determine data zone (i.e. LARGE_DATA or SMALL_DATA) as shown
in below (B). This commit changes that to the normal way of
selecting the data zone to use as shown in (A). It's simply
better not to use an exceptional rule when that doesn't
make any difference as explained below. Also see 901e04c7.

=====(A)
Hammer is designed to use LARGE_DATA zone for >=16KB
length data, and SMALL_DATA zone for <16KB length data.
zone = (data_len >= 16KB ? ZONE_LARGE_DATA_INDEX : ZONE_SMALL_DATA_INDEX);
=====

=====(B)
An exceptional case that doesn't follow an above rule.
zone = (data_len > 8KB ? ZONE_LARGE_DATA_INDEX : ZONE_SMALL_DATA_INDEX);
=====

hammer_alloc_data() using (B) actually doesn't make any
difference because strategy write has already rounded up the
data size to hammer's buf size if data_len is >8KB as shown
below, by the time hammer mirror write code (which is the only
caller with a record type of HAMMER_RECTYPE_DATA) allocates
blockmap space to write the original-rounded-up src data to
the dst fs.

hammer_vop_strategy_write()
> if (bio->bio_offset || ip->ino_data.size > HAMMER_HBUFSIZE)
> bytes = bp->b_bufsize;

In other words, data_len is never going to be
(data_len > 8KB && data_len < 16KB)
when hammer_alloc_data() is called with the record type
of HAMMER_RECTYPE_DATA. If that's the case (A) just works.
sbin/hammer/cmd_blockmap.c
sys/vfs/hammer/hammer_ondisk.c