| To: | Eric Sandeen <sandeen@xxxxxxx> |
|---|---|
| Subject: | Re: Work Items |
| From: | Andi Kleen <ak@xxxxxxx> |
| Date: | Sat, 12 Oct 2002 21:33:51 +0200 |
| Cc: | Alp ATICI <atici@xxxxxxxxxxxxxxxxxxxxx>, Christoph Hellwig <hch@xxxxxxxxxxxxx>, linux-xfs@xxxxxxxxxxx |
| In-reply-to: | <Pine.LNX.4.44.0210121336430.24658-100000@stout.americas.sgi.com> |
| References: | <Pine.LNX.4.44.0210121124180.26350-100000@cpw.math.columbia.edu> <Pine.LNX.4.44.0210121336430.24658-100000@stout.americas.sgi.com> |
| Sender: | linux-xfs-bounce@xxxxxxxxxxx |
| User-agent: | Mutt/1.3.22.1i |
On Sat, Oct 12, 2002 at 01:44:41PM -0500, Eric Sandeen wrote: > Internally, XFS can handle 64-bit inodes and 64-bit block numbers. > > However, since Linux VFS cannot handle 64-bit inodes, XFS on Linux > is -always- restricted to 32 bit inodes. Linux VFS can handle them in a limited way - otherwise e.g. NFSv3 wouldn't work. You can use custom iget functions to look them up in the inode cache. What doesn't work is exporting them to user space via stat64() For XFS it should be enough for now. > With Peter's patch, lots of XFS's 64-bit-ness can probably be turned back on. No, but even 2.4 supports it in a limited way. -Andi |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | XFS-1.2, James Haydon |
|---|---|
| Next by Date: | Re: [2.4.18-14SGI_XFS_1.2a1] acl problems (was: root xfs filesystem executable bits bug comeback?), Ethan Benson |
| Previous by Thread: | Re: Work Items, Eric Sandeen |
| Next by Thread: | Re: Work Items, Stephen Lord |
| Indexes: | [Date] [Thread] [Top] [All Lists] |