|
Grex > Coop11 > #36: Increasing User Disk Space Maximum | |
|
| Author |
Message |
| 25 new of 111 responses total. |
steve
|
|
response 39 of 111:
| 
Oct 29 16:34 UTC 1998 |
Thats difficult to do. There is a concept in many version of UNIX
called quotas, which can limit the disk space that a user can have,
but the quota code on SunOS is not good, and worse yet even if it
worked perfectly it slows disk writes, as each write has to be checked
against the limit for that uid.
Putting a limit on how much data you could move out of Grex is
almost impossible. Every method of transporting data, (FTP, all
the x,y,z modem programs, cat, and anything else that could display
data) would have to be taught how to do this. Sometimes, a seemingly
simple idea like placing limits is next to impossible. Now, we could
do this, but only at the cost of dampening the freedoms that accounts
here have. If we restricted things to a meny system, then we could
do this, but change what Grex is.
|
rcurl
|
|
response 40 of 111:
|
Oct 30 04:44 UTC 1998 |
Accounts do not have disk space freedoms. I am speaking of balancing
freedoms, not diminishing the total. (I have to accept the stated
technical difficulties, but there is still room to discuss the principles,
I hope.)
|
valerie
|
|
response 41 of 111:
|
Nov 2 15:57 UTC 1998 |
This response has been erased.
|
remmers
|
|
response 42 of 111:
|
Nov 2 17:18 UTC 1998 |
Interesting. That would be a much lower-overhead approach, if it's
feasible, since you'd only be checking quotas once a day instead of
on every disk write.
I can see problems with doing this under SunOS. Unix bases both
file create and file delete on the 'w' permission bit. If you have
write permission in a directory, you can both create and delete
files in it. If you don't have write permission, you can't do
either.
But you might be able to set up something quite similar. One
possible approach would be to run a program once a day that checks
users' disk usage and *changes their login shell* if they're
over. The replacement shell would only let them (1) list files,
(2) delete files, and (3) run a program that re-checks their usage
and gives them their old shell back if they're under the limit.
The above is off the top of my head. Feel free to shoot it down.
One problem is that it wouldn't prevent ftp uploads. But I can
think of a possible way to address that.
|
albaugh
|
|
response 43 of 111:
|
Nov 2 18:53 UTC 1998 |
The delete-only option is harsh. What if someone wanted to make a backup
copy of the file, transfer it, compress it? It should at least be readable.
In that case, a user could, say, copy the file to /tmp, compress it, remove
the uncompressed version from his home directory, and then, if he had enough
space, he could transfer the compressed version back.
|
mdw
|
|
response 44 of 111:
|
Nov 2 19:56 UTC 1998 |
Thrashing through the disk measuring people's disk usage isn't "low
overhead".
|
remmers
|
|
response 45 of 111:
|
Nov 3 01:57 UTC 1998 |
Not when you're doing it, I suppose. You'd want to not be doing it most
of the time.
|
rcurl
|
|
response 46 of 111:
|
Nov 3 02:55 UTC 1998 |
Everyone seems to agree that disk is cheap, and yet the proposals keep
coming back to punishing the users of disk space, instead of addressing
the real problem, which is the limits on the ISDN link. The discussion
should be of measuring people's link usage or thrashing through the
link traffic. The discussion reminds me a bit of the story...
As was seen stumbling around a streetlight looking like he had lost
something. A kind pedestrian stopped and asked if he could help, and
the drunk told him he had lost his care key. The kind pedestrian
looked around with the drunk for a while and then asked "where exactly
did you lose the key?". The drunk said, "over there, across the street".
The kind pedestrian of course asked, "then why are you looking for it
here"? The drunk answered - "because the light is better over here".
|
remmers
|
|
response 47 of 111:
|
Nov 3 10:36 UTC 1998 |
Disk may be cheap, but talk is cheaper.
|
rcurl
|
|
response 48 of 111:
|
Nov 3 17:07 UTC 1998 |
That's why we are all here.... 8^}
|
valerie
|
|
response 49 of 111:
|
Nov 3 20:11 UTC 1998 |
This response has been erased.
|
rcurl
|
|
response 50 of 111:
|
Nov 4 07:13 UTC 1998 |
I did? I started this item to argue for a larger disk quota. I have since
asked why not implement e-mail (or link use) quotas too, to balance the
"freedoms" that users have. I have been under the impression that disk
quotas are on now - implemented by hand.
Why not buy more disk space rather than freeing up just a little from
some users? Then everyone can have more.
|
scott
|
|
response 51 of 111:
|
Nov 4 11:44 UTC 1998 |
(Psst...Rane... If you download your accumulated mail onto one of your own
machines, you can access it without having to connect to Grex)
|
valerie
|
|
response 52 of 111:
|
Nov 4 13:18 UTC 1998 |
This response has been erased.
|
keesan
|
|
response 53 of 111:
|
Nov 4 15:37 UTC 1998 |
I will download half the files in my home directory to my own machine, now
that I figured out where the empty space is on my hard disk. Thanks Scott.
|
rcurl
|
|
response 54 of 111:
|
Nov 4 20:16 UTC 1998 |
(Re #51: psst...that is much less convenient for retrieving, editing and
forwarding pieces of past mail, which is my main use for the mail I
keep on Grex - I do not just hoard it, I use it. Also, I have offered to
pay for another MB of disk space...I'll even offer to pay 1000% of the
cost (that would be, oh, about 75 cents)).
How about just doubling the allowed disk space to 2 MB, and see what happens
(and buy more disk space). At the same time, implement the automatic
limit on disk use (and for link use too). Then, people would know what the
automatic consequences would be when theyt 'grow' into the new space, and
I expect there would be less grumbling about having the limits enforced
automatically.
|
steve
|
|
response 55 of 111:
|
Nov 4 23:24 UTC 1998 |
The 1M limit was arbitrary, but an incredibly generous one, even
by todays standards. I don't think there is another shell account
system on the net today that is as free with disk as we are. No,
we're not really a "shell account" system, but still close enough.
1G divided by 1M is only 1000. Right now, Grex has about 23,000
accounts. By "normal" system admin figures, we're doing it all
wrong already and not conserving disk enough. Thats OK with me
however, as its the Grex way.
Yes, we will get more disk--I don't think there is any way we
can avoid that. And, with prices making their ever downward
spiral, we shouldn't have to spend a large amount for it. The
part about this that worries me is the extra staff impact that
more disk has, namely backups. It costs money for the tapes to
back disk up, and costs the more valuable comodity of staff time
to do this. One of the things we might think about in the not
too distant future is the position of "operator", someone who is
1) trusted, 2) able to work correctly on their own, 3) knows when
to ask for help when "weirdness" arrises, 4) is able to do things
on a periodic basis. That should largely solve the backup issue
in terms of time.
The other issue, one that I'm trying to get data on, is how
big a disk we can put on Grex. Today we can get a large SCSI
disk easily, but I want to know exactly what others have done
with this first, before we spend any money on a disk and find
out that it won't work here.
|
janc
|
|
response 56 of 111:
|
Nov 6 02:53 UTC 1998 |
Hmm...I don't know enough about SCSI, but I seem to recall that our SCSI
controller is unable to handle some newer disks. Something about not
being "Fast" or "Wide" or "Ultra" or something. If this is true, then
we are limited to using older disks, whose price doesn't drop as fast,
so disk space isn't as cheap as all that. There must be a way around
this - an alternate SCSI controller on the Sbus maybe?
|
mdw
|
|
response 57 of 111:
|
Nov 6 04:01 UTC 1998 |
There are several kinds of scsi. Some are compatible with others,
others not. I don't think, for our purposes, that makes sense to get
anything that won't plug in and work with the existing cpu scsi
controller; the difference in cost is unlikely to pay for the different
controller.
|
steve
|
|
response 58 of 111:
|
Nov 6 13:14 UTC 1998 |
We're compatible with standard SCSI-2 hardware--that isn't the issue.
There are lots of fast SCSI devices that can work in their backwards
compatible mode, as well. What I'm concered with is the size of the
disk. I believe there is a 2G per partition limit on this version of
SunOS, and there is a limit on how big a disk SunOS can talk to, to
make those 2G partitions. If we can use a 9G SCSI-2 disk and break it
into several 2G partitions that would be great. I haven't talked to
anyone who's done that, yet. So thats my question. Sure, we could go
out tomorrow and get a 2G SCSI disk, but I'd like to get much bigger
ones if we can. I think this is possible but I want confirmation first.
|
janc
|
|
response 59 of 111:
|
Nov 10 05:55 UTC 1998 |
Lots of people are still running 4.1.4 BSD or older. If it is possible
to use bigger disks, lots of people must be doing it. Maybe I'll ask on
the Suns@Home mailing list.
|
valerie
|
|
response 60 of 111:
|
Nov 12 17:28 UTC 1998 |
This response has been erased.
|
rcurl
|
|
response 61 of 111:
|
Nov 12 22:43 UTC 1998 |
What alerts the staff to excessive disk? Can't that be automated (with
suitable warnings)?
I never expected a computer guru to say "there is no way....". ;)
|
davel
|
|
response 62 of 111:
|
Nov 13 02:25 UTC 1998 |
Well, she *said* that, but if you read closely, aside for the "strange bugs"
side remark, the accurate analysis is "will bring Grex to its knees". I for
one think that's a good reason for not doing it. (And I believe Valerie's
analysis is correct, but don't have any direct experience.)
|
scg
|
|
response 63 of 111:
|
Nov 13 08:33 UTC 1998 |
The SunOS quota software has to check how much disk space a user is using
before every time it writes something to their home directory. That will slow
disk writes way down, which in turn will slow everything else way down as
things wait for the disk writes. We don't want to do that.
The processes staff members use to find excessive disk hogs could be
automated. We couldn't run them all the time, since it would slow things way
down, but we could have it run automatically once a week. There is then the
question of what to do when it discovers that a user is over their quota.
Having it go in and delete random stuff would be a bad idea. Having it send
them mail might do something, but would probably be somewhat ineffective.
What might make more sense would be for it to change the permissions on their
home directory such that they couldn't save stuff to it, but that runs into
problems too. Staff has discussed all of those options. It's possible that
we might do something like this in the future, but none of those are easy
solutions.
|