<div dir="ltr"><div>I converted /u to XFS </div><div>Before change with ext4</div><div>/home  3.9T  93M used  3.7T available</div><div>After change to xfs</div><div>/home  3.6T  33M used  3.6T available</div><div><br></div><div>Umounted /dev/xxxxxxx</div><div>I changed this with       mkfs.xfs /dev/xxxxxxx -f</div><div>Modified /etc/fstab and changed  /dev/xxxxxxx to xfs from ext4</div><div>Mounted /dev/xxxxxxx /u</div><div><br></div><div>Seems to have worked okay</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div class="gmail_attr" dir="ltr">On Mon, Feb 4, 2019 at 6:44 PM <a href="mailto:scooter6@gmail.com">scooter6@gmail.com</a> <<a href="mailto:scooter6@gmail.com">scooter6@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir="ltr"><div>Mark,</div><div><br></div><div>So this really would only apply to the /u filesystem (that is 3.9TB) where fP and data will be</div><div>The others can remain ext4 with no issues ? Or just best to convert all ext4 file systems to XFS?</div></div><br><div class="gmail_quote"><div class="gmail_attr" dir="ltr">On Mon, Feb 4, 2019 at 6:10 PM Fairlight via Filepro-list <<a href="mailto:filepro-list@lists.celestial.com" target="_blank">filepro-list@lists.celestial.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">It really depends whether you're using 64-bit or 32-bit filePro binaries.<br>
If you're using 64-bit, you're fine in any event.  If you're using 32-bit,<br>
I suspect you may run into inode number issues.  I'd have to look up how<br>
ext4 handles its internal structure, and see if it's BTree+ as well in<br>
order to say definitively.  Or do some testing. <br>
<br>
I would -never- willingly recommend ext4.  The problem with ext4 is that it<br>
has a static inode table.  If you create a filesystem of 'x' size (say<br>
100GB), by default it allocates 'z' inodes.  It's a steady default<br>
relationship between filesystem size and inode count.  Two problems with<br>
this being static:<br>
<br>
1) If you use heavily heirarchical filesystem structures for storage of<br>
data (think postfix-type queues or storage in nested directories), you will<br>
probably exhaust inode space well before you exhaust disk space.  You can<br>
read 50% disk available, but be out of inodes and will be unable to write<br>
any new files.  You can add data to existing files, but once you hit the<br>
inode limit, you're done adding files or directories.  Which might not be<br>
so bad, if not for the fact that:<br>
<br>
2) The inode table is so static that it is immutable, post-mkfs.  It<br>
cannot be retuned by any means.  If you allocate 1TB worth of disk to the<br>
filesystem, then later add 2TB (which it will happily let you do, and<br>
which obviously LVM2 supports with ease), you will -still- only have the<br>
same quantity of inodes to use under 3TB that you originally had under<br>
1TB.  There is no way around this, short of syncing the entire lot to<br>
another drive, redoing the whole filesystem from scratch with mkfs, and<br>
then syncing everything back. ext4 itself has no inherent accomodation for<br>
increasing the inode table size.  None.<br>
<br>
Do yourself a huge favour, and rework it using XFS if you care about<br>
maintaining scalability.<br>
<br>
m-><br>
<br>
<br>
On Mon, Feb 04, 2019 at 03:08:24PM -0500, <a href="mailto:scooter6@gmail.com" target="_blank">scooter6@gmail.com</a> thus spoke:<br>
>    Just to add - I installed CentOS 7 on RAID 10 hardware RAID on the new<br>
>    Dell PowerEdge<br>
>    I have the OS installed at this point and this is as far as I've gotten<br>
>    The server has four (4) 2TB NLSAS hot plug hard drives<br>
>    I installed all filesystems as ext4 -- I allowed Centos to partition<br>
>    automatically this leaves with a 3.9TB /u file system that is ext4<br>
>    Would you recommend a different filesystem?<br>
> <br>
>    On Mon, Feb 4, 2019 at 2:36 PM Scott Walker via Filepro-list<br>
>    <[1]<a href="mailto:filepro-list@lists.celestial.com" target="_blank">filepro-list@lists.celestial.com</a>> wrote:<br>
> <br>
>      Mark,<br>
>      Brian White was nice enough to help us out with this last year.<br>
>      This is from my notes:<br>
>      CentOS Version 7  Installation Issues<br>
>      --------------------------------------------------------------------<br>
>      --------<br>
>      --------------------------------------------------------------<br>
>      You must have libtermcap.so.2 installed!<br>
>      Â On CentOS 7 you must  first install libc.so.6<br>
>      Â  Â  Â  Â  yum install libc.so.6<br>
>      Then install:<br>
>      Â  Â  Â  Â  rpm -ivh<br>
>      compat-libtermcap-2.0.8-50flt.el7.centos.i686.rpm<br>
>      The above file was provided by Brian.  I can email you a copy if<br>
>      desired.<br>
>      Regards,<br>
>      Scott Walker<br>
>      [2]<a href="mailto:scott.walker@ramsystemscorp.com" target="_blank">scott.walker@ramsystemscorp.com</a><br>
>      -----Original Message-----<br>
>      From: Filepro-list<br>
>      [mailto:[3]filepro-list-bounces+scottwalker=ramsystemscorp.com@lists<br>
>      .celestial.<br>
>      com] On Behalf Of Fairlight via Filepro-list<br>
>      Sent: Monday, February 4, 2019 1:58 PM<br>
>      To: [4]<a href="mailto:filepro-list@lists.celestial.com" target="_blank">filepro-list@lists.celestial.com</a><br>
>      Subject: Re: New server migration<br>
>      My previous comments about XFS were for 32-bit binaries.  The bit<br>
>      depth is<br>
>      important, as even 6.0.0 comes in both 32-bit and 64-bit.  If<br>
>      you're running<br>
>      64-bit, you can use inode64 on any filesystem size, and it shouldn't<br>
>      cause<br>
>      issues.<br>
>      If you're running 64-bit binaries, compat-libtermcap may still be an<br>
>      issue<br>
>      (probably is).  I'd have to revisit that directly to confirm or<br>
>      deny.  I<br>
>      remember that the i686 architecture build target did not exist in<br>
>      the spec<br>
>      file I got from the official SRPM, but that's only necessary if you<br>
>      run<br>
>      32-bit binaries.  The package itself likely still needs to be built<br>
>      properly, so you're not relying on what I remember as being the<br>
>      default<br>
>      broken configuration.<br>
>      m-><br>
>      On Mon, Feb 04, 2019 at 11:02:34AM -0500, scooter6--- via<br>
>      Filepro-list thus<br>
>      spoke:<br>
>      > To clarify, this is with fP 5.6.10R4<br>
>      ><br>
>      ><br>
>      ><br>
>      > On Mon, Feb 4, 2019 at 10:22 AM [5]<a href="mailto:scooter6@gmail.com" target="_blank">scooter6@gmail.com</a><br>
>      > <[6]<a href="mailto:scooter6@gmail.com" target="_blank">scooter6@gmail.com</a>><br>
>      > wrote:<br>
>      ><br>
>      > > Just purchased our new Dell PowerEdge server that I have<br>
>      installed<br>
>      > > CentOS<br>
>      > > 7 on<br>
>      > ><br>
>      > > Am migrating from older Dell PowerEdge that has Centos 5.10 on<br>
>      it<br>
>      > ><br>
>      > > Is there a 'recipe book' anyone may have on steps to migrate all<br>
>      data<br>
>      etc?<br>
>      > > Can a simple copy of the fp directories etc do the trick or does<br>
>      the<br>
>      > > new server need to go through fpinstall ?<br>
>      > ><br>
>      > > I know there are significant changes in CentOS from 5.10 to 6<br>
>      and<br>
>      > > then to<br>
>      > > 7 but in what I've read I don't think there too much of a<br>
>      concern<br>
>      > > for purposes of what we do here<br>
>      > ><br>
>      > > Curious if anyone has done this similar migration and what to<br>
>      watch<br>
>      > > out for or best steps in order to make this as seamless as<br>
>      possible<br>
>      > ><br>
>      > > Thanks for any insight<br>
>      > ><br>
>      > > Scott<br>
>      > > PDM<br>
>      > ><br>
>      > -------------- next part -------------- An HTML attachment was<br>
>      > scrubbed...<br>
>      > URL:<br>
>      ><br>
>      <[7]<a href="http://mailman.celestial.com/pipermail/filepro-list/attachments/" target="_blank" rel="noreferrer">http://mailman.celestial.com/pipermail/filepro-list/attachments/</a><br>
>      20190<br>
>      > 204/1b6775da/attachment.html><br>
>      > _______________________________________________<br>
>      > Filepro-list mailing list<br>
>      > [8]<a href="mailto:Filepro-list@lists.celestial.com" target="_blank">Filepro-list@lists.celestial.com</a><br>
>      > Subscribe/Unsubscribe/Subscription Changes<br>
>      > [9]<a href="http://mailman.celestial.com/mailman/listinfo/filepro-list" target="_blank" rel="noreferrer">http://mailman.celestial.com/mailman/listinfo/filepro-list</a><br>
>      ><br>
>      --<br>
>      Audio panton, cogito singularis.<br>
>      _______________________________________________<br>
>      Filepro-list mailing list<br>
>      [10]<a href="mailto:Filepro-list@lists.celestial.com" target="_blank">Filepro-list@lists.celestial.com</a><br>
>      Subscribe/Unsubscribe/Subscription Changes<br>
>      [11]<a href="http://mailman.celestial.com/mailman/listinfo/filepro-list" target="_blank" rel="noreferrer">http://mailman.celestial.com/mailman/listinfo/filepro-list</a><br>
>      _______________________________________________<br>
>      Filepro-list mailing list<br>
>      [12]<a href="mailto:Filepro-list@lists.celestial.com" target="_blank">Filepro-list@lists.celestial.com</a><br>
>      Subscribe/Unsubscribe/Subscription Changes<br>
>      [13]<a href="http://mailman.celestial.com/mailman/listinfo/filepro-list" target="_blank" rel="noreferrer">http://mailman.celestial.com/mailman/listinfo/filepro-list</a><br>
> <br>
> References<br>
> <br>
>    1. mailto:<a href="mailto:filepro-list@lists.celestial.com" target="_blank">filepro-list@lists.celestial.com</a><br>
>    2. mailto:<a href="mailto:scott.walker@ramsystemscorp.com" target="_blank">scott.walker@ramsystemscorp.com</a><br>
>    3. mailto:<a href="mailto:filepro-list-bounces%252Bscottwalker" target="_blank">filepro-list-bounces%2Bscottwalker</a><br>
>    4. mailto:<a href="mailto:filepro-list@lists.celestial.com" target="_blank">filepro-list@lists.celestial.com</a><br>
>    5. mailto:<a href="mailto:scooter6@gmail.com" target="_blank">scooter6@gmail.com</a><br>
>    6. mailto:<a href="mailto:scooter6@gmail.com" target="_blank">scooter6@gmail.com</a><br>
>    7. <a href="http://mailman.celestial.com/pipermail/filepro-list/attachments/20190" target="_blank" rel="noreferrer">http://mailman.celestial.com/pipermail/filepro-list/attachments/20190</a><br>
>    8. mailto:<a href="mailto:Filepro-list@lists.celestial.com" target="_blank">Filepro-list@lists.celestial.com</a><br>
>    9. <a href="http://mailman.celestial.com/mailman/listinfo/filepro-list" target="_blank" rel="noreferrer">http://mailman.celestial.com/mailman/listinfo/filepro-list</a><br>
>   10. mailto:<a href="mailto:Filepro-list@lists.celestial.com" target="_blank">Filepro-list@lists.celestial.com</a><br>
>   11. <a href="http://mailman.celestial.com/mailman/listinfo/filepro-list" target="_blank" rel="noreferrer">http://mailman.celestial.com/mailman/listinfo/filepro-list</a><br>
>   12. mailto:<a href="mailto:Filepro-list@lists.celestial.com" target="_blank">Filepro-list@lists.celestial.com</a><br>
>   13. <a href="http://mailman.celestial.com/mailman/listinfo/filepro-list" target="_blank" rel="noreferrer">http://mailman.celestial.com/mailman/listinfo/filepro-list</a><br>
<br>
-- <br>
Audio panton, cogito singularis.<br>
_______________________________________________<br>
Filepro-list mailing list<br>
<a href="mailto:Filepro-list@lists.celestial.com" target="_blank">Filepro-list@lists.celestial.com</a><br>
Subscribe/Unsubscribe/Subscription Changes<br>
<a href="http://mailman.celestial.com/mailman/listinfo/filepro-list" target="_blank" rel="noreferrer">http://mailman.celestial.com/mailman/listinfo/filepro-list</a><br>
</blockquote></div>
</blockquote></div>