New server migration

Fairlight fairlite at fairlite.com
Mon Feb 4 10:54:14 PST 2019


Your biggest issue is that compat-libtermcap.i686 is not actually proper
for CentOS 7.  

It's been a year, so I'm fuzzy on the exact details of where we started
this, but my recollection says that it was a stub package which didn't work
because it relied upon something broken.  The answer was to pull down the
SRPM from CentOS 6, add 64-bit support, and compile for i686 (32-bit) as
opposed to x86_64.  I cannot legally offer you the binary RPMs or the spec
files with which I built them, or I would; there are contractual strictures
I must observe.

Also note that if you have large filesystems (> ~1TB on XFS), you've got
the potential for getting past the capability of 32-bit inode numbers, and
the getdents() call which filePro uses internally to populate the listbox
of all available filePro files in every binary will incorrectly report a
truncated entry.  How badly it's truncated depends upon where the 64-bit
inodes fall within the directory listing of $PFDIR.  If you really want
to be safe, you want to mount the XFS filesystem with the inode32 option.
This will cap you at about 4.7 billion files, but it will work reliably
for filePro.  This only becomes a problem after an XFS filesystem is large
enough to have -around- nine or more allocation groups.  You can see how
many allocation groups your filesystem has with xfs_info(1).  Below that
threshold, it's actually safe even with the default inode64 (also included
in 'defaults'), because each allocation group reserves about half a billion
inodes' worth.  The math says it should become a problem roughly partway
through using group 9 (about 40% through its 500 million), or the second
allocation group 10 is invoked.  For reference' sake, a 500GB filesystem
has 4 allocation groups, while a 1.3TB filesystem has 11.  It's a BTree+
self-balancing structure, so we know that the need for the groups is a
linear growth pattern, but I never bothered running the math to find out
exactly how large a filesystem you can create before invoking too many
allocation groups for filePro's stability.  

Note that inode32 is not actually good for performance on a spinning drive,
as it increases seek times due to the inode allocation layout.  On a VM
using SAN storage, or on an SSD, you should be fine.

m->


On Mon, Feb 04, 2019 at 10:22:59AM -0500, scooter6--- via Filepro-list thus spoke:
> Just purchased our new Dell PowerEdge server that I have installed CentOS 7
> on
> 
> Am migrating from older Dell PowerEdge that has Centos 5.10 on it
> 
> Is there a 'recipe book' anyone may have on steps to migrate all data etc?
> Can a simple copy of the fp directories etc do the trick or does the new
> server need to go through fpinstall ?
> 
> I know there are significant changes in CentOS from 5.10 to 6 and then to 7
> but in what I've read I don't think there too much of a concern for
> purposes of what we do here
> 
> Curious if anyone has done this similar migration and what to watch out for
> or best steps in order to make this as seamless as possible
> 
> Thanks for any insight
> 
> Scott
> PDM
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mailman.celestial.com/pipermail/filepro-list/attachments/20190204/2c5cd427/attachment.html>
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list
> 

-- 
Audio panton, cogito singularis.


More information about the Filepro-list mailing list