I forgot to sent this to the list for everyone, not just the spooks who tapped the line ;-)
On 06/21/2018 01:51 PM, Norman Feske wrote:
Hi Guido,
thanks for the report and the log. I have a faint suspicion.
could you please give the following image a try?
Hi Norman,
Your hunch was correct, this image runs the expand process correctly on my 'bad' stick. I ran it three times just to make sure, both in usb2 and usb3 sockets. All good.
Other news: 1. I noticed that the debian iso-download on this 06-21 image was jittery, stopping the now-counter for a second every few MBs. Is that an effect of these patches?
2. With the old (sculpt-tc) image, the debian download sometimes hang with what looked like a filesystem lockup. I could not save the config/deploy, nor exit vim. Other processes seemed unaffected. Is that lockup to be expected from the old code?
It could also have been a memory error I encountered with memtest. But that was transient. I could not pinpoint it to a single DIMM, nor did it occur any time after that. Perhaps this iron is getting old and flaky.
Anyway, thanks for the patch.
I've attached the log.
Cheers, Guido.
Hi Guido,
thanks for the prompt feedback and the thorough testing! We might update the downloadable image once we update our master branch next time.
Other news:
- I noticed that the debian iso-download on this 06-21 image was
jittery, stopping the now-counter for a second every few MBs. Is that an effect of these patches?
I don't think so. Supposing you were testing this with the RAM fs, the jittery effect may be caused by the successive expansion of the RAM file system. Each time it runs out of RAM quota, it blocks until the sculpt manager explicitly increases the quota. The current quota is displayed as capacity value of the 'ram' storage item. When it stops for a moment, you'll most likely see the value increase shortly afterward, before the download continues.
- With the old (sculpt-tc) image, the debian download sometimes hang
with what looked like a filesystem lockup. I could not save the config/deploy, nor exit vim. Other processes seemed unaffected. Is that lockup to be expected from the old code?
No. We rarely (I have seen it only twice in the last two months) observed instabilities of the rump-based file-system server. Once this happens, you may try closing the inspect window (by disabling all 'inspect' buttons), and then opening the inspect window for the ram fs (which should not be affected). Then you can inspect the '/report/log' for file-system-related error messages.
It would be cool to secure the log should encounter the problem again.
Cheers Norman
-
Guido Witmond -
Norman Feske