friedl@vsi.COM (Stephen J. Friedl) (12/28/88)
Hi folks,
A customer of mine has a 3B2/600 running System V Release
3.2.1, with an Informix-SQL application (ver 2.10.00B). We just
converted the filesystem with the actual *large* database files
to be a 2kb filesystem, and the customer notices that everything
runs slower. I can imagine some hypothetical situations where
this would happen but am surprised that overall things are
slower.
Does anybody have any ideas on why this might be the case?
Any experiences with this?
Thanks
Steve
--
Stephen J. Friedl 3B2-kind-of-guy friedl@vsi.com
V-Systems, Inc. attmail!vsi!friedl
Santa Ana, CA USA +1 714 545 6442 {backbones}!vsi!friedl
Nancy Reagan on my new '89 Mustang GT Convertible: "Just say WOW!"denny@mcmi.UUCP (Dennis Page) (01/05/89)
In article <978@vsi.COM> friedl@vsi.COM (Stephen J. Friedl) writes: > A customer of mine has a 3B2/600 running System V Release >3.2.1, with an Informix-SQL application (ver 2.10.00B). We just >converted the filesystem with the actual *large* database files >to be a 2kb filesystem, and the customer notices that everything >runs slower. Did you test the rotation gap when you changed logical block sizes? What is the time difference between moving 1k & 2k blocks? Did they change mkfs to use *logical* gap size instead of physical (512) gap size? Did you check to make sure that the data area still begins on a cylinder boundary? (Twice the logical block size means twice the boundary size for superblock & inode tables.) So many questions! :-) Btw: Be wary of the possibility of mkfs using logical blocks for gapping and fsck using physical blocks. This nasty screwup, especially if you do fsck -s by habit. I don't know if AT&T 3.2 has this disease (I really doubt it -- they don't have it in 3.1.1) , but Unisys 3.x sure does. -- Good health is merely the slowest rate at which one can die.