You are not logged in. Login Now
 0-24   25-49   50-56        
 
Author Message
janc
Increase User Disk Limit? Mark Unseen   Jul 16 14:35 UTC 2001

Last night I made some disk rearrangements that ended up just about doubling
the amount of disk space available for users on Grex.  If we needed more
space, it would take me only a few hours to double it again.  Just have to
turn on one of 4 other 4Gig drives that are already connected to Grex and
run some tests on them.  So basically we have more disk than we know what
to do with.

I think this situation will persist.  Even the 4 Gig disks we are adding onto
Grex now are tiny by modern standards.  With the cost of disk space what it
is, I don't think the old crunch is coming back unless we change our policies.

So I think it may be time to change our policies.

I strongly think we should increase the per-user limit on disk usage.  It is
currently set at a megabyte.  I think it should be increased to two megabytes
at least, possibly more.

Note that disk limits aren't enforced by the software on Grex, but manually
by staff.  We regularly scan for people who exceed the limit and ask them
to reduce usage.  Some people have been consistantly over the limit for
years.  We mostly vaguely tolerate them if they don't seem to be up to
anything malicious.

Also note that very users get anywhere near the disk limit.  Of 31605
users in the last scan (not counting most staff) we have:

        1 - 11 to 11.5 Meg
        0 - 10.5 to 11 Meg
        1 - 10 to 10.5 Meg
        0 - 9.5 to 10 Meg
        1 - 9 to 9.5 Meg
        0 - 8.5 to 9 Meg
        1 - 8 to 8.5 Meg
        0 - 7.5 to 8 Meg
        3 - 7 to 7.5 Meg
        2 - 6.5 to 7 Meg
        2 - 6 to 6.5 Meg
        2 - 5.5 to 6 Meg
        1 - 5 to 5.5 Meg
        1 - 4.5 to 5 Meg
        3 - 4 to 4.5 Meg
        4 - 3.5 to 4 Meg
        7 - 3 to 3.5 Meg
        8 - 2.5 to 3 Meg
       19 - 2 to 2.5 Meg
       38 - 1.5 to 2 Meg
      102 - 1 to 1.5 Meg
      771 - 0.5 to 1 Meg
    30638 - 0 to 0.5 Meg

So if we double the limit it isn't going to be like disk usage doubles.
Most users don't want to use any more disk than they are using already.
So I'd be tempted to move the limit to something like 4 Megs.

Another thing we could do is increase the time an account can be idle
without being reaped.  I think we currently reap accounts that have not
been used in 90 days.  I'm not sure that there is really much benefit
in lengthening that.

The other issue that comes up is our 'gif' policy.  We justified this on
the basis of disk and bandwidth limits.  Probably the bandwidth limitations
are still serious enough to justify it.
56 responses total.
gull
response 1 of 56: Mark Unseen   Jul 16 15:33 UTC 2001

It seems to me that history has shown that it will not take long before
accumulated copies of "eggdrop" will fill up any amount of free space.
remmers
response 2 of 56: Mark Unseen   Jul 16 16:41 UTC 2001

An argument for increasing the time-to-reap is the situation
of students who use Grex at school but are away from school,
and possibly Grex, for a four month spring/summer break.  In the
past, there have been instances of students losing their Grex
accounts because of that.  Increasing the limit from 90 to 150
or 180 days would correct that.
other
response 3 of 56: Mark Unseen   Jul 16 16:46 UTC 2001

Could we institute an allowance of image files with a maximum size of 10 
or 20k, and automatically enforce it?
keesan
response 4 of 56: Mark Unseen   Jul 16 17:26 UTC 2001

Do image files in your home directory (not linked to your website)
hurt anything?  And I agree with other about allowing small gifs even in www,
at least if they are not inline.  (Link to them from your home page).
keesan
response 5 of 56: Mark Unseen   Jul 16 17:28 UTC 2001

I have an 8K jpeg linked to my website (which might get five hits/month).
I support a 20K limit to let people put in small photos of themselves.
pfv
response 6 of 56: Mark Unseen   Jul 17 14:32 UTC 2001

