| To: | David Howells <dhowells@xxxxxxxxxx> |
|---|---|
| Subject: | Re: [PATCH 0/2] Use 64-bit inode numbers internally in the kernel [try #2] |
| From: | Nathan Scott <nathans@xxxxxxx> |
| Date: | Wed, 16 Aug 2006 10:22:24 +1000 |
| Cc: | torvalds@xxxxxxxx, akpm@xxxxxxxx, trond.myklebust@xxxxxxxxxx, aviro@xxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx, nfsv4@xxxxxxxxxxxxx, xfs@xxxxxxxxxxx |
| In-reply-to: | <20060815152627.29222.71414.stgit@warthog.cambridge.redhat.com>; from dhowells@redhat.com on Tue, Aug 15, 2006 at 04:26:27PM +0100 |
| References: | <20060815152627.29222.71414.stgit@warthog.cambridge.redhat.com> |
| Sender: | xfs-bounce@xxxxxxxxxxx |
| User-agent: | Mutt/1.2.5i |
On Tue, Aug 15, 2006 at 04:26:27PM +0100, David Howells wrote: > > These patches make the kernel pass 64-bit inode numbers internally when > communicating to userspace, even on a 32-bit system. They are required > because some filesystems have intrinsic 64-bit inode numbers: NFS3+ and XFS > for example. The 64-bit inode numbers are then propagated to userspace > automatically where the arch supports it. Thanks for doing this, David. FWIW, for XFS its not directly a problem today, we simply block attempts to mount filesystems on 32 bit systems where the inums could get into the problematic ranges. With several XFS changes (main change will be switching to use iget5_locked) we will be able to allow those mounts to go ahead - so, thanks again! cheers. -- Nathan |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: kernel BUG at <bad filename>:50307!, Nathan Scott |
|---|---|
| Next by Date: | Re: 2.6.18-rc3-git3 - XFS - BUG: unable to handle kernel NULL pointer dereference at virtual address 00000078, Nathan Scott |
| Previous by Thread: | Re: kernel BUG at <bad filename>:50307!, Nathan Scott |
| Next by Thread: | Re: [xfs-masters] [BUG]: soft lock detected, David Chinner |
| Indexes: | [Date] [Thread] [Top] [All Lists] |