FILE vs. MDB

HiddenWarrior · 2004-02-19, 03:52

I came to idea that it will be great if Prime95 will store all processing data (content of p* and q* files) not in files but in database (Microsoft Access for example .mdb). There are some positive reasons for that:
1. No data loss. For example, when working with file, some data in it can be lost due to bad disk fragmentation. Some time ago I have to redo 5 million iterations of LLT on 33M exponent coz p* file got some errors when was written... There are no such problem with databases.
2. Sometimes it is faster to read/write from/to database than from file.

Comments?

dsouza123 · 2004-02-19, 04:38

Databases have the same problems.

Databases are saved as files unless they only exist in memory, if it is just in memory then a power outage would wipe it out.
It could be a fast write to memory with a delayed write to disk.

When databases crash they also lose information.

The speed of writing to a database that is stored on disk is dependent on
the efficiency of the disk writing code and other things, so writing a single
file should be faster if the disk writing code is efficient because the database
has to get the information, format it, write to disk and update other information in the database.

Maybe the p and q files should be written twice, ( one copy may be good ).
Or written slower or verified. Maybe if it were written in numbered packets
(like tcp) the size of a disk cluster, they could be found and resequenced easier if lost.
Each packet would have the exponent, iteration, packet number and chunk of data.

Disk fragmentation doesn't cause a file to be corrupt, it just makes it hard or impossible to put it back together if deleted.

Usually a disk has lost clusters or some other file system problem if it is losing parts of a file.

There is a possibility of bugs in the routine to write or read the p and q files,
but is unlikely because many people use them without problems.
Unless it is a very subtle bug that can only surface with very rare conditions.

2004-02-19, 03:52	#1
HiddenWarrior Jun 2003 Russia, Novosibirsk 2×107 Posts	FILE vs. MDB I came to idea that it will be great if Prime95 will store all processing data (content of p* and q* files) not in files but in database (Microsoft Access for example .mdb). There are some positive reasons for that: 1. No data loss. For example, when working with file, some data in it can be lost due to bad disk fragmentation. Some time ago I have to redo 5 million iterations of LLT on 33M exponent coz p* file got some errors when was written... There are no such problem with databases. 2. Sometimes it is faster to read/write from/to database than from file. Comments?

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
P-1 File Name Bug	NBtarheel_33	Software	2	2010-06-06 08:29
WorkToDo File	storm5510	Software	9	2009-08-18 00:18
Dat File?	Xentar	Sierpinski/Riesel Base 5	10	2008-06-23 02:09
Sieve dat file	em99010pepe	Sierpinski/Riesel Base 5	13	2006-12-05 01:50
How to change Pxxxx.001 file to Pxxxx file?	edorajh	Software	3	2003-12-31 12:30

2004-02-19, 04:38	#2
dsouza123 Sep 2002 2×331 Posts	Databases have the same problems. Databases are saved as files unless they only exist in memory, if it is just in memory then a power outage would wipe it out. It could be a fast write to memory with a delayed write to disk. When databases crash they also lose information. The speed of writing to a database that is stored on disk is dependent on the efficiency of the disk writing code and other things, so writing a single file should be faster if the disk writing code is efficient because the database has to get the information, format it, write to disk and update other information in the database. Maybe the p and q files should be written twice, ( one copy may be good ). Or written slower or verified. Maybe if it were written in numbered packets (like tcp) the size of a disk cluster, they could be found and resequenced easier if lost. Each packet would have the exponent, iteration, packet number and chunk of data. Disk fragmentation doesn't cause a file to be corrupt, it just makes it hard or impossible to put it back together if deleted. Usually a disk has lost clusters or some other file system problem if it is losing parts of a file. There is a possibility of bugs in the routine to write or read the p and q files, but is unlikely because many people use them without problems. Unless it is a very subtle bug that can only surface with very rare conditions.