If I might make a suggestion:

        The idea of "users" using small images on their "grex pages" is
        already a non-problem - they can point at images stored on their
        ISP's web-space or another machine. (This is how I used one on my
        own page).

        However, storing them all over user-space on grex could get ugly
        fairly quickly - among other things, they have to get them HERE
        and then they get fed out. Further, staff-time is already in
        limited supply: who is going to police the _content_, let alone
        the size-limits?

        As an alternative, you MIGHT want to create a "graphics space"
        and have folks submit graphics like they submit noises in party:
        to the admin for inclusion.

        Personally, I think allowing the graphics _ON_ Grex is prolly a
        mistake, but it's your call.
gull
response 7 of 56: Mark Unseen   Jul 17 14:35 UTC 2001

Hmm.  What kind of content are you worried about?  That someone will 
try to create a hot porn site on Grex?  That would certainly tend to 
swamp our Internet bandwidth quickly...
scott
response 8 of 56: Mark Unseen   Jul 17 14:44 UTC 2001

The graphics space idea is pretty good.
janc
response 9 of 56: Mark Unseen   Jul 17 16:25 UTC 2001

I think you can take it as a given that if we allow images, pornographic ones
will show up in quantity.  If you allow lots of images, then bursts of heavy
net traffic will follow when someone announces on IRC that they can get their
free porn fix there.

I personally don't particularly hate porn, but it isn't the industry I'm
hoping to support with my volunteer work here.  Our ban on images has let
us largely sidestep the porn issue.  Someday we are going to have to readdress
that though.
keesan
response 10 of 56: Mark Unseen   Jul 18 03:16 UTC 2001

Not everyone has either an ISP account or a friend with an ISP account who
is willing to post images there for them.  (We have two such friends who
posted pictures of us that they photographed).  People who are going to post
porn could do so right now, as far as I know, as there does not seem to be
any enforcement of current policy.  
janc
response 11 of 56: Mark Unseen   Jul 18 13:45 UTC 2001

The policy is enforced much the way the disk space policy is.  If space is
short we look for people using a lot of space.  Such people usually have
mountains of mail saved or things like eggdrop.  Sometimes they have gif
collections.  If we find them, we delete them.

We could probably build more effective enforcement, but it hasn't been a big
enough problem to be worth the trouble.
cmcgee
response 12 of 56: Mark Unseen   Jul 18 14:00 UTC 2001

After thinking about this for a while, I believe that all we can have is a
size limit, not a limit based on content (Sindi's "pictures of ourselves" 
policy).  To have someone view a file and "decide" whether it was a
picture of me as a Grex member, rather than me as a porn star, seems so
antithetical to Grex that I can't imagine even proposing to do it, much
less getting it passed as Grex policy, and finding staff willing to spend
time inforcing it. 

gull
response 13 of 56: Mark Unseen   Jul 18 14:47 UTC 2001

It does raise an interesting question.  You can actually make a bit of money
by putting up a bunch of porn on a site with some banner ads.  How should we
feel if someone does this on Grex, basically using Grex resources for free
to line their own pockets?
keesan
response 14 of 56: Mark Unseen   Jul 18 16:15 UTC 2001

Arachne has a feature that lets paying users delete banner ads.  Arachne is
a browser and grex is not, but could grex somehow also recognize banner ads
and delete any webpage containing them?  It is related somehow to their size
and shape.
pfv
response 15 of 56: Mark Unseen   Jul 18 18:45 UTC 2001

Further, nothing stops dufii from having "pics" of someone else - and this
can be embarassing, porn or whatever.

