New server migration
scooter6 at gmail.com
scooter6 at gmail.com
Mon Feb 4 15:44:02 PST 2019
Mark,
So this really would only apply to the /u filesystem (that is 3.9TB) where
fP and data will be
The others can remain ext4 with no issues ? Or just best to convert all
ext4 file systems to XFS?
On Mon, Feb 4, 2019 at 6:10 PM Fairlight via Filepro-list <
filepro-list at lists.celestial.com> wrote:
> It really depends whether you're using 64-bit or 32-bit filePro binaries.
> If you're using 64-bit, you're fine in any event. If you're using 32-bit,
> I suspect you may run into inode number issues. I'd have to look up how
> ext4 handles its internal structure, and see if it's BTree+ as well in
> order to say definitively. Or do some testing.
>
> I would -never- willingly recommend ext4. The problem with ext4 is that it
> has a static inode table. If you create a filesystem of 'x' size (say
> 100GB), by default it allocates 'z' inodes. It's a steady default
> relationship between filesystem size and inode count. Two problems with
> this being static:
>
> 1) If you use heavily heirarchical filesystem structures for storage of
> data (think postfix-type queues or storage in nested directories), you will
> probably exhaust inode space well before you exhaust disk space. You can
> read 50% disk available, but be out of inodes and will be unable to write
> any new files. You can add data to existing files, but once you hit the
> inode limit, you're done adding files or directories. Which might not be
> so bad, if not for the fact that:
>
> 2) The inode table is so static that it is immutable, post-mkfs. It
> cannot be retuned by any means. If you allocate 1TB worth of disk to the
> filesystem, then later add 2TB (which it will happily let you do, and
> which obviously LVM2 supports with ease), you will -still- only have the
> same quantity of inodes to use under 3TB that you originally had under
> 1TB. There is no way around this, short of syncing the entire lot to
> another drive, redoing the whole filesystem from scratch with mkfs, and
> then syncing everything back. ext4 itself has no inherent accomodation for
> increasing the inode table size. None.
>
> Do yourself a huge favour, and rework it using XFS if you care about
> maintaining scalability.
>
> m->
>
>
> On Mon, Feb 04, 2019 at 03:08:24PM -0500, scooter6 at gmail.com thus spoke:
> > Just to add - I installed CentOS 7 on RAID 10 hardware RAID on the new
> > Dell PowerEdge
> > I have the OS installed at this point and this is as far as I've
> gotten
> > The server has four (4) 2TB NLSAS hot plug hard drives
> > I installed all filesystems as ext4 -- I allowed Centos to partition
> > automatically this leaves with a 3.9TB /u file system that is ext4
> > Would you recommend a different filesystem?
> >
> > On Mon, Feb 4, 2019 at 2:36 PM Scott Walker via Filepro-list
> > <[1]filepro-list at lists.celestial.com> wrote:
> >
> > Mark,
> > Brian White was nice enough to help us out with this last year.
> > This is from my notes:
> > CentOS Version 7Â Installation Issues
> > --------------------------------------------------------------------
> > --------
> > --------------------------------------------------------------
> > You must have libtermcap.so.2 installed!
> >  On CentOS 7 you must first install libc.so.6
> > Â Â Â Â yum install libc.so.6
> > Then install:
> > Â Â Â Â rpm -ivh
> > compat-libtermcap-2.0.8-50flt.el7.centos.i686.rpm
> > The above file was provided by Brian. I can email you a copy if
> > desired.
> > Regards,
> > Scott Walker
> > [2]scott.walker at ramsystemscorp.com
> > -----Original Message-----
> > From: Filepro-list
> > [mailto:
> [3]filepro-list-bounces+scottwalker=ramsystemscorp.com at lists
> > .celestial.
> > com] On Behalf Of Fairlight via Filepro-list
> > Sent: Monday, February 4, 2019 1:58 PM
> > To: [4]filepro-list at lists.celestial.com
> > Subject: Re: New server migration
> > My previous comments about XFS were for 32-bit binaries. The bit
> > depth is
> > important, as even 6.0.0 comes in both 32-bit and 64-bit. If
> > you're running
> > 64-bit, you can use inode64 on any filesystem size, and it shouldn't
> > cause
> > issues.
> > If you're running 64-bit binaries, compat-libtermcap may still be an
> > issue
> > (probably is). I'd have to revisit that directly to confirm or
> > deny. I
> > remember that the i686 architecture build target did not exist in
> > the spec
> > file I got from the official SRPM, but that's only necessary if you
> > run
> > 32-bit binaries. The package itself likely still needs to be built
> > properly, so you're not relying on what I remember as being the
> > default
> > broken configuration.
> > m->
> > On Mon, Feb 04, 2019 at 11:02:34AM -0500, scooter6--- via
> > Filepro-list thus
> > spoke:
> > > To clarify, this is with fP 5.6.10R4
> > >
> > >
> > >
> > > On Mon, Feb 4, 2019 at 10:22 AM [5]scooter6 at gmail.com
> > > <[6]scooter6 at gmail.com>
> > > wrote:
> > >
> > > > 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:
> > >
> > <[7]
> http://mailman.celestial.com/pipermail/filepro-list/attachments/
> > 20190
> > > 204/1b6775da/attachment.html>
> > > _______________________________________________
> > > Filepro-list mailing list
> > > [8]Filepro-list at lists.celestial.com
> > > Subscribe/Unsubscribe/Subscription Changes
> > > [9]http://mailman.celestial.com/mailman/listinfo/filepro-list
> > >
> > --
> > Audio panton, cogito singularis.
> > _______________________________________________
> > Filepro-list mailing list
> > [10]Filepro-list at lists.celestial.com
> > Subscribe/Unsubscribe/Subscription Changes
> > [11]http://mailman.celestial.com/mailman/listinfo/filepro-list
> > _______________________________________________
> > Filepro-list mailing list
> > [12]Filepro-list at lists.celestial.com
> > Subscribe/Unsubscribe/Subscription Changes
> > [13]http://mailman.celestial.com/mailman/listinfo/filepro-list
> >
> > References
> >
> > 1. mailto:filepro-list at lists.celestial.com
> > 2. mailto:scott.walker at ramsystemscorp.com
> > 3. mailto:filepro-list-bounces%2Bscottwalker
> > 4. mailto:filepro-list at lists.celestial.com
> > 5. mailto:scooter6 at gmail.com
> > 6. mailto:scooter6 at gmail.com
> > 7.
> http://mailman.celestial.com/pipermail/filepro-list/attachments/20190
> > 8. mailto:Filepro-list at lists.celestial.com
> > 9. http://mailman.celestial.com/mailman/listinfo/filepro-list
> > 10. mailto:Filepro-list at lists.celestial.com
> > 11. http://mailman.celestial.com/mailman/listinfo/filepro-list
> > 12. mailto:Filepro-list at lists.celestial.com
> > 13. http://mailman.celestial.com/mailman/listinfo/filepro-list
>
> --
> Audio panton, cogito singularis.
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.celestial.com/pipermail/filepro-list/attachments/20190204/d62f4f88/attachment.html>
More information about the Filepro-list
mailing list