kurai

Overview webGUI can set out of spec large cookies that are breaking some functionality (notably docker VNC connectivity) Problem source https://wiki.unraid.net/Manual/Release_Notes/Unraid_OS_6.10.0#Other_Improvements The optional Network traffic graph [introduced with 6.10.0] in the INTERFACE dashboard panel stores the rolling history in two cookies: rxd-init & txd-init. The value is recorded at 1 second intervals for a history of 10s | 30s | 1min | 2min With the traffic value recorded in 14 digit precision this gives rise to cookie sizes below:- 10 sec: 2 x ~185 bytes 30 sec: 2 x ~540 bytes 1 min : 2 x ~1085 bytes 2 min : 2 x ~2155 bytes Relevance RFC 6265bis has long recommended limits on cookie sizes, which ended up as a requirement to limit the sum of the lengths of the cookie's name and value to 4096 bytes. Pretty much all browser engines complied with this. Because each engine went about managing this limit in subtly different ways a further refinement was added that also specified a limit for the length of each cookie attribute value to 1024 bytes. Any attempt to set a cookie exceeding the name+value limit should be rejected, and any cookie attribute exceeding the attribute length limit should be ignored. Unraid issue Most of the webGUI functionality seems to deal with this out-of-spec condition OK, but it definitely breaks some VM & docker VNC connectivity. e.g. It's possible that this might be a root cause of a variety of other reported bugs - the only one that I can personally confirm is with a CrashPlan docker that fails to connect if the webGUI Network graph is set to 2 minute history and allowed to sample traffic for longer than 1 minute or so. Some other dockers with VNC interfaces, such as Krusader, seem unaffected. Suggested solutions Reduce recorded value to ~7 digit precision from 14 ? Limit recorded intervals to 60 seconds instead of 120 ? Use some other sort of variable state mechanism other than cookies ? Investigate what is happening with some VNC implementations that cause them to mishandle out-of-spec cookies ? Sources https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis/ https://github.com/httpwg/http-extensions/blob/main/draft-ietf-httpbis-rfc6265bis.md#the-set-cookie-header-field-set-cookie

[Note: I originally added this as as reply to [6.7.2] DOCKER IMAGE HUGE AMOUNT OF UNNECESSARY WRITES ON CACHE Didn't notice it was raised against 6.7.2, not 6.8.0. Sorry] For what it's worth:- Is this perhaps an issue with sparse files ? I'm having a somewhat similar problem when writing a torrent of an ISO to a share on a mirrored cache pool. (2 x Crucial MX500 SSDs, BTRFS, Raid 1) 6.7.2 was fine, on 6.8.0 there's huge write amplification whenever the torrent client tries to write out a chunk. e.g. Torrent client creates a 3.5GB sparse file, then starts downloading chunks to it's internal RAM cache. When a chunk (4MB) part is completely received it writes it to disk into the pre-allocated ISO sparse file. However - instead of the expected 4MB disk write it seems to be rewriting the *entire* 3.5GB file every time it sends a new chunk to the disk file. This leads to the SSDs writing continuously for hours, for what *should* take less than a second (and also getting very hot). Other types of disk write activity (copying, moving, file creation etc) behave normally, at expected speeds and levels of SSD activity. i.e. Copying a regular 3.5GB file to the share takes < 10 seconds. Also - I reverted from 6.8.0 to 6.7.2 and the problem disappeared, so it's not related to a bad Unraid cache pool config, or anything in the, unchanged, torrent client config. I found this bug report before I raised one of my own and I wonder if it was the same root cause as (I believe) the Docker IMG files are also created as sparse files. If I'm way off base, and my issue is unrelated issue please let me know and I'll raise mine as a separate bug report. -- kurai