On Tue, February 20, 2018 4:33 pm, Momchil Ivanov wrote: > On Tue, February 20, 2018 3:42 pm, Marian Marinov wrote: >> Предложението ти не е лошо, но е в пъти по-сложно и за съжаление ще >> hit-ва >> сериозно write performance-а за клиента. >> Замисли се, вместо директно да почнеш да пишеш на диска, първо ще се >> случва write със същата големина :( > > На пръв поглед това даже се случва като си избереш > > LV Zero new blocks yes > > погледни например [1] и по специално [2]. Предпологам трябва да се > разгледа по-подробно за да се види дали става навсякъде където трябва. > > 1: > https://elixir.bootlin.com/linux/latest/source/drivers/md/dm-thin.c#L1248 > 2: > https://elixir.bootlin.com/linux/latest/source/drivers/md/dm-thin.c#L1310 > > Поздрави, > Момчил >
Хм, това нещо ми показва друг код като го отварям през лаптопа, странна работа. Става въпрос за следното парче код от drivers/md/dm-thin.c /* * A partial copy also needs to zero the uncopied region. */ static void schedule_copy(struct thin_c *tc, dm_block_t virt_block, struct dm_dev *origin, dm_block_t data_origin, dm_block_t data_dest, struct dm_bio_prison_cell *cell, struct bio *bio, sector_t len) { int r; struct pool *pool = tc->pool; struct dm_thin_new_mapping *m = get_next_mapping(pool); m->tc = tc; m->virt_begin = virt_block; m->virt_end = virt_block + 1u; m->data_block = data_dest; m->cell = cell; /* * quiesce action + copy action + an extra reference held for the * duration of this function (we may need to inc later for a * partial zero). */ atomic_set(&m->prepare_actions, 3); if (!dm_deferred_set_add_work(pool->shared_read_ds, &m->list)) complete_mapping_preparation(m); /* already quiesced */ /* * IO to pool_dev remaps to the pool target's data_dev. * * If the whole block of data is being overwritten, we can issue the * bio immediately. Otherwise we use kcopyd to clone the data first. */ if (io_overwrites_block(pool, bio)) remap_and_issue_overwrite(tc, bio, data_dest, m); else { struct dm_io_region from, to; from.bdev = origin->bdev; from.sector = data_origin * pool->sectors_per_block; from.count = len; to.bdev = tc->pool_dev->bdev; to.sector = data_dest * pool->sectors_per_block; to.count = len; r = dm_kcopyd_copy(pool->copier, &from, 1, &to, 0, copy_complete, m); if (r < 0) { DMERR_LIMIT("dm_kcopyd_copy() failed"); copy_complete(1, 1, m); /* * We allow the zero to be issued, to simplify the * error path. Otherwise we'd need to start * worrying about decrementing the prepare_actions * counter. */ } /* * Do we need to zero a tail region? */ if (len < pool->sectors_per_block && pool->pf.zero_new_blocks) { atomic_inc(&m->prepare_actions); ll_zero(tc, m, data_dest * pool->sectors_per_block + len, (data_dest + 1) * pool->sectors_per_block); } } complete_mapping_preparation(m); /* drop our ref */ } и съответната документация от lvmthin(7): Zeroing When a thin pool provisions a new data block for a thin LV, the new block is first overwritten with zeros. The zeroing mode is indicated by the "z" attribute displayed by lvs. The option -Z (or --zero) can be added to commands to specify the zeroing mode. Command to set the zeroing mode when creating a thin pool LV: lvconvert --type thin-pool -Z{y|n} --poolmetadata VG/ThinMetaLV VG/ThinDataLV Command to change the zeroing mode of an existing thin pool LV: lvchange -Z{y|n} VG/ThinPoolLV If zeroing mode is changed from "n" to "y", previously provisioned blocks are not zeroed. Provisioning of large zeroed chunks impacts performance. lvm.conf(5) thin_pool_zero controls the default zeroing mode used when creating a thin pool. _______________________________________________ Lug-bg mailing list Lug-bg@linux-bulgaria.org http://linux-bulgaria.org/mailman/listinfo/lug-bg