<div id="geary-body" dir="auto"><div><div>Dear all, </div><div><br></div><div>one more question related to ZFS-buffers in Lustre.</div><div><br></div><div>There is a function osd_grow_blocksize(obj, oh, ...) called after the fist portion of data (first rnb?) </div><div>has been committed to ZFS.</div><div>There are some restrictions for block size changing:</div><div>dmu_object_set_blocksize says:</div><div>The object cannot have any blocks allcated beyond the first. If</div><div>* the first block is allocated already, the new size must be greater</div><div>* than the current block size.</div><div>and later on</div><div>/*</div><div> * Try to change the block size for the indicated dnode.  This can only</div><div> * succeed if there are no blocks allocated or dirty beyond first block</div><div> */ </div><div><br></div><div>I am now interested on the frist block's size, which seems to be set when creating the dnode.</div><div>This size comes from ZFS and is something like</div><div>dnp->dn_datablkszsec << SPA_MINBLOCKSHIFT or SPA_MINBLOCKSIZE (not sure).</div><div><br></div><div>I would like to specify this size on Lustre's side, not just take what ZFS offers.</div><div>E.g. make the first block 128K instead of 4K.</div><div>Is it possible? Could I just overwrite the block size before the corresponsing memory for the block is allocated?</div><div><br></div><div>I am not able to call osd_grow_blocksize for the first block, since I do not have any thread context there, not yet.</div><div>Do I need to grab into dnode_allocate and dnode_create?</div><div><br></div><div>And for better understanding, does one dnode always represent one lustre object?</div><div><br></div><div>I would be greatful for any suggestions.</div><div><br></div><div>***</div><div><br></div><div>Some context for my questions:</div><div><br></div><div>I have compressed data chunks coming from the Lustre client. I want to hand them over to ZFS like they</div><div>were compressed by ZFS. ZFS offers some structures, e.g. compressed arc-buffers, which know how the data has been </div><div>compressed (which algo, physical and logical sizes). I want and need my chunks to be aligned to the records (arc buffers).</div><div>We have already extended the interfaces of the internal ZFS compression structures. But currently ZFS (or osd-zfs) first defines</div><div>the sizes of buffers and the data is put in there. In my case, the data should "dictate" how many buffers there are and how large they can be.</div><div><br></div><div>Best regards</div><div>Anna</div></div><div><br></div><div>--</div><div>Anna Fuchs</div><div>Universität Hamburg</div></div><div id="geary-quote" dir="auto"><br>On Thu, Jun 13, 2019 at 1:54 PM, Anna Fuchs <anna.fuchs@informatik.uni-hamburg.de> wrote:<br><blockquote type="cite"><div id="geary-body" dir="auto"><div>Dear all,</div><div><br></div><div>in osd-zfs/osd_io.c:osd_bufs_get_write you can find a comment regarding zerocopy:</div><div><br></div><div><div><span class="Apple-tab-span" style="white-space:pre">        </span>/*</div><div><span class="Apple-tab-span" style="white-space:pre">   </span> * currently only full blocks are subject to zerocopy approach:</div><div><span class="Apple-tab-span" style="white-space:pre">      </span> * so that we're sure nobody is trying to update the same block</div><div><span class="Apple-tab-span" style="white-space:pre">      </span> */</div></div><div><br></div><div>Whenever a block to be written is full, an arc buffer is requested, otherwise alloc_page.</div><div><br></div><div>I do not really understand the conclusion. Why and how do full blocks prevent updates?</div><div>And put it differently - why not to try zerocopy for not full blocks?</div><div>What could happen if I tried to request an arc buffer for e.g. a block with missin
 g last page?</div><div><br></div><div>I would be greateful for details.</div><div>Best regards</div><div>Anna</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div></blockquote></div>