<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-im" style="color:rgb(80,0,80)">><br></span><span class="gmail-im" style="color:rgb(80,0,80)">> > we propose to remove the ring buffer and write to the log file<br></span><span class="gmail-im" style="color:rgb(80,0,80)">> > as soon as some characters are received.<br></span><span class="gmail-im" style="color:rgb(80,0,80)">><br></span><span class="gmail-im" style="color:rgb(80,0,80)">> I am not sure it is a good idea.<br></span><span class="gmail-im" style="color:rgb(80,0,80)">> The host can generate a lot of logs, but we have very limited free space.</span><span class="gmail-im" style="color:rgb(80,0,80)"><br></span>This is a fair concern, but wouldn't the rollover limits make this not<br>an issue?  They seem like they could be easily configured.</blockquote><div>Right. Logrotate will be able to handle the rotation. Maximum size, # log files, and compression can be easily configured.  </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-im" style="color:rgb(80,0,80)">> In<br></span><span class="gmail-im" style="color:rgb(80,0,80)">> addition, such heavy traffic will lead to a quick breakdown of the flash (most<br></span><span class="gmail-im" style="color:rgb(80,0,80)">> available products are guaranteed to withstand around 100,000 P/E cycles only).</span><span class="gmail-im" style="color:rgb(80,0,80)"><br></span>JFFS2 is wear leveled, and there are other BMC stacks that I know of<br>that implement this without any ill effects to flash longevity, with<br>that said, if Nan made the "last log on disk" feature configurable,<br>would that alleviate your concerns?</blockquote><div>We also noticed that the obmc-server itself will buffer the log a bit. Will it still be a problem if we don't write a character at once but a block of them?</div><div>And as Ed said, we can also make this feature configurable. I would imagine the log buffer will remain if the "last log on disk" feature is disabled.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-im" style="color:rgb(80,0,80)">><br></span><span class="gmail-im" style="color:rgb(80,0,80)">> > This implicitly removes the needs<br></span><span class="gmail-im" style="color:rgb(80,0,80)">> > of the ring buffer, and the persistence triggering (host reboot, sigterm,<br></span><span class="gmail-im" style="color:rgb(80,0,80)">> > etc) in hostlogger. We believe this keeps the same functionality but saves<br></span><span class="gmail-im" style="color:rgb(80,0,80)">> > hundreds of lines of codes in phosphor-hostlogger.</span><span class="gmail-im" style="color:rgb(80,0,80)"><br></span>Difference of opinion here, I don't think this removes the need for<br>the host reboot event;  Having each reboot post to a different log<br>needs to be maintained, and I have to imagine that there's some sort<br>of sigterm handler still, although it becomes a lot smaller.</blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-im" style="color:rgb(80,0,80)">><br></span><span class="gmail-im" style="color:rgb(80,0,80)">> You are suggesting to delete the buffer, DBus watcher, log rotate. How are you<br></span><span class="gmail-im" style="color:rgb(80,0,80)">> going to keep the same functionality if you remove everything related to it?</span><span class="gmail-im" style="color:rgb(80,0,80)"><br></span>+1.  In the initial thought I didn't think we were removing any<br>functionality with this.  I had assumed the dbus watcher would remain,<br>and we would still have the log rotation behavior.  In reading through<br>Nans proposal I don't think these are getting removed;  Maybe I<br>misunderstood? </blockquote><div><br></div><div>Yes, if we want to keep different reboot posts to a different log file, we can keep part of the dbus/signal watcher.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 21, 2021 at 10:24 AM Ed Tanous <<a href="mailto:edtanous@google.com">edtanous@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, May 20, 2021 at 11:10 PM Artem Senichev <<a href="mailto:artemsen@gmail.com" target="_blank">artemsen@gmail.com</a>> wrote:<br>
><br>
> On Thu, May 20, 2021 at 04:29:09PM -0700, Nan Zhou wrote:<br>
> > Hi all,<br>
> ><br>
> > In the previous thread (<br>
> > <a href="https://lists.ozlabs.org/pipermail/openbmc/2021-March/025234.html" rel="noreferrer" target="_blank">https://lists.ozlabs.org/pipermail/openbmc/2021-March/025234.html</a>), we<br>
> > (engineers from Google and Quanta) discussed our attempt to share host<br>
> > serial logs via Redfish, which includes polling logs via LogService and<br>
> > streaming log bytes via EventService (e.g. SSE). We went with the event log<br>
> > architecture<br>
> > <<a href="https://github.com/openbmc/docs/blob/master/architecture/redfish-logging-in-bmcweb.md" rel="noreferrer" target="_blank">https://github.com/openbmc/docs/blob/master/architecture/redfish-logging-in-bmcweb.md</a>><br>
> > and did the implementation.<br>
> ><br>
> > We still want to reuse the phosphor-hostlogger and do some modification. We<br>
> > believe it is better to try to reuse existing codes if possible and improve<br>
> > them rather than creating new things that have similar functionalities (in<br>
> > our case, it is a daemon that could collect logs and persist them).<br>
><br>
> I agree, reusing code is a right choice, but only when it is really possible.<br>
> For now it looks like you want to remove most of the Hostlogger features to<br>
> transform it from buffer-like to stream-like service.<br>
<br>
I'm not quite following this statement.  Which features are getting<br>
removed?  From what I can see, he's suggesting making<br>
phosphor-hostlogger look more like a well-behaved linux logging<br>
daemon, but I don't think any features got omitted (or I'm missing<br>
something critical).<br>
<br>
><br>
> > We want to do the following modification in phosphor-hostlogger (from the<br>
> > input and output point of view, just very few things will be changed)<br>
> ><br>
> > 1. One limitation of phosphor-hostlogger is that it will lose data in the<br>
> > memory (the ring buffer maintained by hostlogger) when BMC gets force<br>
> > restarted;<br>
><br>
> When BMC goes to reboot it stops all services, at that moment hostlogger gets<br>
> a signal and flushes all gathered logs to a file.<br>
<br>
Only if the reboot is planned.  If the BMC loses power (which is<br>
"normal" for a bmc) there isn't time to persist to flash before the<br>
power goes down and the logs are most likely lost.<br>
<br>
><br>
> > we propose to remove the ring buffer and write to the log file<br>
> > as soon as some characters are received.<br>
><br>
> I am not sure it is a good idea.<br>
> The host can generate a lot of logs, but we have very limited free space.<br>
<br>
This is a fair concern, but wouldn't the rollover limits make this not<br>
an issue?  They seem like they could be easily configured.<br>
<br>
> In<br>
> addition, such heavy traffic will lead to a quick breakdown of the flash (most<br>
> available products are guaranteed to withstand around 100,000 P/E cycles only).<br>
<br>
JFFS2 is wear leveled, and there are other BMC stacks that I know of<br>
that implement this without any ill effects to flash longevity, with<br>
that said, if Nan made the "last log on disk" feature configurable,<br>
would that alleviate your concerns?<br>
<br>
><br>
> > This implicitly removes the needs<br>
> > of the ring buffer, and the persistence triggering (host reboot, sigterm,<br>
> > etc) in hostlogger. We believe this keeps the same functionality but saves<br>
> > hundreds of lines of codes in phosphor-hostlogger.<br>
<br>
Difference of opinion here, I don't think this removes the need for<br>
the host reboot event;  Having each reboot post to a different log<br>
needs to be maintained, and I have to imagine that there's some sort<br>
of sigterm handler still, although it becomes a lot smaller.<br>
<br>
><br>
> You are suggesting to delete the buffer, DBus watcher, log rotate. How are you<br>
> going to keep the same functionality if you remove everything related to it?<br>
<br>
+1.  In the initial thought I didn't think we were removing any<br>
functionality with this.  I had assumed the dbus watcher would remain,<br>
and we would still have the log rotation behavior.  In reading through<br>
Nans proposal I don't think these are getting removed;  Maybe I<br>
misunderstood?<br>
<br>
><br>
> > 2. We propose not to compress the latest log file. This saves us the<br>
> > overhead of doing decompression when BMCWeb just needs to retrieve the most<br>
> > recent logs. There are still going to be log rotations in the file level.<br>
> > Files other than the latest log file are still going to be compressed. We<br>
> > can modify existing codes to achieve this or use the linux logrotate<br>
> > directly.<br>
> ><br>
> > Furthermore, we will add host serial logs into BMCWeb, both LogService and<br>
> > EventService. In LogService, we will teach BMCWeb how to read the latest<br>
> > log file that is not compressed and the other compressed old logs, and how<br>
> > to assemble LogEntries out of raw serial logs. We will discuss EventService<br>
> > in future threads but the very initial idea is to setup inotify on log<br>
> > files and SSE to stream out new bytes to clients (like what the existing<br>
> > event logging is doing).<br>
> ><br>
> > As we said above, for phosphor-hostlogger, the input is still the<br>
> > obmc-server unix socket, and the output are still persisted log files. But<br>
> > the functionality will get improved (less data loss), code gets simplified<br>
> > (no ring buffer and persistence triggering), and it will become easier and<br>
> > more performant to get BMCWeb hooked up for log streaming via Redfish.<br>
> ><br>
> > Please let us know what you think. We appreciate any feedback. Thank you<br>
> > very much!<br>
> ><br>
> > Sincerely,<br>
> > Nan<br>
><br>
> --<br>
> Regards,<br>
> Artem Senichev<br>
> Software Engineer, YADRO.<br>
</blockquote></div>