|
Bugzilla – Full Text Bug Listing |
| Summary: | Live system boot-up takes a long time trying to write "superblocks and filesystem accounting information" | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Distribution | Reporter: | Atri Bhattacharya <badshah400> |
| Component: | Live Medium | Assignee: | Stephan Kulow <coolo> |
| Status: | RESOLVED FIXED | QA Contact: | Stephan Kulow <coolo> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | bruno, ms |
| Version: | 13.2 Beta 1 | Flags: | badshah400:
SHIP_STOPPER?
|
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | openSUSE 13.2 | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | Tarball from save_y2logs | ||
I need to look at it myself, but kiwi added lately tons of timeouts as workarounds ;( Since this seems to be a by and large general issue [1] and provides for a potentially fatal first impression of the distribution, I would like to request a ship_stopper for this. If there is anything I can do to help out, I would be happy to -- please let me know -- but it seems to me this needs to be fixed before 13.2 full release. [1] http://lists.opensuse.org/opensuse-factory/2014-10/msg00667.html This should be fixed with: commit 1542af4dacc862b5e6bd89fc67e5a344a017a115 Author: Marcus Schäfer <ms@suse.de> Date: Wed Oct 22 11:04:37 2014 +0200 Use btrfs as write partition for hybrid images (bnc #900922) For hybrid live iso images there is the optional support to create a write partition for data persistency. The initial creation of the filesystem can take a long time on e.g USB sticks. The creation of a btrfs filesystem without static inode tables is much faster. Thus the switch to btrfs I have done some smoke tests and it improved the situation. But the performance of USB sticks wrt IO is very different Atri, if you try a dd if=/dev/zero of=/dev/YOURUSBSTICK bs=4M what is the result ? With lot of keys around you will got a 5MBps which is just so slow compared to any kind of standard 100/160 MBps for rusted harddrive to 600/800 MBps for the best ssd in sata3 mode. btrfs could be a solution. and usb3 stick too. btw our branded openSUSE sticks are in the slowest key on earth in term of rw io. (In reply to Marcus Schaefer from comment #3) > This should be fixed with: > > commit 1542af4dacc862b5e6bd89fc67e5a344a017a115 > Author: Marcus Schäfer <ms@suse.de> > Date: Wed Oct 22 11:04:37 2014 +0200 > Thanks Marcus! Coolo, is there a 13.2/Factory Live image with this change built in that I could test perhaps? (In reply to Bruno Friedmann from comment #4) > Atri, if you try a dd if=/dev/zero of=/dev/YOURUSBSTICK bs=4M > what is the result ? > > With lot of keys around you will got a 5MBps which is just so slow compared > to any kind of standard 100/160 MBps for rusted harddrive to 600/800 MBps > for the best ssd in sata3 mode. > > btrfs could be a solution. and usb3 stick too. > Hi Bruno! Yes I understand the general slowness when using USB sticks (btw, my USB stick is USB3, and not that bad at speeds). However, the problem here is a regression compared to 13.1, i.e. if i use the same medium for doing a first boot from a 13.1 Live image, it isn't half as slow. The problem is the persistent filesystem creation as Marcus mentions. In fact 2nd boot onwards, boot-up speeds are ok. Marcus's fix #c3 really fixed the problem. I tried a fresh Live USB boot from Build 37 and not only was this problem all gone, boot up was impressively fast and performance during Live medium also seems to have improved several orders. Thanks a lot, Marcus! Coolo, I believe this bug can be now closed. ok |
Created attachment 607148 [details] Tarball from save_y2logs During first boot from the 13.2 Beta 1 GNOME x86_64 Live USB disk reaches a stage where it shows "Writing superblocks and filesystem accounting information" and stops there for something like 5-7 mins without showing a progress-bar or any indication that the booting process is actually continuing. This hurts the first impressions on the live system since * a less patient person might have powered-off his computer thinking that the boot process has stopped at this stage, and * even for the patient, this is a major annoyance while trying to get a first impression, having to wait for 5-7 mins without a clue as to whether the system is working or not. If this 5-7 min "pause" absolutely cannot be avoided, it would be great if some progress bar could be shown as the process continues. YaST logs attached.