On Thu, Oct 25, 2018 at 5:08 PM Eric Sandeen <sandeen@xxxxxxxxxxx> wrote:
> On 10/23/18 10:10 AM, Eric Sandeen wrote:
> > On 10/11/18 2:44 PM, Stefan Ring wrote:
> >> The processing for data zeroing was never added to process_multi_fsb_objects.
> >> It is now the same thing that process_single_fsb_objects does.
> >
> > First, thanks for doing this, seems about right.
> >
> > But I could use more changelog words here. ;)
> >
> > AFAICT, the intent was for process_multi_fsb_objects to call
> > process_dir_data_block() in order to handle the zeroing for multi-fsb
> > objects, so at least some of the cases /were/ handled, right?
> >
> > Your patch seems to be splitting that 3 ways, so we go to
> > process_dir_free_block or process_dir_leaf_block or process_dir_data_block,
> > the first two are new cases that are now handled? (I do see that this is
> > the same as the process_single_fsb_objects code.)
> >
> > Given the old case:
> >
> > if ((!obfuscate && !zero_stale_data) ||
> > o >= mp->m_dir_geo->leafblk) {
> > ret = write_buf(iocur_top);
> >
> > it looks like we were just directly writing the leaf blocks and
> > never obfuscating them, is that correct? I guess I need to go make
> > some test filesystems... do you know from your testing if this is true?
>
> Whoops, I forgot what directory leaf blocks were, sorry - there is nothing
> to obfuscate in them. (but there may be data to zero in them...)
I really could not make sense of your previous response, but I'll look
over it once again anyway.
