[pve-devel] [RFC PATCH storage] pvesm export: convert dd's \r in status=progress output to \n

[Dominik Csapak]

On 1/16/25 10:21, Thomas Lamprecht wrote:
> Am 16.01.25 um 09:13 schrieb Dominik Csapak:
>>> FWIW, you could test with `-t STDERR` if the std error FD is a terminal
>>> and differ between replacing \r or not.
>>>
>> not sure if that would work here since we do quite some redirection for
>> the worker task (to be able to display + putting it in the task log at
>> the same time), but yes, I'll try that
> 
> 
>>
>>>> AFAICS there is no easy way to only do this for the task log, since
>>>> we simply pipe the output fh of the worker task to the task log fh.
>>>>
>>>> Alternatively we could patch the task log api to parse \r as newlines or
>>>> patch the yew widget toolkit to replace \r with \n.
>>> Wouldn't be one alternative also be to do that in the UI?
>> thats what i meant in that sentence. (replacing in yew widget toolkit)
> 
> Ah OK, seems I sorta skipped reading after the first half of the
> sentence, sorry.
> 
> Well, I see some merit in having this done at backend side, having some
> consistency and avoiding that other API consumer need to to such
> transformations, but it then might be worth thinking about doing it more
> generally.

I agree with it being done on the backend side, otherwise the
output lands in the tasklog and the api as a single line which is imho confusing.

> 
> I shortly looked into that (fork_worker and run_command) and I initiially
> got slightly confused, as in run_command we already do
> `print STDERR "$laststderr\n" if $laststderr;` for the case there is no
> errfunc defined, with $laststderr being a single line without any limiter
> (\r and/or \n or \b, fwiw), but that's only called if there is a errmsg
> parameter; bleh, run_command should really be reworked (or die).
> 
> So FWIW, this could be also "fixed" by passing something like
> errmsg => "failed to write file '$file'" ... <.<

I find it weird behaviour of run_command do do that kind of output
transformation with a more or less "unrelated" option?
Shouldn't that transformation happen always or never? (or with
an explicit option?)

Anyway would you prefer this approach to the manual errfunc?
Would still warrant a comment IMHO since one might optimize
the option away in the future without noticing it's there for
the transformation...

> 
> Another completely different option, skip DD and do the write ourself,
> might be even be done relatively easily with the sendfile syscall in
> a loop of 64K blocks and some output every few seconds, i.e. not
> totally trivial, but also not _that_ hard, just mentioning for sake
> of completeness, even if we want to go in that direction we can employ
> transforming the \r to \n as a stop gap.

Also thought about something like this, Advantage would be that we're in control
of the output and could more easily integrate that into a (potential future) feature
where tasks can have meta info like percentage done/stages/etc.

I'd still probably do the transformation fix now (one way or another) and
look into how we can maybe more generalize such "streaming" commands away,
that maybe also does format conversion (instead of qemu-img) and other exports
(rbd/zfs/lvm?) as well? (Writing this, I'm noticing this easily becomes
a much larger change/feature than what I was trying to fix though :P)

I'm happy to do any of these, just let me know what you'd prefer.