Block Size Change

[dkellgren]

My research tells me that the optimal os Block Size for a Progress DB is 8k. The UNIX server that our Progress databases are served on was setup at 1k. I would assume that the only way to change it to 8k would be to re-setup the file systems.

Is there a better way?

Would it be a significant payoff?

TIA

 

[fpullen]

Hopefully your research includes looking at the application and the actual data stored. For some data, a 1KB block size makes sense. For other, 8KB makes sense. The answer is that it depends. To a certain extent, you're trading off disk space with performance, so it's important to look at what data is being stored.

Not sure what you mean by "re-setup the file systems." This sounds like an OS-level change--the disk partitions--whereas to change a database from 1KB to 8KB you need to do a dump and load. I'd recommend using the Progress bulk load utility, which will save you some time. You might want to think about defragging the disk partition, too; if the databases are the only things on that partition, it's not too hard to delete that partition and recreate it. That way, you're sure that the database is defragged, on both an OS- and a Progress-level.

Any questions, feel free to email me. I've only done this a few dozen times.

Regards,
--Fred Pullen

 

[dkellgren]

Thanks for the response...

By "re-setup" I'm thinking I could add a drive to my system, and when I setup the file system, do so as an 8k file system, rather than a 1k. Then I can setup my DB on that file system (and do so as an 8k DB).

I haven't read anything as to what to consider towards the "what data" is being stored. Do you mean one way is better for "writes" and the other is better for "reads"?

From what I've read, the 8k is always more advantageous.

? ? ? ? ? ? ?

-dk-

 

[fpullen]

> I haven't read anything as to what to consider
> towards the "what data" is being stored. Do you
> mean one way is better for "writes" and the other is
> better for "reads"?

No, what I meant was that if you're storing records which are likely to be less than 1KB, then you're possibly wasting a lot of space by using 8KB database blocks. For SyteLine--the ERP system I know best--8KB makes the most sense, because most large records such as order and invoice headers, jobs, etc. can fit in the 8KB space.

> From what I've read, the 8k is always more advantageous.

You might want to refer to Dan Foreman's guides; he's the recognized guru of such things. I've got his books around here somewhere, and will cite my source if/when I find 'em.

Regards,
--Fred

 

[dkellgren]

Thanks Fred... I actually just ordered the book today. And now I understand what you mean on the data size.

 

[toby.Harman]

Excuse my mis-understanding but you were asking about the *O/S* block size rather than the *DB* blocksize?

If this is true, then I believe the general recommendation is that the O/S block size should be an integer multiple of the Database blocksize, and I also think that the optimal multiple is 1.

This gets down to the problems with writes to the O/S of a single Progress block casuing multiple writes (when the O/S blocksize is smaller) or partial block writes (when the O/S blocksize is bigger).

The only way I know of to fix the O/S blocksize is to build a new filesystem and copy the database across. If it was the database blocksize then you would have to dump and load.

Toby Harman