<div class="gmail_quote">On Tue, Apr 5, 2011 at 10:21 AM, Lamar Owen <span dir="ltr"><<a href="mailto:lowen@pari.edu">lowen@pari.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
You really, really, really don't want to do this.  Not on 32-bit.  When you roll one byte over 16TB you will lose access to your filesystem, silently, and it will not remount on a 32-bit kernel.  XFS works best on a 64-bit kernel for a number of reasons; the one you're likely to hit first is the 16TB hard limit for *occupied* file space; you can mkfs an XFS filesystem on a 17TB or even larger partition or volume, but the moment the occupied data rolls over the 16TB boundary you will be in disaster recovery mode, and a 64-bit kernel will be required for rescue.<br>


<br>
The reason I know this?  I had it happen.  On a CentOS 32-bit backup server with a 17TB LVM logical volume on EMC storage.  Worked great, until it rolled 16TB.  Then it quit working.  Altogether.  /var/log/messages told me that the filesystem was too large to be mounted.  Had to re-image the VM as a 64-bit CentOS, and then re-attached the RDM's to the LUNs holding the PV's for the LV, and it mounted instantly, and we kept on trucking.<br>


<br>
There's a reason upstream doesn't do XFS on 32-bit.<br></blockquote><div><br></div><div>Afaik 32-bit binaries do run on the 64-bit build and compat libraries exist for most everything. You should evaluate if you really *really* need 32-bit. </div>

<div><br></div><div><br></div></div>