On 11/21/19 5:18 PM, Dave Chinner wrote: > On Thu, Nov 21, 2019 at 10:44:44PM +0100, Pavel Reichl wrote: >> Signed-off-by: Pavel Reichl <preichl@xxxxxxxxxx> >> --- > > This is mixing an explanation about why the change is being made > and what was considered when making decisions about the change. > > e.g. my first questions on looking at the patch were: > > - why do we need to break up the discards into 2GB chunks? > - why 2GB? > - why not use libblkid to query the maximum discard size > and use that as the step size instead? Just wondering, can we trust that to be reasonably performant? (the whole motivation here is for hardware that takes inordinately long to do discard, I wonder if we can count on such hardware to properly fill out this info....) > - is there any performance impact from breaking up large > discards that might be optimised by the kernel into many > overlapping async operations into small, synchronous > discards? FWIW, I had simply suggested to Pavel that he follow e2fsprogs' lead here - afaik they haven't had issues/complaints with their 2g iteration, and at one point Lukas did some investigation into the size selection... Thanks, -Eric > i.e. the reviewer can read what the patch does, but that deosn't > explain why the patch does this. Hence it's a good idea to explain > the problem being solved or the feature requirements that have lead > to the changes in the patch.... > > Cheers, > > Dave. >
