Dnet to move to free bsd...

Adul

Elite Member
Oct 9, 1999
32,999
44
91
danny.tangtam.com
From bwilson@distributed.net plan file. june 10th



<< Hello again.

As long as we had tally off-line to expand the database, decibel and I
decided to perform some much needed maintenance. We rebuilt some of the
indexes on the tables we torture the most, and updated statistics on The
Big Table (that's the detail table for RC5-64). For comparison, this one
table occupies almost 3GB, which is about 80% of the data in the stats
database, and nearly one fourth of the total disk on tally.

We had hoped this wouldn't be necessary - we had hoped to be moved over
to the new server (blower) by now. Technology and time schedules prevented
us from completing the migration. The 2GB file size limit on Linux is
starting to be a real problem. All the stats folks are getting together
by phone soon to discuss the possibility of switching to Free BSD. This
option would give us more room to grow, but would not (easily) support
some of our current tools. I think we're leaning that direction, but we
don't want to backtrack that far just to find it's not going to work.

Another maintenance task I performed was to purge many of the teams that
had been created but never used. This is mostly our fault - the
team-creation forms on the website make it easy for people to create a
team and then forget how to join it. Over the years, many people have
created a team several times in a row, never succeeding in joining. This
purge had never been performed in the past, to my knowledge, so it was
long overdue.

Rest assured, I have only purged those teams that never had any work
submitted, never had any members, and do not currently have any members.
I also preserved any empty team created in the last several months, just
in case the work is being saved up to submit in the near future. Even as
careful as I was, it turns out over half the teams in the table were
completely inactive. I saved an archive of the removed teams, but being
in a different SQL table, they will have less impact on statsrun. If by
some chance, you had created a team and I have removed it, please e-mail
me directly to have it replaced.

The next time we have occasion to modify the team-creation code, we'll
add a date-created field to the teams table and establish a policy where
teams will be removed if no work is submitted in a certain time-frame.

That's all the news that's fit to print. Thanks again for all the cycles.
>>

 

narzy

Elite Member
Feb 26, 2000
7,006
1
81
hell they would be better off with win2k and SQL server 2000. let zuni do the programming for them :)
 

Fandu

Golden Member
Oct 9, 1999
1,341
0
0
Wouldn't it be easier to switch statsbox over to one of the journaling file systems?

Although I do think a re-write of the stats software is a good thing. It seems to me that having the statsbox to stats in real time would greatly reduce the load on it, and the statsaholics would be able to get their fix.
 

Hawkeye_(BEL)

Banned
Dec 24, 1999
364
0
0
Fandu,

the filesystem has nothing to do with the maximum size of files, it's the kernel that's responsible for that.

EXT2, ReiserFS, XFS, JFS,... all share that pesky 2Gb file limit :(
 

Hawkeye_(BEL)

Banned
Dec 24, 1999
364
0
0
The stock 2.4.3 kernel still has the problem. I don't think it has changed in 2.4.4 or 2.4.5, since such an important feature would've surely been added to 2.4.0, and I can't find anything about it in the Changelog...

However, DNet should know that the FreeBSD filesystem is EXTREMELY slow compared to EXT2, because it's a synced system (to improve reliability in the case of a power dropout), whereas all other filesystems are asynced.
 

ottawanker

Member
Nov 21, 2000
180
0
0
There are (kernel) patches for 2.2.x and 2.4.x to support files over 2 gigs.. for example, redhat enterprise edition apparantly has these patches.. it shouldn't be that big a deal.
 

Hawkeye_(BEL)

Banned
Dec 24, 1999
364
0
0
Apperently, 2.4.x kernels do support larger filesizes than 2Gb according to this.

And according to this, it's not a kernel issue at all, but more of a glibc issue.

There are indeed some patches that seem to get you above that limit: http://www.suse.de/~aj/linux_lfs.html. And here's a quote from a GNUpgp mailinglist :


<< > I have been having some problems decrpting large files (over 4 gig).

This problem is probably due to a long overflow in fseek(FILE*, long, int).
There is no easy solution for that, except compiling both OS and Gnupg
anainst a libc that uses 64 (or higher) bit longs.
>>



All in all, it seems possible to have files larger than 2Gb on Linux, but the hassle it'll put you through simply doesn't seem worth it...

[edit: fixed a broken link]