On Wed Apr 4 05:14:54 EDT 2007, vlholmesjr@netzero.net wrote:
> i was reading about jukeboxs & worm drives on the plan9 site. CD-R ~=
> WORM...
> so does the venti system allow you to use a recordable cd in a multi-
> session mode as a backup repository?

the worm was originally used with the standalone fileserver kernel.
magnetic disks were used as cache, the dump (archival snap in
venti-speak) was written linearly onto the worm starting at block
3 of the first worm disk. a robot changer was used to swap disks.

one could add the ability to write to cd/dvd to fs without too much
trouble. the trouble is it takes a lot of dvds to backup a single drive
and to make this really work, you'd need a robotic changer.

venti has isect (index) and arenas (data). arenas are approxminately
cd size, but there's no provision to deal with cds directly. copying
filled arenas to cd would be pretty simple with cdfs. (dvds aren't
supported. i don't know about muti-session cds.) the problem is
making this automatic.

> also, i am three hours into a fresh plan9 download, and firefox says i
> have three hours to go. ( i;m in the boonies about 5 miles past the
> nearest broadband, but i really want to try abaca badly. Maybe i can
> recycle my w98 partition!) isn't there a way to keep a plan 9 arena
> on the web so people who enjoy life on the bleeding edge could update
> their source from the incremental backup and rebuild rather than
> download a new iso to stay up to date?

been there, done that! you can update with /usr/genda/bin/rc/pull.
this will scan a log and update only the files changed. it was very
speedy for me over a 56k modem.

over the modem i never could get the full image to download before
it was updated, thus forcing me to start over.

- erik

> been there, done that! you can update with /usr/genda/bin/rc/pull.
> this will scan a log and update only the files changed. it was very
> speedy for me over a 56k modem.

http://plan9.bell-labs.com/wiki/plan...ng_up_to_date/

> over the modem i never could get the full image to download before
> it was updated, thus forcing me to start over.

I have heard various reports of people with broken ISO images and this
might be an explanation.

Would be nice if the BL overlords could avoid this, maybe by moving
the previous day ISO before the new one takes its place, similar to
how replica moves foo to _foo.

uriel

> Would be nice if the BL overlords could avoid this, maybe by moving
> the previous day ISO before the new one takes its place, similar to
> how replica moves foo to _foo.

It already does that (maybe the overlords aren't as dumb as you think).
But if the HTTP download gets interrupted after a new file has been
dropped in its place, a client retrying the HTTP request will see
the new file. If your download is not interrupted, then it will get
a consistent file.

Even if you are getting interrupted, the CD is at most 100MB
compressed, which is only 5 hours at 56kbps, so you've got plenty
of time to grab it in the 24-hour window.

Further, I doubt very much that this is the cause of people with
broken ISO images. You can't get that far if you get half of one
download and half of another. They're compressed, and the checksum
will fail during decompression even if the web browser doesn't notice
that the file changed in the second request. So you'd end up with a
broken .bz2 file, not a broken image. If you ever get to a .iso file,
it will be intact.

Russ

russ,

the plan 9 distribution is very nice and the careful work and thought
that went into the distribution. i don't think there's anything stupid
about it.

however,

On Thu Apr 5 11:13:00 EDT 2007, rsc@swtch.com wrote:
> Even if you are getting interrupted, the CD is at most 100MB
> compressed, which is only 5 hours at 56kbps, so you've got plenty
> of time to grab it in the 24-hour window.

i found that even with a 56k connection with compression
(which works against you in this case), the download took significantly
longer. modems can be difficult to keep connected. this in addition
to the fact that i didn't know what time of day the new iso was cut,
made it nearly impossible to download the iso.

- erik

Ok, then I guess I was wrong.

Maybe a solution to quanstrom's problem would be to use file names
based on the creation date (one would only need to keep one or two
around).

uriel

On 4/5/07, Russ Cox wrote:
> > Would be nice if the BL overlords could avoid this, maybe by moving
> > the previous day ISO before the new one takes its place, similar to
> > how replica moves foo to _foo.
>
> It already does that (maybe the overlords aren't as dumb as you think).
> But if the HTTP download gets interrupted after a new file has been
> dropped in its place, a client retrying the HTTP request will see
> the new file. If your download is not interrupted, then it will get
> a consistent file.
>
> Even if you are getting interrupted, the CD is at most 100MB
> compressed, which is only 5 hours at 56kbps, so you've got plenty
> of time to grab it in the 24-hour window.
>
> Further, I doubt very much that this is the cause of people with
> broken ISO images. You can't get that far if you get half of one
> download and half of another. They're compressed, and the checksum
> will fail during decompression even if the web browser doesn't notice
> that the file changed in the second request. So you'd end up with a
> broken .bz2 file, not a broken image. If you ever get to a .iso file,
> it will be intact.
>
> Russ
>

On 4/5/07, erik quanstrom wrote:
> russ,
>
> the plan 9 distribution is very nice and the careful work and thought
> that went into the distribution. i don't think there's anything stupid
> about it.
>
> however,
>
> On Thu Apr 5 11:13:00 EDT 2007, rsc@swtch.com wrote:
> > Even if you are getting interrupted, the CD is at most 100MB
> > compressed, which is only 5 hours at 56kbps, so you've got plenty
> > of time to grab it in the 24-hour window.
>
> i found that even with a 56k connection with compression
> (which works against you in this case), the download took significantly
> longer. modems can be difficult to keep connected. this in addition
> to the fact that i didn't know what time of day the new iso was cut,
> made it nearly impossible to download the iso.
>

what about setting up a bittorrent tracker ?

it could solve the issue and allow to have several versions of the ISO
available online for some time from various sources.

--
Laurent Malvert [laurent.malvert@gmail.com]

On Fri, Apr 06, 2007 at 03:26:19PM +0200, Laurent Malvert wrote:
> On 4/5/07, erik quanstrom wrote:
> >On Thu Apr 5 11:13:00 EDT 2007, rsc@swtch.com wrote:

> >> Even if you are getting interrupted, the CD is at most 100MB
> >> compressed, which is only 5 hours at 56kbps, so you've got plenty
> >> of time to grab it in the 24-hour window.
> >i found that even with a 56k connection with compression
> >(which works against you in this case), the download took significantly
> >longer. modems can be difficult to keep connected. this in addition
> >to the fact that i didn't know what time of day the new iso was cut,
> >made it nearly impossible to download the iso.
>
> what about setting up a bittorrent tracker ?
>
> it could solve the issue and allow to have several versions of the ISO
> available online for some time from various sources.

I'm sure you could even select from many already available ones.
Just run a seed somewhere. Of course even that could be done
unofficially and downloaders doing the checksum dance to verify
the result.

It would take load off the download servers, too, of course.

For extra fashion points, you could have RSS feeds announce new
versions. Many clients would let you follow those quite
automatically.

--
To know what you prefer, instead of humbly saying Amen
to what the world tells you you ought to prefer,
is to have kept your soul alive.
-- Robert Louis Stevenson