[Cluster-devel] [PATCH v3 5/8] gfs2: Implement iomap buffered write support

Andreas Grünbacher andreas.gruenbacher at gmail.com
Fri Apr 6 15:15:30 UTC 2018


2018-04-06 16:44 GMT+02:00 Bob Peterson <rpeterso at redhat.com>:
> Hi,
>
> ----- Original Message -----
> (snip)
>> +static int gfs2_iomap_begin_write(struct inode *inode, loff_t pos, loff_t
>> length,
>> +                               unsigned flags, struct iomap *iomap)
> (snip)
>> +{
>> +     struct metapath mp = { .mp_aheight = 1, };
>> +     struct gfs2_inode *ip = GFS2_I(inode);
>> +     struct gfs2_sbd *sdp = GFS2_SB(inode);
>> +     unsigned int data_blocks = 0, ind_blocks = 0, rblocks;
>> +     bool unstuff, alloc_required;
>> +     int ret;
>> +
>> +     ret = gfs2_write_lock(inode);
>> +     if (ret)
>> +             return ret;
>> +
>> +     unstuff = gfs2_is_stuffed(ip) &&
>> +               pos + length > gfs2_max_stuffed_size(ip);
>> +
>> +     ret = gfs2_iomap_get(inode, pos, length, flags, iomap, &mp);
>> +     if (ret)
>> +             goto out_release;
>> +
>> +     alloc_required = unstuff || iomap->type != IOMAP_MAPPED;
>> +
>> +     if (alloc_required || gfs2_is_jdata(ip))
>> +             gfs2_write_calc_reserv(ip, iomap->length, &data_blocks, &ind_blocks);
>
> It would be ideal if the iomap_get could tell us how many blocks are mapped
> and how many are unmapped, if it wouldn't cause unnecessary IO.
> If we could use the number of unmapped blocks rather than iomap->length, it could
> potentially save us from reserving unnecessary journal space, for example, on
> rewrites (iow where the metadata for the writes already exists).
> (snip)

Yes, I'll change gfs2_iomap_get to return the number of blocks
gfs2_iomap_alloc should be able to allocate. It's a simple variant of
hole_size; the maximum will be an entire indirect block worth of data.

Thanks,
Andreas




More information about the Cluster-devel mailing list