On Thu, Oct 26, 2017 at 11:33 AM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
> From: Dave Chinner <dchinner@xxxxxxxxxx>
>
> Now that we have persistent usable block counts, we need to be able
> to change them. This allows us to control thin provisioned
> filesystem space usage at the filesystem level, not the block device
> level.
>
> If the grow operation grows the usable space beyond the current
> LBA size of the filesystem, then we also need to physically grow the
> filesystem to match the new size of the underlying device. Hence
> grow behaves like it always has, expect for the fact that it wont'
> grow physically until usable space would exceed the LBA size.
>
> Being able to modify usable space also allows us to shrink the
> filesystem on thin devices as easily as growing it. We simply reduce
> the usable space and the free space, and we're done. The user then
> needs to run a fstrim pass to ensure all the unused space in the
> filesystem LBA is marked as unused by the underlying device. No data
> or metadata movement is required as the underlying LBA space has not
> changed.
>
> Signed-Off-By: Dave Chinner <dchinner@xxxxxxxxxx>
With this change, behavior of userspace program that tried to shrink filesystem
size will change from -EINVAL to success for filesystems that were configured
to allow that. But unmodified userspace program may still be caught by surprise
from this success return code that was never excersized in the past.
I have also argued elsewhere that the fact that the request to shrink the
"virtual" size vs. physical size is implicit and not explicit, that would hinder
future attempts to use the API as it was intended to implement physical shrink.
Suggestion:
Let userspace opt-in for the new "virtual grow" API by using the 3 upper
bytes in (struct xfs_growfs_data){.imaxpct}.
Those byes are guarantied to be zeroed by old application due to value
range check in current code, so there is plenty of room to add flags byte
and use it to request to grow USABLE_DBLOCK explicitly.
All the logic in your code stays the same (i.e. grow physical to accomodate
for growing virtual) only we stir away from being called by old apps by
mistake.
Cheers,
Amir.
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
