On Mar 7, 2012, at 1:16 PM, John R Pierce wrote:
> On 03/07/12 6:47 AM, Ross Walker wrote:
>> These days XFS should always be inode64 enabled, given the size of disks,
>> and NFS should have been fixed a long, long time ago.
>
> yes. problem is, we have clients that are running all sorts of OS
On Wed, Mar 7, 2012 at 1:46 PM, John R Pierce wrote:
> On 03/07/12 11:27 AM, Warren Young wrote:
>> Why do those embedded systems have to see a whole 74 TB storage midden?
>> Why not slice off a 1 TB or so LVM slice for them?
>
> LVM management blows chunks. each of these arrays (we have dozen
On 03/07/12 11:27 AM, Warren Young wrote:
> Why do those embedded systems have to see a whole 74 TB storage midden?
>Why not slice off a 1 TB or so LVM slice for them?
LVM management blows chunks. each of these arrays (we have dozens of
these 74TiB storage servers) will end up nearly filled
On 3/7/2012 11:16 AM, John R Pierce wrote:
> On 03/07/12 6:47 AM, Ross Walker wrote:
>> These days XFS should always be inode64 enabled, given the size of disks,
>> and NFS should have been fixed a long, long time ago.
>
> yes. problem is, we have clients that are running all sorts of OS's,
> inc
On 03/07/12 6:47 AM, Ross Walker wrote:
> These days XFS should always be inode64 enabled, given the size of disks, and
> NFS should have been fixed a long, long time ago.
yes. problem is, we have clients that are running all sorts of OS's,
including older versions of Solaris... this is a man
On Mar 7, 2012, at 2:17 AM, John R Pierce wrote:
> On 03/06/12 10:40 PM, James A. Peltier wrote:
>> I've had to use inode64 on far smaller file systems (15TB) due to inode
>> counts (many files) and not file system size.
>
>
> My understanding of it is, the inode number is its physical positio
On 03/06/12 10:40 PM, James A. Peltier wrote:
> I've had to use inode64 on far smaller file systems (15TB) due to inode
> counts (many files) and not file system size.
My understanding of it is, the inode number is its physical position on
the disk. if the first 1TB (2^31 * 512) of the disk h
- Original Message -
| On Mar 6, 2012, at 6:59 PM, John R Pierce
| wrote:
|
| > On 03/06/12 3:51 PM, Ross Walker wrote:
| >> Is there a need for inode64? Is it too late to back-out of it, or
| >> have you pickled the file system already.
| >
| > as i undertsand it, you need inode64 on an
On Mar 6, 2012, at 6:59 PM, John R Pierce wrote:
> On 03/06/12 3:51 PM, Ross Walker wrote:
>> Is there a need for inode64? Is it too late to back-out of it, or have you
>> pickled the file system already.
>
> as i undertsand it, you need inode64 on any XFS file system over 2TiB,
> and ours is
On 03/06/12 3:51 PM, Ross Walker wrote:
> Is there a need for inode64? Is it too late to back-out of it, or have you
> pickled the file system already.
as i undertsand it, you need inode64 on any XFS file system over 2TiB,
and ours is 74TiB.
--
john r pierceN 37
On Mar 6, 2012, at 4:36 PM, John R Pierce wrote:
> On 03/02/12 10:05 AM, John R Pierce wrote:
>> is anyone familiar with this inode64 stuff and NFS in EL6.2 ?
>
> still having show stopping issues with XFS, inode64, and NFS. the
> fsid=uuid option suggested by some googling doesn't seem to wo
On 03/02/12 10:05 AM, John R Pierce wrote:
> is anyone familiar with this inode64 stuff and NFS in EL6.2 ?
still having show stopping issues with XFS, inode64, and NFS. the
fsid=uuid option suggested by some googling doesn't seem to work at all
for Solaris clients...
http://xfs.org/index.php/X
we recently deployed some large XFS file systems with centos 6.2 used as
NFS servers...
I've had some reports of a problem similar to the one reported here...
http://www.linuxquestions.org/questions/red-hat-31/xfs-inode64-nfs-export-no_subtree_check-and-stale-nfs-file-handle-message-855844/
thes
13 matches
Mail list logo
