Re: Rawhide 20080328 Snapshot Released

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jesse Keating wrote:
On Sat, 2008-03-29 at 22:59 +0900, John Summerfield wrote:
Is it difficult to release jigdos?

The problem is this.

Jigdo would require the exploaded bits be available by http.  Trying to
sync all that content around the mirrors in any sort of reasonable time
frame is not going to happen.  Hanging the entire tree off of a single
http point is not going to happen either, that point would quickly drown
under the connections.  We can't just rely on rawhide as tomorrow the
rawhide content will be different and you wouldn't be able to complete
your jigdo.

If we're to have any sort of fast to the public snapshoting, we have to
use a delivery mechanism that is capable of spreading the bandwidth load
throughout the users without bringing down the host.  Right now, that
only leaves us with bittorrent as an option.

Now, if there were some way to combine bittorrent and jigdo and if jigdo
had better failover methods when mirrors are hit without the content we
could potentially do something better.  Jigdo + rawhide + whatever you
already have for the majority of the content, bittorrent to suck down
the very last little bit or something along those lines.

One way to make bittorrent for the {iso} faster may be to:
- build iso as normal
- mount the iso
- build the torrent of the mounted iso
    now we have a torrent in little rpm {+ other bits} chunks.
- user gets set to download this torrent, but puts the download location in the same location that he had his previous copy of mounted iso. note: the practice of including a subfolder in the .torrent definition makes this difficult - because you need to mess with what the path inside the new torrent will be.

- force recheck function {azureus}
- each pre-downloaded {existing} file is checked against the torrent
- bt client only downloads the changed chunks / new files.

- need a tool to rebuild the identical iso out of the copy of the mounted tree... including the iso structure and boot parts.

Further it would be cool if bt client could know about:
- fastest: bits I may already have on my local machine
- faster: bits I have on my local network
- fast: bits that my ISP is mirroring {and not charging me download for}
- medium: in country mirrors.
- bittorrent normal method.
and use them in that order.

If any of that actually makes sense, let me know if I can be of assistance.

DaveT.

--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list

[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Photo Sharing]     [Yosemite Forum]     [KDE Users]

  Powered by Linux