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