|
|
| Author |
Message |
| 25 new of 292 responses total. |
hhsrat
|
|
response 156 of 292:
| 
Oct 30 03:28 UTC 1999 |
(Who's this General Protection dude, and why is everything always his
fault? :)
|
tpryan
|
|
response 157 of 292:
|
Oct 30 15:45 UTC 1999 |
He took over from General Mills.
|
krj
|
|
response 158 of 292:
|
Nov 3 05:28 UTC 1999 |
/a is almost full, someone in party was complaining about a lost
participationf ile.
|
gelinas
|
|
response 159 of 292:
|
Nov 3 06:09 UTC 1999 |
Well, it's at 100% right now, and my part file was merely corrupted. I've
not deleted it yet.
|
aruba
|
|
response 160 of 292:
|
Nov 3 13:44 UTC 1999 |
I lost my participation file to /a last night.
|
drew
|
|
response 161 of 292:
|
Nov 4 20:27 UTC 1999 |
Time to put in one of those extra hard drives, and move half of /a to it.
|
richard
|
|
response 162 of 292:
|
Nov 5 20:42 UTC 1999 |
Arrgh, are vandals attacking the /a drive again and filling it up?
Im getting a "bad participation file" message every time I log on, and
my conf bookmarks arent being kept upto date. How can I fix?
|
other
|
|
response 163 of 292:
|
Nov 5 20:56 UTC 1999 |
yeah, richard! quit taking up so much drive space! ;)
|
gull
|
|
response 164 of 292:
|
Nov 5 21:17 UTC 1999 |
Keep a big junk file around, so when the drive fills up, you can delete it
and get enough space to save your participation file. ;>
(I'm kidding. Don't do that, it's not polite.)
|
goose
|
|
response 165 of 292:
|
Nov 6 21:34 UTC 1999 |
HELLO STAFF?!? /a ihas now become a chronic problem.......
|
krj
|
|
response 166 of 292:
|
Nov 7 06:46 UTC 1999 |
Yes, the /a problem just trashed another participation file of mine.
|
sno
|
|
response 167 of 292:
|
Nov 7 15:29 UTC 1999 |
Why can't a link be used for certain groups' home directory to a known
viable space on another volume. It seems that waiting to repartition
doesn't fix the problem very fast.
|
jazz
|
|
response 168 of 292:
|
Nov 7 16:53 UTC 1999 |
I'd thought about that, or taking an additional step, and creating a
partition specifically for BBS partition files. The only advantage here is
that the volume would be easier to manage when conferences are dismanted (if
they are here, I haven't seen it happen, but it was a mess on m-net) - it's
still a limited volume and will still fill up. :)
|
scg
|
|
response 169 of 292:
|
Nov 7 17:20 UTC 1999 |
I switched newuser over yesterday so that it is now creating new accounts on
the /c partition instead. I fell asleep in the middle of trying to clear up
space on /a.
|
jazz
|
|
response 170 of 292:
|
Nov 7 17:43 UTC 1999 |
It's a tough job, Steve. Good luck. Have you considered changing the
reaping times for inactive accounts?
|
hematite
|
|
response 171 of 292:
|
Nov 8 04:08 UTC 1999 |
How does one get switch the new menu system back to the old one?
|
mcnally
|
|
response 172 of 292:
|
Nov 8 04:50 UTC 1999 |
Given that:
1) the people who intentionally vandalize the system by filling up
filesystems in a denial-of-service attack generally do so from
new accounts, not long-established ones, and that
2) "filesystem full" problems are of particular annoyance to conference
participants..
Would it be profitable to consider a home-directory allocation scheme
where long-established accounts with a history of mostly stable disk-
usage were grouped together on one or more partitions set aside for
the purpose? If the majority of long-time confer participants had home
directories which were physically segregated away from newuser accounts
it seems like many of the surprise filesystem problems which affect
Picospan users could be diverted..
|
orinoco
|
|
response 173 of 292:
|
Nov 8 05:13 UTC 1999 |
That sounds like it would just be inviting trouble, though. Who would
determine who gets to be a "special user" with a stable directory? Wouldn't
giving accounts which are likely to lose their participation files to new
users tend to make conferencing difficult for the people we're trying the
hardest to attract to the conferences?
It seems to me that the scheme John mentions in #168 would have a similar
effect -- putting all the participation files someplace away from all the
home directories would make vandalism less likely to trash them, right? --
but without discriminating between long-time conferencers and everyone
else. Then again, I may be wrong.
|
jazz
|
|
response 174 of 292:
|
Nov 8 12:44 UTC 1999 |
Well, never attribute to malicious hackers what can easily be explained
by thousands of bored "software engineers" and other twits.
|
richard
|
|
response 175 of 292:
|
Nov 8 18:08 UTC 1999 |
perhaps staff should identify these /a drive vandals and notify their
ISP's and block'em if they are all coming from the same place
|
tpryan
|
|
response 176 of 292:
|
Nov 8 20:02 UTC 1999 |
Or put a hard limit on the amount of disk space used by a
user?
|
pfv
|
|
response 177 of 292:
|
Nov 8 20:18 UTC 1999 |
Gee.. what happened to the grex "we have no problem[issue]" speeches?
|
mcnally
|
|
response 178 of 292:
|
Nov 8 20:28 UTC 1999 |
They vanished when you woke up.. Nobody's ever claimed that we don't
have problems on Grex. The fact that we don't all agree with your
approach to disk-space management doesn't mean that everyone thinks that
the situation can't be improved..
re #176: The problem with enabling quotas is largely one of computational
power -- the extra overhead for filesystem calls with quotas enabled on
user filesystems would probably swamp Grex's fairly feeble processor(s).
|
pfv
|
|
response 179 of 292:
|
Nov 8 20:30 UTC 1999 |
Aww, that was cute..
Yeah, sorry: quota is too CPU-intensive.
|
drew
|
|
response 180 of 292:
|
Nov 8 21:13 UTC 1999 |
I agree with Richard on this. ISP accounts are still mostly traceable to the
perpetrators, and any ISP with half a brain is going to take a dim view of
this sort of nonsense.
As for a separate partition, this can be resolved fairly, maybe, with a 30
day? 60 day? wait before being moved to the stable partition. Certainly worth
looking at. Clean up /a, then have all new arrivals start out on /b, and later
get moved to /d (or whatever name is available) when we get to know them
better.
As for quotas: has this been experimented with to see just how bad the CPU
hit would be? Perhaps a CPU upgrade is in order.
|
