http://bugzilla.opensuse.org/show_bug.cgi?id=964677 http://bugzilla.opensuse.org/show_bug.cgi?id=964677#c2 --- Comment #2 from Ulrich Windl --- Meanwhile I got one step further, but now 'http://download.opensuse.org/update/42.1/repodata/ed4b28992b296a6d4e639f2b01...' has a wrong SHA-256 checksum: want: ed4b28992b296a6d4e639f2b01f942bfa32380b75a53acaa82ed292616ab21e1 have: 0c978f049c7c1aa5acda4a0ed11224c5833f678b668567a3a9ce9b084b1b71a1 Another file that does not work is 'http://download.opensuse.org/update/42.1/repodata/a5c2ffb1a8acfe52a34d58a230...' -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=964677 http://bugzilla.opensuse.org/show_bug.cgi?id=964677#c4 andreas bittner changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |abittner@opensuse.org --- Comment #4 from andreas bittner --- btw, apparently I reported too late ;) #boo964696 but I experienced slowness and barely loading while zypper ref already like 12 hours ago or even longer. So if its all related then the problem has been cooking for half a day already -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=964677 http://bugzilla.opensuse.org/show_bug.cgi?id=964677#c6 --- Comment #6 from andreas bittner --- seems to refresh quickly/normally right now again. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=964677 http://bugzilla.opensuse.org/show_bug.cgi?id=964677#c8 --- Comment #8 from andreas bittner --- well there are still no hints posted in this bugreport as to the reasons why the mirrorbrain and or the other mirrors were not properly filled or registered for select files. maybe related: was ever a much more decentralised and distributed means considered dealing with software distribution also for smallish files of the update repositories and in general? maybe like a torrent based or similar ideas? less single servers and single point of failures. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=964677 http://bugzilla.opensuse.org/show_bug.cgi?id=964677#c9 --- Comment #9 from Marcus Rückert --- we can always have moments shortly after an update was released that we dont have mirrors yet. in that case 195.135.221.157 gets hammered and we might run into "max connections"-limit of that server. For the torrent part that would require yast support first. and for metalink files we would need to have mirrors first. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=964677 http://bugzilla.opensuse.org/show_bug.cgi?id=964677#c11 --- Comment #11 from andreas bittner --- back at this bug as right at this moment fetching the meta is hellishly slow again :( Retrieving: http://download.opensuse.org/update/leap/42.1/oss/repodata/bd866ab99c839986f... .....[done (8.1 KiB/s)] Retrieving: http://download.opensuse.org/update/leap/42.1/oss/repodata/8102bbe0c7d5a85ff... ....[done (6.9 KiB/s)] Retrieving: http://download.opensuse.org/update/leap/42.1/oss/repodata/6bda640ac3fa2b9ff... ----------[/ (2.4 KiB/s)]Retrieving: http://download.opensuse.org/update/leap/42.1/oss/repodata/6bda640ac3fa2b9ff... ........[error (673 B/s)] Download (curl) error for 'http://download.opensuse.org/update/leap/42.1/oss/repodata/6bda640ac3fa2b9ff...': those few kilobytes/sec is long-term meaning taking many minutes to fetch those files and the last one timed out even or so -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=964677 http://bugzilla.opensuse.org/show_bug.cgi?id=964677#c13 --- Comment #13 from andreas bittner --- I must be very lucky then to kinda 'always' fetch these files when they are still hot :) Is there no better ways to first push to mirrors and only the make the meta files (and data files) visible on the master? Is there more advanced technology like git or similar to do this kind of stuff? Thanks. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=964677 http://bugzilla.opensuse.org/show_bug.cgi?id=964677#c15 --- Comment #15 from Ulrich Windl --- Well, my complaint was about no being able to retrieve files at all, but anyway: As far as I understand things, the repository is already a bit git-like, so you can sync everything but when not having the "root commit", you cannot access anything. If I'm not wrong the repomd.xml points to the latest "commit" (something like repodata/783deddb9a521dc024d89fd18cc4bf98dd1df913e13febc73ae 704788a875055-primary.xml.gz). In my understanding old patches are also still around in the repository, so while a repository is updated you can still retrieve the older versions (this is a guess). As soon as the new repomd.xml (and signature) is available, the newer patches will be found and used. (In the past those second-level XML files had a fixed file name, so you could only have exact one version in the directory) I don't know if those obsolete repodata/*-*.xml.gz are ever removed from the source directories... -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=964677 http://bugzilla.opensuse.org/show_bug.cgi?id=964677#c17 --- Comment #17 from andreas bittner --- for almost an hour now the repo metadata oss update for leap 42.1 is barely (or actually not at all) retrievable i have several remote sessions on different machines who all retrieve the oss update repo information for double digit minutes now it is never clear when opensuse mirror infrastructure broke down and when to really consider these slowlieness as a real problem or when to wait longer today earlier the 11hour something repo never retrieved for me, then later i came back and now the 15hour repo again doesnt retrieve at my places all small files (sub 5kilobytes) have mirrors available and the one 700kilobyte file has mirrors all others even the few hundred kilobyte files and the multi megabyte files in the oss update repo dont have mirrors for almost an hour now http://download.opensuse.org/update/leap/42.1/oss/repodata/?C=M;O=D now i really dont know how robust the opensuse mirrors ought to be but either i should go to a casino and use my bad luck there or i am truly always suffering from these mirror unavailabilities -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=964677 http://bugzilla.opensuse.org/show_bug.cgi?id=964677#c19 --- Comment #19 from andreas bittner --- Well race condition in what way ? Race condition with 1+ hour locking down delay? I didnt manage to fetch the metadata from today at 11oclock edition, and barely managed to fetch the newer repodata at 15oclock. The weird stuff is that the repodata is on fewer or on none of the mirrors but the actual binaries of the releases themselves are already spread. Why not going for a a very simple pointer. A single tiny file pointing to the current and well spread revision of the actual main metadata(s). and only when the newer metadata files are spread, then update this index metadata tiny file as the last object on the main server. This would be the most simple way to circumvent these hassles. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=964677 http://bugzilla.opensuse.org/show_bug.cgi?id=964677#c21 Marcus Rückert changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #21 from Marcus Rückert --- This will be fully fixed when we switch to an event based publisher handling. but we split download.o.o from the fallback machine now. so this shouldnt happen anymore. you should always get a slot but not always a fast download. -- You are receiving this mail because: You are on the CC list for the bug.