I reiterate above: having everyone on grex decide to stuff jpgs, gifs (which
can be animated - while others can't, afaik), and whatnot in THEIR space
makes it "our" (grex) space.

otoh, for those that want a pointer, or a texture or a pic, or whatever -
the thing to do SEEMS to be to submit to webadmin (or whatever) and add to a
global-space for global-use.

On the gripping hand, this (as previously mentioned as well) will certainly
affect the net-connection.

<shrug> Grex is not an ISP, never has been or claimed to be, Keesan.. Now,
if you want to try to con the borg into buying the idea of a "member" having
graphics space, so be it: those folks are already identified and NOT
"anonymous" - everyone else _IS_ presumed to be anonymous.

I'd also point out that, while porn itself would raise problems Grex would
NOT want to get involved in, there is also the idea of "business sites" and
, Bog knows, The haqueer/craqueer and artsy-fartsy types.

Now, does anyone know what sites are silly enough to offer FREE *graphic*
web-pages to anonymous users?
keesan
response 16 of 56: Mark Unseen   Jul 18 20:30 UTC 2001

Geocities, to anyone willingto sign up with them. (Yahoo).
I don't understand how an 8K jpeg affects band width any more than an 8K html
file, when they are both linked to a home page.  Please explain.
mdw
response 17 of 56: Mark Unseen   Jul 19 00:07 UTC 2001

It takes a lot of hard work to come up with an 8K html page that is
worth someone's while to read it.  It takes about 3 seconds with a
digital camera to come up with a 50K picture of one's cat, and the hard
part is squeezing it down to 8K without having it mutate into black
mold.
keesan
response 18 of 56: Mark Unseen   Jul 19 00:21 UTC 2001

My home page is twice as long as my jpeg - am I supposed to be breaking it
up into little pieces linked to index.htm?  My jpeg was produced by a digital
camera and some image-processing software (which clipped out a small portion
of the original photo).  Do white cats turn black when squeezed?
other
response 19 of 56: Mark Unseen   Jul 19 02:04 UTC 2001

only if you squeeze them the way you'd squeeze pencils to make cubic 
zirconia.
russ
response 20 of 56: Mark Unseen   Jul 19 02:23 UTC 2001

Instead of increasing user space or filesystem limits, is there
any chance that we could do RAID duplication of various filesystems?
It would be *so* nice to be able to absorb the failure of a disk
without having the system so much as burp.

Speaking of egg-bots and such, it occurs to me that anyone trying to
run such a thing is probably going to leave lots of traces.  There
will be incoming ftp traffic or a bunch of mail.  Is ftp traffic logged?
If so, it wouldn't be hard to look at the total volume and trip a daemon
to look at any account that goes over a threshold.  If the daemon finds
an egg-bot or the like, it notifies staff.  That would get rid of most
of the work of keeping the disk clean.

I'm sure that Pete would love to write such a daemon. ;-)
aruba
response 21 of 56: Mark Unseen   Jul 19 03:08 UTC 2001

I hope that eventually Grex will decide to allow users to store at least
some graphics here.  I don't think we can be all text forever, and graphics
are, after all, what makes the web so cool.  I like Pete's idea of having an
area for graphics and a procedure for submitting graphics to it.  The
sticking point may be deciding what limits to place on submissions, and
getting a volunteer to review submissions and enforce limits.
keesan
response 22 of 56: Mark Unseen   Jul 19 13:26 UTC 2001

Sort of like a clip-art library?
How about other users (members?) voting on which images to allow?
remmers
response 23 of 56: Mark Unseen   Jul 19 14:44 UTC 2001

Re #20:  Yes, ftp traffic is logged.  It's a good way to detect
such things as eggdrop uploads.

Re #21:  Realistically, I think that a submission and review
procedure for graphics is going to be unwieldy for a volunteer
system with so many users and so few personnel.
aruba
response 24 of 56: Mark Unseen   Jul 19 17:03 UTC 2001

I think we should try to find some sort of compromise between allowing anyone to put up any picture, and allowing no one to put up any pictures. In the future, at least, if not now. I think having a submission system would discourage a lot of the abuse we worry about when we consider our link being swamped with graphics.

If we can find a volunteer, maybe we should try it. If it doesn't work, we can try something else.

 0-24   25-49   50-56        
Response Not Possible: You are Not Logged In
 

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss