From: Eric Sandeen <sandeen@sandeen.net>
To: Emmanuel Florac <eflorac@intellique.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH] enable inode64 by default when possible
Date: Wed, 10 Feb 2010 14:15:21 -0600 [thread overview]
Message-ID: <4B7313D9.9020603@sandeen.net> (raw)
In-Reply-To: <20100210210448.36f16aba@galadriel.home>
Emmanuel Florac wrote:
> Le Wed, 10 Feb 2010 13:32:39 -0600 vous écriviez:
>
>> As such, this patch changes the default to inode64 whenever
>> XFS_BIG_INUMS is set, which in turn depends on either
>> CONFIG_LBDAF or 64-bit longs.
>
> But doesn't it cause problems specially for NFS sharing ?
>
For some clients, yes - as do other NFS servers.
That's what noinode64 is for...
Also, newer nfs clients have an option:
nfs.enable_ino64=
[NFS] enable 64-bit inode numbers.
If zero, the NFS client will fake up a 32-bit inode
number for the readdir() and stat() syscalls instead
of returning the full 64-bit number.
The default is to return 64-bit inode numbers.
(see Documentation/kernel-parameters.txt)
At some point we have to drag people kicking and screaming
out of 1988, I think! :)
(I am mindful that this may manifest itself as "xfs is incompatible"
but if we document this and advertise it a bit, I hope we can avoid
that. At some point, apps just need to be fixed.)
-Eric
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2010-02-10 20:14 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-10 19:32 [PATCH] enable inode64 by default when possible Eric Sandeen
2010-02-10 20:04 ` Emmanuel Florac
2010-02-10 20:15 ` Eric Sandeen [this message]
2010-02-10 20:42 ` Emmanuel Florac
2010-04-09 22:01 ` Alex Elder
2010-04-10 2:37 ` Stan Hoeppner
2010-04-10 3:34 ` Eric Sandeen
2010-04-12 6:21 ` Dave Chinner
2010-04-13 6:35 ` Stan Hoeppner
2010-04-14 6:57 ` Andi Kleen
2010-04-12 6:12 ` [RFC, PATCH] inode64 feature bit (was Re: [PATCH] enable inode64 by default when possible) Dave Chinner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B7313D9.9020603@sandeen.net \
--to=sandeen@sandeen.net \
--cc=eflorac@intellique.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.