git: sys/vfs/hammer: Remove exceptional zone selection case

Tomohiro Kusumi tkusumi at
Thu Sep 24 07:46:33 PDT 2015

commit 97358992e1db75a4e2989baafd87c0fb76ad2a31
Author: Tomohiro Kusumi <kusumi.tomohiro at>
Date:   Sun Sep 6 22:00:07 2015 +0900

    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.
    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);
    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.
    > 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.

Summary of changes:
 sbin/hammer/cmd_blockmap.c     | 10 ----------
 sys/vfs/hammer/hammer_ondisk.c | 25 ++++++-------------------
 2 files changed, 6 insertions(+), 29 deletions(-)

DragonFly BSD source repository

More information about the Commits mailing list