New server migration

scooter6 at gmail.com scooter6 at gmail.com
Mon Feb 4 16:03:04 PST 2019


I converted /u to XFS
Before change with ext4
/home  3.9T  93M used  3.7T available
After change to xfs
/home  3.6T  33M used  3.6T available

Umounted /dev/xxxxxxx
I changed this with       mkfs.xfs /dev/xxxxxxx -f
Modified /etc/fstab and changed  /dev/xxxxxxx to xfs from ext4
Mounted /dev/xxxxxxx /u

Seems to have worked okay



On Mon, Feb 4, 2019 at 6:44 PM scooter6 at gmail.com <scooter6 at gmail.com>
wrote:

> 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/cbfba1b2/attachment.html>


More information about the Filepro-list mailing list