[yast-devel] storage-ng and cache invalidation
Good morning, I am currently working on cache invalidation problem in CaaSP (bsc#1035746). From top-level view, bootloader store some storage devices in cache due to performance reasons ( in past we get bug report from real that with 1k disks, installation took more then 8 hours just to display bootloader proposal ) and what is problem is bug in invalidating that cache when bootloader storage changed. ( so it is true that chace invalidation is one of two hard things :) [1] ) In CaaSP and for master I will solve it using Storage.GetTargetChangeTime where I compare it and if different I invalidate cache. Now lets get to storage-ng. I try to port this fix there. So my first question is, what is similar equivalent in storage-ng which allows me to see if there is change in storage, so bootloader proposal is no longer valid? When I try to reproduce it on the latest storage-ng iso, I found even more annoying behavior, that when you go to installation summary and then go back to storage proposal and modify it ( I use guided setup with lvm ) and then go back to installation summary, it crashes badly ( segfault ). You can try it on your own with recent enough storage-ng DVD. In general my suspicion is that cache is not just no longer valid for root device, but because bootloader store storage objects, it is no longer valids. And here is my second question, what is recommended way to debug such issues ( so find where invalid object is hold ) ? I reproduce issue using plane libstorage-ng [2], so I try to debug this minimal case. I use gdb and valgrind. I see there that it is destroyed when device graph is destroyed. But I do not find method how to find where in ruby lives object that cause segfault. Any ideas how to recognize it? Ideally way that works also when issue happen on user side. Also I have to say, that from user POV, segfault and ruby exception is very very different. When I get ruby exception, I see popup saying what is a problem. I can continue. I was asked to report bug. And the most important part, I can get logs as environment still lives! When I get segfault, I get quick black screen followed by red area on blue which mention Error occured during installation without any details and what is more important: I do not find way how to get any logs, at least y2signal log will be useful!! So my user experience is very different, as in first case I see reason, I am asked to write bug report and I also can get logs when error happen. In second case I get only generic error and cannot get logs, so if this happen in openQA we also have problem to get it and we have to reproduce it ourself. We probably need to enhance a bit linuxrc to handle this more nicely and at least allow to get logs from segfaulted installation. Thanks for help with any of the question or any feedback. Josef [1] https://martinfowler.com/bliki/TwoHardThings.html [2] https://gist.github.com/jreidinger/b37ae595b3c3d8519453cd3c9fc0f198 -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Tue, May 30, 2017 at 10:04:33AM +0200, Josef Reidinger wrote: [...]
Now lets get to storage-ng. I try to port this fix there. So my first question is, what is similar equivalent in storage-ng which allows me to see if there is change in storage, so bootloader proposal is no longer valid?
That was discussed and even documented in yast2-storage-ng/doc/software-requirements.md but unfortunately already deleted. Have a look at https://w3.suse.de/~shundhammer/storage-timer.txt. [...]
Also I have to say, that from user POV, segfault and ruby exception is very very different. When I get ruby exception, I see popup saying what is a problem. I can continue. I was asked to report bug. And the most important part, I can get logs as environment still lives! When I get segfault, I get quick black screen followed by red area on blue which mention Error occured during installation without any details and what is more important: I do not find way how to get any logs, at least y2signal log will be useful!!
AFAIR as long as the red popup is there you can switch to another console and copy logs and debug the issue. For debugging I recommend to attach gdb before the error happens. ciao Arvin -- Arvin Schnell, <aschnell@suse.com> Senior Software Engineer, Research & Development SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 05/30/2017 11:04 AM, Arvin Schnell wrote:
On Tue, May 30, 2017 at 10:04:33AM +0200, Josef Reidinger wrote:
[...]
Now lets get to storage-ng. I try to port this fix there. So my first question is, what is similar equivalent in storage-ng which allows me to see if there is change in storage, so bootloader proposal is no longer valid?
That was discussed and even documented in yast2-storage-ng/doc/software-requirements.md but unfortunately already deleted. Have a look at https://w3.suse.de/~shundhammer/storage-timer.txt.
And implemented as documented here. To check the revision number: http://www.rubydoc.info/github/yast/yast-storage-ng/master/Y2Storage/Storage... To update the staging devicegraph making sure revision gets updated as well: http://www.rubydoc.info/github/yast/yast-storage-ng/master/Y2Storage/Storage... http://www.rubydoc.info/github/yast/yast-storage-ng/master/Y2Storage/Storage... Cheers. -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Tue, 30 May 2017 11:04:57 +0200 Arvin Schnell <aschnell@suse.com> wrote:
On Tue, May 30, 2017 at 10:04:33AM +0200, Josef Reidinger wrote:
[...]
Now lets get to storage-ng. I try to port this fix there. So my first question is, what is similar equivalent in storage-ng which allows me to see if there is change in storage, so bootloader proposal is no longer valid?
That was discussed and even documented in yast2-storage-ng/doc/software-requirements.md but unfortunately already deleted. Have a look at https://w3.suse.de/~shundhammer/storage-timer.txt.
Thanks for pointing this out. I will try to discuss it today with ancor when he is still in Prague.
[...]
Also I have to say, that from user POV, segfault and ruby exception is very very different. When I get ruby exception, I see popup saying what is a problem. I can continue. I was asked to report bug. And the most important part, I can get logs as environment still lives! When I get segfault, I get quick black screen followed by red area on blue which mention Error occured during installation without any details and what is more important: I do not find way how to get any logs, at least y2signal log will be useful!!
AFAIR as long as the red popup is there you can switch to another console and copy logs and debug the issue.
Thanks, I am not aware about this possibility. So we should at least add it as hint for customers which face it and want to grab logs.
For debugging I recommend to attach gdb before the error happens.
In the end with a bit help from google I can get ruby backtrace. So for future reference, you can get ruby backtrace in gdb ( or if you get core ). with this command: p rb_eval_string_protect("puts caller.inspect", (int *)0) which will print it to console. If stdout is redirected, you can there write it to file with p rb_eval_string_protect("File.write(\"/tmp/debug\", caller.inspect)", (int *)0) And it should also work with core dumps. So what we need in such case from customers are core dump from them, which looks reasonable. Thanks for help Josef
ciao Arvin
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
participants (3)
-
Ancor Gonzalez Sosa
-
Arvin Schnell
-
Josef Reidinger