SCIENTIFIC-LINUX-USERS Archives

July 2014

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Lamar Owen <[log in to unmask]>
Reply To:
Lamar Owen <[log in to unmask]>
Date:
Thu, 10 Jul 2014 09:06:00 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (47 lines)
On 07/09/2014 06:48 PM, Patrick J. LoPresti wrote:
> On Wed, Jul 9, 2014 at 1:27 PM, Lamar Owen <[log in to unmask]> wrote:
>> I don't recall if I had to specify that option or not with CentOS 5.10:
>> +++++++++++++++++++++++++++
>> [root@backup-rdc ~]# df -h
>> Filesystem            Size  Used Avail Use% Mounted on
>> ...
>> /dev/mapper/plates-cx3--80
>>                         27T   26T  805G  98% /opt/plates
>> /dev/mapper/vg_opt-lv_backups
>>                        5.8T  5.4T  365G  94% /opt/backups
>> [root@backup-rdc ~]# blkid
> You are getting a little bit lucky, I think...

Perhaps.  But I ran into the >16TB problem with the 32-bit install (same 
filesystem, by the way, lvm exported from the 32-bit install and 
imported on the 64-bit reinstall) as soon as the 'Used' column passed 
16TB (binary TB....).  This is the very filesystem on which that happened.
> The failure happens
> when the first 16TB of the block device (as opposed to file system)
> are in use. Since XFS allocates blocks from allocation groups all over
> the disk, it is improbable that the first 16TB is ever actually in use
> until the entire file system fills up....

Hmm, interesting.

> I swear I am not making up this problem; see e.g.
> http://www.doc.ic.ac.uk/~dcw/xfs_16tb/

Oh, I believe you. Most likely the reason I've not hit it is due to the 
file mix that's on the filesystem; the number of files is pretty small, 
but each file is large (in the GB size range per file; they are scanned 
astronomical photographic plates in uncompressed FITS format).  Thus all 
the inodes should be able to be in the first 1TB of the disk.

>
> Anyway, inode64 is the recommended mount option for large XFS file
> systems unless you have some specific legacy need (like exporting via
> NFSv2 to 32-bit Solaris... guess how I know)
>
>
Oh, I believe you.  It may be worthwhile for me to add that mount 
option; can't hurt.  It's just that the 16TB issue I hit was different 
from this one;  I hit the 4k stack size issue with the 32-bit kernel, 
and that issue went away with the 64-bit kernel.  But this issue is 
different.

ATOM RSS1 RSS2