|
|
| Author |
Message |
| 16 new of 40 responses total. |
gregc
|
|
response 25 of 40:
| 
Sep 22 06:54 UTC 1995 |
Marcus, you state: If we do plan to deploy direct network access, then we
better give careful consideration to the best use of our limited network
bandwidth."
What "limited network bandwidth"? If we hook the 2 machines together with
a 10mps ethernet cable, we'll barely touch that bandwidth. Currently, the
only traffic we have on our cable is to/from gryphs and that is limited by
the PPP link. A terminal server will eventually add more load, but that is
limited by character speed of the modems. We have limited network bandwidth
over the PPP link to the internet, but if someone is logged into Grex(the
Sun-4) and wthey read their mail interactively from te mail server(the Sun-3)
the network traffic is going to be *trivial*.
As far as backups are concerned, we don't need a second tape unit and we
don't need an A/B switch. Have you never done a remote dump? The Sun-3
can be backed up over the ethernet to the tape drive on the Sun-4.
But, aside from an initial backup after it is fully configured, and then
occaisional backups whenever something new is added, or maybe once every
month or 2 just in case, the mail server probably won't *need* to be
backed up. The only thing on it that would need backing up, would be the
mail spool, but that is such a *variable* and transitory set of data, that
you would have to either make a backup every 30 minutes, or just not bother.
Any backup made with be worthless within 6 hours.
^^^^will
|
scg
|
|
response 26 of 40:
|
Sep 22 13:58 UTC 1995 |
I think what Marcus was saying about IMAP was not that it would put a
tremendous load on the ethernet in the Dungeon, but that it would put a
tremendous load on the 28.8 link to the Net if it were used from somewhere
else, and would be of no advantage if it were just used to read mail on one
machine.
|
gregc
|
|
response 27 of 40:
|
Sep 22 17:52 UTC 1995 |
Ok, I'm talking about using IMAP for the express and only purpose of off-
loading mail processing from the main machine(the eventual Sun-4) to a
secondary machine(the current Sun-3) that would only do mail processing.
That secondary machine would only be accessable from the Sun-4 and not
from the Internet.
|
ajax
|
|
response 28 of 40:
|
Sep 22 21:42 UTC 1995 |
For me, a 6-hour-old backup of the mail spool wouldn't be useless; in fact,
even a month-old backup would have a little value. It depends on how a
person processes their mail.
As an aside, does SunOS or another Unix that Grex could use in the future
support mirrored hard drives with free/inexpensive software? Might be
useful for a mail or other frequently changing partition.
|
gregc
|
|
response 29 of 40:
|
Sep 22 22:01 UTC 1995 |
No, that's not available.
|
mdw
|
|
response 30 of 40:
|
Sep 23 14:50 UTC 1995 |
Backups over ethernet are typically much slower than when done locally.
The ugly issue of security also arises; we certainly don't want to give
bad people the ability to read everyone's mail.
I've never made any sort of serious study of this; but I'd guess that
most of the files stored on Grex (aside from staff and system files)
probably *are* mail. There will be a few scripts, some bits of ascii
art, web pages for a small minority, and a few people with C programs
and such - but all that will be relatively rare.
Now, with POP, I'd agree, that mail spool can be treated as
non-permament transient storage, not worth backing up. But with IMAP,
that's no longer true - all those love letters, favorite hate mail, cute
poems, favorite sayings, private archives of favorite limited
circulation mailing lists, and family recipes that people currently save
in their mail directory on Grex, would end up on the IMAP server instead
- and so the backup needs will become just as crucial as grex itself, if
not more so.
|
lilmo
|
|
response 31 of 40:
|
Sep 23 19:40 UTC 1995 |
Re #30: Hear, hear !!!
|
scg
|
|
response 32 of 40:
|
Sep 24 02:36 UTC 1995 |
That would depend on how far Grex goes in an IMAP implementation. It is
certainly desirable to have the mail files live on the server when doing IMAP
from lots of different machines, which is the usual use for it. However, when
doing mail with IMAP and only using a mailer on Grex, it would probably make
more sense for people to save it in their home directories on Grex than on
the IMAP server, since the files are more easily accessable that way. The
only IMAP mailer I've ever played with is Pine, so I don't know how the others
work, but with Pine it is possible to keep the mail spool on an IMAP server
and still save stuff in a home directory.
|
mdw
|
|
response 33 of 40:
|
Sep 24 06:45 UTC 1995 |
Is that something the user decides, or something that's configured
into Pine?
|
scg
|
|
response 34 of 40:
|
Sep 24 17:05 UTC 1995 |
I think the default can be configured into Pine, but the user can decide and
override the default.
|
lilmo
|
|
response 35 of 40:
|
Sep 24 18:31 UTC 1995 |
I just checked, and it appears that that is the case, but I am not an expert
in Unix, and even less so over a local network.
|
gregc
|
|
response 36 of 40:
|
Oct 3 12:16 UTC 1995 |
Marcus, in #30 you stated:
"Backups over ethernet are typically much slower than when done locally."
Not true.
The Exabyte tape drive we use has an upper limit of about 10Mbyte per minute
due to tape speed and interface. That translates to about 167Kbyte per second
across the ethernet. Theoretical maximum speed for ethernet is 1.25mbyte per
second. Now I *know* that maximum, or even close to it, is unattainable, but
SunOS has alot of the VJ enhancements already integrated, and 2 suns *are*
easily capable of 500Kbyte per second across the ethernet. Plus you allowing
one machine to do only reads on it's SCSI bus, and the target machine to do
only writes on it's SCSI bus to the tape drive, thereby limiting bus
contention. I know this works. I am currently backing up the new Sun-4, using
rdump, across the ethernet to my Exabyte drive on my NetBSD box. I'm able to
pump the tape drive at it's full 10Mbyte per minute rate.
I think one thing you must consider: Any conceptions you have about the
realative performance levels of ethernet are based on the work you're been
doing the last couple of years at large companies and the UofM. These networks
have alot of machines doing alot activity and make ethernet look slow. But
that doesn't apply to Grex. We have one short segment, with just a very few
machines on it and not much intermachine net traffic. Ethernet under our
situation is actually very *fast*.
|
mdw
|
|
response 37 of 40:
|
Oct 5 06:34 UTC 1995 |
Most modern disks are much faster than ethernet. Tapes vary
considerable in performance, but higher performance tape drives
typically approach disk speeds, not ethernet speeds. I'm afraid I don't
have any exact tape performance speeds for the various generations of
tape drives I've seen here at the U; but I suspect most of them were
higher end devices, often on separate busses from the disk. That means
it would be surprising if introducing ethernet (even a fully idle path)
didn't slow things down. In the more general case, I've found that more
complicated systems generally perform worse unless great care is taken
to optimize performance. In the case of rdump/rtmpd, there isn't any
sort of fancy overlapping windowing protocol; it's a simple
command/response interface. That means there are 4 states: reading from
the disk, writing the data to ethernet, writing the data to tape, and
sending the response back. If the performance you measured was equal to
the tape, and your tape is that slow, then that says that the tape
controller or drive is "smart" and manages a local series of streaming
buffers, and that the relatively faster ethernet/scsi disk data source
is able to keep the local tape data buffers full. If such is indeed the
case, then it's likely to make little difference if the tape is on the
same or a different scsi bus, or either locally attached or accessed via
the network - in all cases, the performanced would be bounded by the
speed of the slow tape. That's different than the tapes I'm used to,
but certainly I've heard of tape drives like that.
My sercurity concerns regarding the remote tape interface still stand.
I note that rdump uses "rcmd" to spawn the /etc/rmt process on the tape
machine. That does not inspire me with any confidence whatsoever that
people's data will remain private.
|
rogue
|
|
response 38 of 40:
|
Oct 6 03:13 UTC 1995 |
An Exabyte 8505 will do 500kb/sec straight and 1MB-2MB/sec with hardware
data compression. That is approaching hard disk speed but most modern
Fast SCSI-2 hard disks will crush the Exabyte 8505 pretty easily.
A DDS-2 DAT will do 330kb/sec straight and 660kb-1.3MB/sec with hardware
data compression. Again, hard disks will crush it.
|
steve
|
|
response 39 of 40:
|
Oct 22 18:16 UTC 1995 |
Marcus, I share your concerns about security, but it doesn't quite
apply here, becuase we normally take the system down before doing a
backup. Otherwise, everyone suffers. Having recently done some tests
on a sparc 5 dumping across a limited net, I can attest to the fact
that remote dumping to an exabyte drive (the 5 gig drive--forget the
model number) isn't appreciably slower than a local dump.
I think we should look at mail systems from the user's points of
view first, then see if we can match them on the technical side. My
first though is, can we find pop/imap applications today for all the
popular mailers, and what do we do about mail processing (ala procmail)?
I tend to think that IMAP is the way to go here, but I really want to
see what we can get, to make life for users as close to the surrent
system, before deciding which to use. The fact that IMAP is gaining
support is certainly a large factor in its favor.
|
mdw
|
|
response 40 of 40:
|
Oct 29 02:42 UTC 1995 |
The problem with the network is, taking down the system doesn't really
make much difference. I do agree, however, that this is a fairly
esoteric detail & certainly not reason in itself to do or not do
something. My argument really is that if we do decide IMAP is the way
to go, then we should certainly be willing to do proper backups and that
is almost certainly best done with a dedicated tape drive. But there
are a lot of other details that would need to be worked out as well,
such as how to deal with "vacation" and "procmail".
|