|
Grex > Coop13 > #4: brainstorming solutions for the full disk problem |  |
|
| Author |
Message |
| 25 new of 203 responses total. |
davel
|
|
response 25 of 203:
| 
Mar 6 01:05 UTC 2001 |
I agree, pretty strongly, but I think this means Marcus & Mark &
I are part of what pfv means when he says "the crazies will jump all over the
idea".
(OK with me, if so.)
|
swa
|
|
response 26 of 203:
|
Mar 6 07:22 UTC 2001 |
More frequent reminders might be a good place to start. I don't bring
over huge files to my Grex account, but I use it for mail, which has the
tendency to accumulate over time. I go through and delete bunches of old
mail when I happen to think of it and notice I'm over the disk space limit
-- but generally I notice before staff does; only once have I received a
reminder about this.
This won't solve the problem of disk hogs who are just passing through,
but I suspect I'm not the only person out there who does care, is
absentminded, and responds well to gentle pressure.
|
ryan
|
|
response 27 of 203:
|
Mar 6 17:46 UTC 2001 |
This response has been erased.
|
remmers
|
|
response 28 of 203:
|
Mar 6 20:30 UTC 2001 |
I think we have spare hard drives as it is. No additional money
needed to install, just some staff time...
|
pfv
|
|
response 29 of 203:
|
Mar 6 20:35 UTC 2001 |
money, space and staff time were the original "bottom-line"
Add space? Same problems will grow.
Older users? Same-same.
NEW USERS? same-same..
|
ryan
|
|
response 30 of 203:
|
Mar 6 20:35 UTC 2001 |
This response has been erased.
|
gull
|
|
response 31 of 203:
|
Mar 6 20:42 UTC 2001 |
I think we just happened to get a good deal on a bunch of 2-gig drives?
pfv's probably right. Adding space will only delay the problem, not fix it.
|
ryan
|
|
response 32 of 203:
|
Mar 6 20:49 UTC 2001 |
This response has been erased.
|
gull
|
|
response 33 of 203:
|
Mar 6 21:46 UTC 2001 |
The problem is never one twit filling the drive. It's that we get a
constant influx of twits who each fill a little chunk. Staff warns
them, but being twits they don't care, and the accounts generally aren't
deleted.
Anyway, from the looks of it we're going to talk this to death and
ultimately do nothing, again.
|
aruba
|
|
response 34 of 203:
|
Mar 6 21:50 UTC 2001 |
I feel the need to comment on Ryan's comment that Grex has a lot of money in
the bank: we do have money in the bank, but not as much as we used to. See
the treasurer's report for details. I think it's time we shed the notion
that Grex is rich.
|
ryan
|
|
response 35 of 203:
|
Mar 6 23:22 UTC 2001 |
This response has been erased.
|
scott
|
|
response 36 of 203:
|
Mar 6 23:23 UTC 2001 |
There *is* some kind of 2GB filesystem limit.
|
ryan
|
|
response 37 of 203:
|
Mar 7 15:12 UTC 2001 |
This response has been erased.
|
scott
|
|
response 38 of 203:
|
Mar 7 16:30 UTC 2001 |
Something like that.
|
keesan
|
|
response 39 of 203:
|
Mar 7 22:56 UTC 2001 |
Is there also a limit on number of partitions?
|
mdw
|
|
response 40 of 203:
|
Mar 7 23:21 UTC 2001 |
Yes.
|
keesan
|
|
response 41 of 203:
|
Mar 8 00:40 UTC 2001 |
Are you going to tell us this limit?
|
gull
|
|
response 42 of 203:
|
Mar 8 03:31 UTC 2001 |
Maybe you should call Sun and ask them. It seemed to work for
Ameritech.
|
other
|
|
response 43 of 203:
|
Mar 8 05:00 UTC 2001 |
There is a rational philosophy to keeping disk sizes small and numbers
great. To wit, the smaller disks limit the potential loss in the event
of disk failure.
The limiting factor then becomes the controllers and their connections to
the CPU.
We need to add another SCSI controller so we can add disk space by adding
more small (<=2GB) disks. We should not start obtaining and installing
much larger disks, because we do not have the resources for redundant
systems to protect larger disks from data loss.
|
scott
|
|
response 44 of 203:
|
Mar 8 12:15 UTC 2001 |
Re: 42
Regardless of how you feel about the now infamous Ameritech call, that was
just rude.
|
mdw
|
|
response 45 of 203:
|
Mar 8 17:53 UTC 2001 |
I thought I'd wait until somebody actually asked for the limit, although
it's readily available from !man sd or !man dkio, and NDKMAP in
/usr/include/sun/dklabel.h . I'm not sure if it's obvious from those,
but partition "c" is usually reserved to mean the whole disk, although
that's probably not a big issue.
Another limit is less obvious, and that's the number of access paths and
other performance constraints to a given amount of space. One 9 G drive
won't perform the same as 4 2 G drives, and for grex, that can be
important at times. We have extra sbus disk controllers, so in theory
there's no reason we can't have more than 7 scsi devices.
|
keesan
|
|
response 46 of 203:
|
Mar 8 19:01 UTC 2001 |
Thanks, Scott (43) but I think the response in 42 was due to my not putting
a :=) after my second question to make it obvious that I realized that Marcus
was playing 20 questions (his joke).
Or answering like a computer to a yes/no question. No hard feelings on my
part and I will try to make my jokes more obvious.
|
gull
|
|
response 47 of 203:
|
Mar 8 19:09 UTC 2001 |
I'm sorry. It was meant as a somewhat sarcastic joke. I understand Sindi
is only trying to help, but I sometimes get the impression that the only way
to make her happy would be to make her Dictator of Grex and let her set all
policy herself, from how the checking accounts are run right out to dialin
settings and disk space allocation.
|
pfv
|
|
response 48 of 203:
|
Mar 8 19:11 UTC 2001 |
Isn't there a login and logout script run for every user - telnet or
ssh? Someone care to illuminate this?
|
gull
|
|
response 49 of 203:
|
Mar 9 01:36 UTC 2001 |
It's shell-dependent, I think. csh will run .login and .logout,
respectively. bash will run .profile and (in some versions) .bashrc,
but I don't think it has a provision for a logout script. I could be
wrong, though.
|